Introduction to Cross-Site Request Forgery (CSRF)
As a penetration tester or bug bounty hunter, you will often be tasked by your client to test a web application to check its CSRF defenses. The critical question you must answer is: Is this application vulnerable? Posing as an attacker, you need to find out all the flaws. Can unauthorized actions be performed? Can we intercept the password? Can we manually inject JavaScript code into it and change the application’s state?
Cross-Site Request Forgery (CSRF), sometimes called Sea-Surf, is a type of vulnerability that occurs when a malicious website, email, blog, instant message, or program causes a user’s web browser to perform an unwanted action on a trusted site for which the user is currently authenticated. Finding and mitigating these flaws is a critical part of web application security.
Setting Up the Test Environment: OWASP Juice Shop
To practically demonstrate how to discover CSRF vulnerabilities, a common practice is to use intentionally vulnerable web applications. These environments are specifically designed with security flaws, allowing ethical hackers to test their skills and tools without causing harm to real systems.
The security community has already examined two intentionally vulnerable web applications: WebGoat and http://testphp.vulnweb.com. For this detailed exploration, the focus will be on another excellent, intentionally vulnerable web application: OWASP Juice Shop. The OWASP Foundation [Open Web Application Security Project] has created this unique e-commerce application, which is considered one of the most modern and challenging vulnerable web applications.
Installation Steps
Installing Juice Shop is extremely easy. The most recommended method is using a virtual environment like Kali Linux with VirtualBox.
- Navigate to the official Juice Shop GitHub repository: https://github.com/bkimminich/juice-shop.
- Go to the setup section and you will find many options available to set up your local Juice Shop.
- The most effective method involves using a Kali Linux environment:
- Open your VirtualBox Kali Linux and download the latest zipped application folder.
- Unpack the zipped content in your Download directory.
- After that, use the following code in your terminal:
root@kali:~/Downloads# cd juice-shop_8.7.2/
root@kali:~/Downloads/juice-shop_8.7.2# npm start
> juice-shop@8.7.2 start /root/Downloads/juice-shop_8.7.2
> node app
info: All dependencies in ./package.json are satisfied (OK)
info: Detected Node.js version v10.16.0 (OK)
info: Detected OS linux (OK)
info: Detected CPU x64 (OK)
info: Required file index.html is present (OK)
info: Required file main.js is present (OK)
info: Required file polyfills.js is present (OK)
info: Required file runtime.js is present (OK)
info: Required file vendor.js is present (OK)
info: Configuration default validated (OK)
info: Port 3000 is available (OK)
info: Server listening on port 3000
Now, your Juice Shop application is running and accessible locally on http://localhost:3000.
Initial Traffic Interception with Burp Suite
The next step involves setting up a proxy tool to intercept and examine the traffic between the browser and the vulnerable application. Burp Suite is the industry standard for this task.
Open Burp Suite. Crucially, keep intercept off initially. Juice Shop provides a registration facility for new users, which must be used to create a baseline account. An account was made using these credentials for the test:
- Email: foo@bar.com
- Password: P@ssword
During registration, a security question is required. There are many choices. The chosen question was: what is your first company? The answer provided was: ‘MyCompany’.
The goal of the next step is to test the password change functionality, as this is a common target for CSRF attacks. The plan is to add the username Sanjib in the profile section, and then attempt to change the password in Juice Shop. The question is, Will Burp Suite intercept that traffic successfully? A check was already performed to ensure that all traffic to Juice Shop is being processed through Burp Suite.
Capturing the Password Change Request
The current password was changed from P@ssword to password123 within the Juice Shop application. It was successfully changed in the application. Simultaneously, the following request was captured in Burp Suite:
GET /rest/user/change-password?current=P@ssword&new=password123
&repeat=password123 HTTP/1.1
Host: localhost:3000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0)
Gecko/20100101 Firefox/60.0
Accept: application/json, text/plain, */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://localhost:3000/
Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJ
zdGF0dXMiOiJzdWNjZXNzIiwiZGF0YSI6eyJpZCI6MTUsInVzZXJuYW1lIjoiI
iwiZW1haWwiOiJmb29AYmFyLmNvbSIsInBhc3N3b3JkIjoiMzgyZTAzNjBlNGV
iN2I3MDAzNGZiYWE2OWJlYzU3ODYiLCJpc0FkbWluIjpmYWxzZSwibGFzdExvZ
2luSXAiOiIwLjAuMC4wIiwicHJvZmlsZUltYWdlIjoiZGVmYXVsdC5zdmciLCJ
0b3RwU2VjcmV0IjoiIiwiaXNBY3RpdmUiOnRydWUsImNyZWF0ZWRBdCI6IjIwM
TktMDYtMjAgMDE6MDk6NDMuMjcwICswMDowMCIsInVwZGF0ZWRBdCI6IjIwMTk
tMDYtMjAgMDE6MDk6NDMuMjcwICswMDowMCIsImRlbGV0ZWRBdCI6bnVsbH0sI
mlhdCI6MTU2MDk5MzAwMCwiZXhwIjoxNTYxMDExMDAwfQ.JZYZzCAgPEkbGA9a
RIKKKrMue9lnZBkNkyXbP86TXn40sT6k3yP-6kVejGvyM5UNBd0iXpTOmkaG9
tZefEoIqsm7D7tb6gxvJcdP2s6RrS0BSTH2w32WZ46xaFt4EVCFGqMYUeOVkbLU1UtVJUaf-IVm66lzk29njHtz4Lo_g
Cookie: language=en; io=Unq26SseBmTY8sRrAAAC; welcome-bannerstatus=dismiss; token=eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJ
zdGF0dXMiOiJzdWNjZXNzIiwiZGF0YSI6eyJpZCI6MTUsInVzZXJuYW1lIjoiI
iwiZW1haWwiOiJmb29AYmFyLmNvbSIsInBhc3N3b3JkIjoiMzgyZTAzNjBlNGV
iN2I3MDAzNGZiYWE2OWJlYzU3ODYiLCJpc0FkbWluIjpmYWxzZSwibGFzdExvZ
2luSXAiOiIwLjAuMC4wIiwicHJvZmlsZUltYWdlIjoiZGVmYXVsdC5zdmciLCJ
0b3RwU2VjcmV0IjoiIiwiaXNBY3RpdmUiOnRydWUsImNyZWF0ZWRBdCI6IjIwM
TktMDYtMjAgMDE6MDk6NDMuMjcwICswMDowMCIsInVwZGF0ZWRBdCI6IjIwMTk
tMDYtMjAgMDE6MDk6NDMuMjcwICswMDowMCIsImRlbGV0ZWRBdCI6bnVsbH0sI
mlhdCI6MTU2MDk5MzAwMCwiZXhwIjoxNTYxMDExMDAwfQ.JZYZzCAgPEkbGA9a
RIKKKrMue9lnZBkNkyXbP86TXn40sT6k3yP-6kVejGvyM5UNBd0iXpTOmkaG9
tZefEoIqsm7D7tb6gxvJcdP2s6RrS0BSTH2w32WZ46xaFt4EVCFGqMYUeOVkbLU1UtVJUaf-IVm66lzk29njHtz4Lo_g; cookieconsent_status=dismiss;
continueCode=6DyMwXxlmzZRy9EWqoBKPLew2Or6dwo1d4b15M3aQvYVkgnpj
87XNDJKPVJL
DNT: 1
Connection: close
Establishing the Vulnerability
Therefore, the action of changing the password was successfully attacked and it is established that this web application has vulnerabilities; its CSRF defenses are weak.
Examine the first section of the header part that is reflected on Burp Suite:
GET /rest/user/change-password?current=P@ssword&new=password123 &repeat=password123 HTTP/1.1
It means that Burp Suite captured the traffic without any difficulties. If the CSRF defense had been strong enough in Juice Shop, Burp Suite could not have captured the request parameters so easily. Here, the output is a clear indication of weakness. Any strong application would not have allowed capturing that data in such a direct and simple manner, typically by requiring a unique, unguessable CSRF token in the request body or header.
Advanced Testing with Burp Suite Repeater
To confirm the vulnerability and further test the application’s response to manipulated requests, a tool within Burp Suite called Repeater can be used. Since this tool plays back modified requests to the server, it’s aptly named Repeater. Security professionals can always manually modify any HTTP request and replay the request back to the server to test the responses and find vulnerabilities.
Attempting to Change the Password with Incorrect Credentials
To send the captured request to Repeater, simply use the second mouse click (right-click) on the Burp Suite response and choose the Repeater option.
On the left side panel of the Repeater tool, one can change the current password parameter to pass (an intentionally incorrect password) and click the Go button. This change is made on the top panel of the header section in the Raw tab. By changing the current password to a new value and clicking the Go button, the tool plays back the modified request to the server. The HTTP request has been manually modified to try and force the server to obey a new order.
On the right side panel, the application provides the following output.
HTTP/1.1 401 Unauthorized
X-Powered-By: Express
Access-Control-Allow-Origin: *
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
Content-Type: text/html; charset=utf-8
Content-Length: 32
ETag: W/"20-6tKKLCLLgOnzR5qInvJyo/E13vg"
Vary: Accept-Encoding
Date: Thu, 20 Jun 2019 01:28:22 GMT
Connection: close
Current password is not correct.
The response states: “Current password is not correct.” This is expected. When the initial login occurred, the password was immediately changed (from P@ssword to password123), and the current test is using the wrong password (pass).
Successfully Forcing the Password Change
The next logical step is to attempt another password change, this time using the correct current password (password123) and setting a new one, for instance, pass1234. The same process will be executed through the Burp Suite Repeater tool, but with the correct credentials.
Now, using the Repeater feature of Burp Suite, the newly changed password can also be changed again. On the left panel, the new password parameter is changed to pass1234 and the Go button is clicked above.
On the right side, the following response is received:
HTTP/1.1 200 OK
X-Powered-By: Express
Access-Control-Allow-Origin: *
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
Content-Type: application/json; charset=utf-8
Content-Length: 302
ETag: W/"12e-UI0HnPP2ynY8xMCFiTvRctgcM9A"
Vary: Accept-Encoding
Date: Thu, 20 Jun 2019 01:34:56 GMT
Connection: close
{"user":{"id":15,"username":"Sanjib","email":"foo@bar.com",
"password":"32250170a0dca92d53ec9624f336ca24","isAdmin":false,"
lastLoginIp":"0.0.0.0","profileImage":"default.svg","totpSecret
":"","isActive":true,"createdAt":"2019-06-20T01:09:43.270Z",
"updatedAt":"2019-06-20T01:34:56.417Z","deletedAt":null}}
As clearly seen in the preceding code, the HTTP status is 200 OK. This confirms the attack worked. The password of the current user was successfully changed while the user was logged in, simply by replaying and modifying a request. Once the user logs out, a successful login can be achieved with the new password (pass1234).
Immediately, the successful attempt to break the CSRF defenses is reflected on the Juice Shop application itself. It announces: “You successfully solved a challenge: Privacy Policy Tier 1 (Read our privacy policy.)”
Injecting JavaScript for State Change
Further confirming the vulnerability, an attempt can be made to inject JavaScript code into the Juice Shop application. If the code successfully changes the password or triggers another state-changing action, the mission will be unequivocally successful.
A specific piece of code can be prepared for injection (though the code itself is missing here).
// The JavaScript payload that triggers the state change
// is placed here for injection.
This code can be pasted into the search text box, and upon hitting the button, a message is immediately popped up in the terminal:
info: Solved challenge Privacy Policy Tier 1 (Read our privacy policy.)
This successful injection further proves that the application is vulnerable and can be manipulated by an attacker to force state-changing actions on an authenticated user.
Conclusion: The Ongoing Journey in Security Testing
This detailed walkthrough established many features of CSRF attacks and demonstrated their successful exploitation on the OWASP Juice Shop application. However, the journey in web application security has just begun; the forms of attacks are continually changing and evolving.
It is highly recommended that security professionals and enthusiasts get involved with the open source resources available on the Internet (OWASP is a very good place) to keep up with current defense mechanisms and testing methodologies. It takes time to get adjusted to all the challenges. The next focus of study will be another major challenge: how to defend against Cross-site Scripting (XSS).