Cross-Site Request Forgery (CSRF) is an attack where an attacker sends requests from malicious website to a target web application that a user is already authenticated. This way an attacker can access functionality in a target web application via the victim's already authenticated browser. Targets include web applications like social media, in-browser email clients, online banking and web interfaces for network devices.
- Malicious requests are sent from a site that a user visits to another site that the attacker believes the victim is validated against.
- The malicious requests are routed to the target site via the victim’s browser, which is authenticated by the victim against the target site.
- The vulnerability lies in the web application, not the victim’s browser.
Executing a CSRF Attack
In a Cross-Site Request Forgery attack, the victim must be authenticated against (logged into) the target site(web application). For instance, let’s say www.abcdbank.com has online banking that is vulnerable to CSRF. If I visit a page containing a CSRF attack on www.abcdbank.com but am not currently logged in, nothing happens. If I am logged in, however, the requests in the attack will be executed as if they were actions that I had intended to take.
Let’s look at how the attack described above would work in a bit more detail.
First, let’s assume that I’m logged into my account on www.abcdbank.com, which allows for online banking features such as transferring funds to another account.
To transfer funds to some account say 98765, I need to send a GET request to http://abcdbank.com/transferFunds?amount=1000&destinationAccount=98765, this normally happens
Now let’s say I happen to visit www.malicioussite.com. It just so happens that this site is trying to attack people who bank with www.abcdbank.com and has set up a CSRF attack on its site. The attack will transfer $1,000 to account number 12345. Somewhere on www.malicioussite.com, attackers have added this line of code:
Now let’s say I happen to visit www.malicioussite.com. It just so happens that this site is trying to attack people who bank with www.abcdbank.com and has set up a CSRF attack on its site. The attack will transfer $1,000 to account number 12345. Somewhere on www.malicioussite.com, attackers have added this line of code:
<iframe src="http://abcdbank.com/transferFunds?amount=100&destinationAccount=12345>
Upon loading that iframe, my browser will send that request to www.abcdbank.com, which my browser has already logged in as me. The request will be processed and send $1,000 to account 12345.
To prevent Cross-Site Request Forgery (CSRF) attacks append unpredictable challenge tokens to each request and associate them with the user’s session. Such tokens should at a minimum be unique per user session, but can also be unique per request. By including a challenge token with each request, the developer can ensure that the request is valid and not coming from a source other than the user.
Post a Comment