A Cross-Site Request Forgery, or CSRF, attack occurs when a malicious website, email, instant message, application, etc. causes a user’s web browser to perform some action on another website where that user is already authenticated, or logged in. Often this occurs without the user knowing the action has occurred.
A successful CSRF exploit can compromise end user data and operation, when it targets a normal user. If the targeted end user is the administrator account, a CSRF attack can compromise the entire web application.
The impact of a CSRF attack depends on the website which is receiving the action. Here’s an example:
- Bob logs into his bank account, performs some banking but does not log out.
- Bob checks his email and clicks a link to an unfamiliar website.
- The unfamiliar website makes a request to Bob’s banking website to transfer money
passing in cookie information stored from Bob’s banking session in step 1.
- Bob’s banking website receives the request from the unfamiliar (malicious) website,
without using a CSRF token and processes the transfer.
Even more interesting is the idea that the link to the malicious website could be contained in valid HTML which does not require Bob to click on the link, . If Bob’s device (i.e., browser) renders this image, it will make the request to malicious_site.com and potentially kick off the CSRF attack.
Now, knowing the dangers of CSRF attacks, they can be mitigated a number of ways, perhaps the most popular is a CSRF token which must be submitted with potentially data altering requests (i.e., POST requests). Here, a web application (like Bob’s bank) would generate a token with two parts, one which Bob would receive and one which the application would retain.
When Bob attempts to make transfer requests, he would have to submit the token which the bank would then validate with its side of the token.
Lastly, it’s important to note (thanks to Jobert Abma for flagging), that not every request without as CSRF token is a valid CSRF issue. Some websites may perform additional checks like comparing the referrer header (though this isn’t foolproof and there have been cases where this was bypassed). This is a field that identifies the address of the webpage that linked to the resource being requested. In other words, if the referrer on a POST call is not from the same site receiving the HTTP request, the site may disallow the call thereby achieving the same effect as validating a CSRF token. Additionally, not every site refers to or users the term csrf when creating or defining a token. For example, on Badoo it is the rt parameter as discussed below.
Check out the OWASP testing guide at OWASP Testing for CSRF 1
Badoo Full Account Takeover
Report Link: https://hackerone.com/reports/127703
Date Reported: April 1, 2016
Bounty Paid: $852
CSRF represent another vector for attack and may be executed without a victim even knowing or actively performing an action. Finding CSRF vulnerabilities may take some ingenuity and again, a desire to test everything.
Generally, web forms are uniformly protected by application frameworks like Rails if the site is performing a POST request but APIs can be a different story. For example, Shopify is written primarily using the Ruby on Rails framework which provides CSRF protection for all forms by default (though it can be turned off). However, clearly this isn’t necessarily the case for API’s created with the framework. Lastly, be on the lookout for any calls which change server data (like delete actions) which are being performed by a GET request.