CSRF stands for Cross-Site Request Forgery. It is a web security vulnerability that will force you to submit a request to a Web application where you are currently authenticated. It exploits the trust the web application has in an authenticated user.
In today’s article, we will cover-
Let’s know the details of what is CSRF in Cybersecurity.
What can be the Impact of a CSRF Attack?
A Cross-Site Request Forgery attack’s first and foremost impact is turning an unpleasant relationship between the user and the web application. It can happen while-
- Changing your email address
- Changing your account password
- Or making a fund transfer
The attacker can control the user’s account entirely or steal a vast amount of money without the user’s consent. The worst part of all these is if the user is an Admin of the application or software, then the attacker can access all the database and core functionalities.
How does Cross-Site Request Forgery Work?
Most of the time, attackers use social engineering platforms to launch a CSRF attack. Firstly they create maliciously crafted URLs. Then tricks the victim into clicking on an unauthorized request for a particular Web application.
The request consists of credentials related to the website, such as user session cookies, to make it look like an authorized request. That’s why the attackers successfully exploit the software’s vulnerability.
Mainly they wait and target the software malfunctioning to differentiate between valid and forged requests.
Let’s have a ride to a CSRF attack.
CSRF Attack Example of Different Scenarios
X wants to send $2000 to Y through a bank web application (suppose- superbank.com), which is CSRF vulnerable. Now an attacker named Z wishes to trick X send this money to himself instead. In the beginning, Z will create an exploit URL or Script. And then trick X into executing the Social Engineering action.
Here we will explain 3 different scenarios.
1. GET Scenario
The web application can be designed to use GET requests primarily in case of transferring parameters and executing actions. So the money transfer operation URL might look like this-
GET http://superbank.com/transfer.do?acct=Y&amount=2000 HTTP/1.1Z, the attacker, will now misuse the software vulnerability using X as the victim. To transfer a large amount of money, Z replaces the beneficiary name with himself and transfers the amount to the URL-
http://superbank.com/transfer.do?acct=Z&amount=200000It tricks X into loading that particular URL when he is logged into the bank application. To do so Z will either send an unsolicited email with HTML content or input an exploit script/ URL or pages where the victim (X) was visiting parallelly doing online banking. That exploit URL can be hyperlinked with some intriguing text.
<a href="http://superbank.com/transfer.do?acct=Z&amount=200000">Check Out the Alone Girl!</a>Or as a 0x0 fake image:
<img src="http://superbank.com/transfer.do?acct=Z&amount=200000" width="0" height="0" border="0">2. POST Scenario
In POST the attack is executed in a different way than GET. Suppose the bank is now using POST requests it looks like-
POST http://superbank.com/transfer.do HTTP/1.1
acct=Y&amount=2000This type of request can not be exploited with standard A or IMG tags
Such a request cannot be delivered using standard A or IMG tags, but can be delivered using a FORM tag:
<form action="http://superbank.com/transfer.do" method="POST">
<input type="hidden" name="acct" value="Z"/>
<input type="hidden" name="amount" value="200000"/>
<input type="submit" value="Check Out the Alone Girl"/>
</form>3. HTTP Method
Up-to-date and recent APIs use HTTP methods, like- PUT and DELETE. For instance, SuperBank uses PUT which takes a JSON block as an argument.
PUT http://superbank.com/transfer.do HTTP/1.1
{ "acct":"Y", "amount":2000 }This type of request can be executed using JavaScript embedded into an exploit page:
<script>
function put() {
var x = new XMLHttpRequest();
x.open("PUT","http://superbank.com/transfer.do",true);
x.setRequestHeader("Content-Type", "application/json");
x.send(JSON.stringify({"acct":"Y", "amount":2000}));
}
</script>
<body onload="put()">Luckily, this request will not be executed by modern web browsers thanks to same-origin policy restrictions. Same Origin Policy is-
A web browser permits scripts contained in a first web page to access data in a second web page, but only if both web pages have the same origin. An origin is defined as a combination of URI scheme, hostname, and port number. This policy prevents a malicious script on one page from accessing sensitive data on another web page.
Wikipedia
Also More: Prevent URL Malware from Your Website
Notable CSRF Attacks in Recent Times
1. In 2008, Dutch-owned multinational banking group ING Direct was attacked by CSRF and users lost a huge amount of money. 2. In 2008, YouTube was attacked by CSRF and all actions were made by any user. The situation was immediately fixed. 3. In 2014, McAfee Network Security Manager was also attacked by the same way. Through their vulnerability, attackers modify other user accounts. It was patched as well. 4. In 2020, TikTok users got malware messages through CSRF attackers. TikTok patched this issue within 3 weeks. Source: Bright Sec
5 CSRF Attack Prevention Tactics
Don’t get frightened! CSRF attack is preventable. Check out how you can safeguard your website.
1. Being RESTful
REST- Representational State Transfer is a set of principles, a great creation of computer scientist Roy Fielding. It assigns activity types (View, Create, Delete, Update a resource) for each HTTP verb (GET, POST, PATCH, PUT, DELETE).
Using RESTful design ensures your code is clean and can scale. Most importantly, it reduces vulnerabilities in coding. If you use GET requests for only view or read-only actions, there is a high chance that you will be protected from CSRF attacks. Whatever requests you are using, it shouldn’t transform data and display only recorded data. This way, the vulnerable requests number to CSRF will be limited.
2. Enabling CORS Protection
Enable CORS- Cross-Origin Resource Sharing will add flexibility to the Same-Origin Policy (SOP). It authorizes controlled access to requests originating outside of a given domain. When you need to serve API requests, this can save you instantly.
There are issues in the SOP policy. It can open up your website to cross-domain-based attacks. But it can also be prevented with reasonable control over your CORS policy.
The request headers related to the policy are
- Origin
- Access-Control-Request-Method
- Access-Control-Request-Headers
3. Anti-forgery Tokens
You have to use POST, PUT, PATCH, and DELETE requests to interact with users and let them take actions while needed as a software owner. So, there is another foolproof way to prevent CSRF attacks from these endpoints. In every request, introduce an anti-forgery token that uniquely identifies safe origin websites.
The anti-forgery token will be written out to a hidden HTML field with every request. Now, when the server renders any requests it will identify whether it’s authenticated or an exploited one. In modern frameworks, anti-forgery token management is always included to eliminate such cyber attacks.
4. SameSite Attribute in Your Cookies
A cookie is a piece of data from a website. Web browsers can store it, and particular websites can retrieve it later. Generally, a cookie tells the server that a user has returned to the same website again. So, it has the power to authorize users, store session data, and more.
The worst part of a cookie is that it is an easy way to expose vulnerabilities. There are several attributes in a cookie that control its behavior. The most common one is Max-Age.
The famous Chrome browser team has introduced the SameSite attribute; it is now available to major browsers. SameSite attribute can baffle or thwart CSRF attacks. It allows announcing if the cookies are restricted to a first-party or same-site context. Moreover, it declares how much a user can access the codes of the server side.
How to Set a Same-Site attribute to a Cookie?
Set-Cookie: CookieName=CookieValue; SameSite=Lax;
Set-Cookie: CookieName=CookieValue; SameSite=Strict;- SameSite=Lax means for any GET requests the cookies will not be removed. It gives a consistent user experience while following links to your website from another site. Otherwise, your user would have to reauthenticate to gain access.
- SameSite=Strict means any requests from a third-party site to your website will have all cookies removed by the browser. This is the safest setting and block untrusted authorized requests rendering.
5. Verifying Users for Subtle Actions
If users can reauthenticate themselves before taking any critical actions like sending messages or transferring money, CSRF attacks can be prevented.
When any sensitive action is taken from the user side, a one-time password or simple CAPTCHA will be sent to his/ her registered email or phone number. Users will then fill it out and proceed smoothly if everything goes well.
This method can prevent any kind of dangerous cyber attacks.
Are You Now Safe From CSRF Attack
Every minute, cybercrime costs organizations $1.79 million. This is really unexpected, and hard to get back the money again. If you don’t want to be one of the victims or have a bad experience, don’t forget to learn how not to get attacked.
To do so, you must know what is CSRF in cybersecurity, as it is one of the most common ways to hack websites and your user accounts.
This article has included all the necessary information to prevent this type of cyber harassment. Let us know your experience with cyber attacks.