The Cross Site Request Forgery attack is one of those types of attacks that are hard to recognize at first glance. It is most often used in conjunction with other attacks. It involves forcing a user to perform an unwanted action in a web application. When combined with other vulnerabilities, CSRF can result in various effects. Sometimes it can be exposing sensitive data, deleting, editing and adding data or even taking access to a user's account.
Token
There are several ways to protect against CSRF attacks. It is worth mentioning that most of today's frameworks have built-in protection against CSRF (for example, .NET).
One of the many and also the most well-known way to protect against CSRF is to generate random tokens, i.e. using the Synchronizer Token Pattern. These tokens are generated on the server side once per user session or each time before the next request. Then, after submitting a form that looks like the following:
<form action="/checkout" method="post">
<input type="hidden" name="CSRFToken" value="edc5bb791b41b9d5d25a662dfe0bd11773351bd5c7e87d4c1a32cc66bdbc9694">
(...)
</form>
The server verifies that the CSRFToken it generated earlier is correct. The attacker is not able to predict the token that will be generated moments earlier.
Example on a live application
All the time we are revolving in the world of abstractions and theorizing. So let's move on to practice, which will illustrate the problem and the Cross Site Request Forgery attack. To start with, let's locally replicate repository. Then let's install the necessary libraries and run the application locally. At [http://localhost:3000](http://localhost:3000/)/login is our vulnerable application. Let's log in using the login bob and password test.
We see in front of us a simple form for transferring funds to other users' accounts. We have 500 funds in our account. Now let's go to the attacker's site at the link http://localhost:3001/.
Let's take a look at the Network tab in the developer tools.
Let's take a look at the Network tab in the developer tools.As you can see, several requests have been sent to the vulnerable page. In addition, when we enter it, we can see that our balance has changed.
How did it happen that the balance of our account decreased by 13? Let's check the requests from the attacker more closely.
GET /transfer?to=alice&amount=4 HTTP/1.1
Host: localhost:3000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0
Accept: image/webp,*/*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
DNT: 1
Connection: keep-alive
Referer: http://localhost:3001/
Cookie: connect.sid=s%3AIIXi7mXyaq2sXJuCSaiBEUtkwrYzQxFu.CrlsY1pvQRTrS615VWPdhPCna8dimAmdP%2FzMPEW8ZN8
POST /transfer HTTP/1.1
Host: localhost:3000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Content-Type: application/x-www-form-urlencoded
Content-Length: 17
Origin: http://localhost:3001
DNT: 1
Connection: keep-alive
Referer: http://localhost:3001/
Cookie: connect.sid=s%3AIIXi7mXyaq2sXJuCSaiBEUtkwrYzQxFu.CrlsY1pvQRTrS615VWPdhPCna8dimAmdP%2FzMPEW8ZN8
Upgrade-Insecure-Requests: 1
to=alice&amount=9
Between the requests there were two with a response status of 302. One of them is a GET request, in which we define in the parameters the person to whom we are to send our funds (alice) and their amount (4). The second request is already of POST type and in its body we find the same information. This time, however, the number of funds to be sent has a value of 9. This gives us a total of 13 funds, which is exactly how much has disappeared from our account.
Vulnerability detection scripts
There are a slew of scripts and tools to check if an application is using tokens correctly (if at all). One of the tools is Bolt. Its operation is trivially simple.
┌──(figaro㉿kali)-[~/Desktop/3rdtools/Bolt]
└─$ python3 bolt.py -u http://www.ip:port/ -l 2
⚡ BOLT ⚡
(...)
⚡ Phase: Crawling [1/6]
[!] Crawled 12 URL(s) and found 12 form(s).
⚡ Phase: Evaluating [2/6]
[+] Insecure form(s) found
⚡ Phase: Comparing [3/6]
[-] No CSRF protection to test
Another example of the tool is XSRFProbe.
┌──(figaro㉿kali)-[~/Desktop/3rdtools/XSRFProbe]
└─$ xsrfprobe -u http://www.ip:port/
_____ _____ _____ _____ _____
__|__ |_ __|___ |_ __|___ |_ _|____ |_ _|____ |_ _____ _____ ______ ______
\ ` / || ___| || _ _| || ___| | | _ | || _ ,' / \| _ )| ___|
> < | `-.`-. || \ || ___| | | __| || \ | - || |_ { | ___|
/__/__\ _||______| _||__|\__\ _||___| _| |___| _||__|\__\\_____/|______)|______|
|_____| |_____| |_____| |_____| |_____|
[---] XSRFProbe, A Cross Site Request Forgery Audit Toolkit [---]
[---] [---]
[---] ~ Author : Pinaki Mondal ~ [---]
[---] ~ github.com / 0xInfection ~ [---]
[---] [---]
[---] ~ Version 2.3.1 ~ [---]
[!] Testing site www.evil-page.com status...
[+] Site seems to be up!
[!] Testing endpoint status...
[+] Endpoint seems to be up!
[*] Preparing the request...
[*] Processing the GET Request...
[!] Trying to parse response...
[!] Checking endpoint request validation via Referer Checks...
+--------------------------------------+
| Referer Based Request Validation |
+--------------------------------------+
[!] Making request on normal basis...
[*] Preparing the request...
[*] Processing the GET Request...
[*] Setting generic headers...
[!] Making request with Tampered Referer Header...
[*] Preparing the request...
[*] Processing the GET Request...
[-] Endpoint Referer Validation Not Present!
[-] Heuristics reveal endpoint might be VULNERABLE to Origin Based CSRFs...
[+] Possible CSRF Vulnerability Detected : http://www.evil-page.com/!
[+] Possible Vulnerability Type: No Referer Based Request Validation
[!] Confirming the vulnerability...
[!] Confirming endpoint request validation via Origin Checks...
+-------------------------------------+
| Origin Based Request Validation |
+-------------------------------------+
[!] Making request on normal basis...
[*] Preparing the request...
[*] Processing the GET Request...
[*] Setting generic headers...
[!] Making request with Tampered Origin Header...
[*] Preparing the request...
[*] Processing the GET Request...
[-] Endpoint Origin Validation Not Present!
[-] Heuristics reveal endpoint might be VULNERABLE to Origin Based CSRFs...
[+] Possible CSRF Vulnerability Detected : http://www.evil-page.com/!
[!] Possible Vulnerability Type: No Origin Based Request Validation
[!] Retrieving all forms on http://www.evil-page.com/...
[+] Scan completed!
Sources
https://owasp.org/www-community/attacks/csrf
https://github.com/Learn-by-doing/csrf-examples
https://rohitcoder.medium.com/victims-anti-csrf-token-could-be-exposed-to-third-party-applications-installed-on-user-s-device-be8e40d511ba
https://ysamm.com/?p=702
https://nirajmodi51.medium.com/missing-cors-leads-to-complete-account-takeover-1ed4b53bf9f2
https://github.com/s0md3v/Bolt
https://github.com/0xInfection/XSRFProbe
Top comments (0)