CSRF in web applications:

Cross Site Request Forgery vulnerabilities have a potential to occur wherever the application has features with state changes on the server side. These often occur through features with form submissions. One such For example, submitting a form to change password is a feature, where state change happens. In the next few sections, let us discuss how CSRF vulnerabilities can be discovered and exploited.

Finding Cross Site Request Forgery:

Let us launch Xtreme Vulnerable Web Application (XVWA) and navigate to CSRF. We can also access this challenge directly using the following URL.   The page looks as follows. As we can see, a user can change his password using the form. Interestingly, the form is not asking for the user’s current password. Providing the new password twice will update the user’s password. If an attacker can trick the logged in user to submit this form with an attacker controlled password, the victim will change his password without his knowledge. It is needless to mention that the attack will work only if the developers do not implement appropriate protections against CSRF attacks.

Exploiting CSRF vulnerabilities

Let us first login to the application as an attacker using the following credentials.   Next, navigate to the vulnerable page and enter the new password twice and intercept the request using Burp Suite. The request looks as follows.   User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:82.0) Gecko/20100101 Firefox/82.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 Connection: close Referer: http://192.168.1.105/xvwa/vulnerabilities/csrf/ Cookie: PHPSESSID=j8f2hcm4gbfj0oa3hkgb4n7f41 Upgrade-Insecure-Requests: 1 As we can notice, clicking the Submit button has resulted in a GET request. Now, an attacker can craft a link to a malicious page with the following proof of concept code.  

A chance to win a free iPhone.

I want to participateThis page can be hosted on an attacker controlled server and it looks as follows when someone accesses this page. Now, let us login to XVWA as admin using the following credentials.   The following figure shows that the user admin is logged in. Following is the cookie for this user, which can be seen using Developer Tools of the browser. With a valid session as admin in XVWA, let us click the button I want to participate in the link provided by the attacker using the same browser and observe the http request using Burp proxy. We should see the following.   User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:82.0) Gecko/20100101 Firefox/82.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 Connection: close Referer: http://192.168.1.90/iphone.html Cookie: PHPSESSID=j8f2hcm4gbfj0oa3hkgb4n7f41 Upgrade-Insecure-Requests: 1 As we can notice, a request to update user password has been made and forwarding the request will update the user’s password. In a real world scenario, the victim obviously just clicks the link without using a tool like Burp and the password will be updated silently.   Let us assume that the password change request is sent using POST instead of GET. The following excerpt can be used as a proof of concept exploit.  

A chance to win a free iPhone

When this page is accessed using a browser, it looks as follows. Clicking the button produces the following HTTP request using POST.   User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:82.0) Gecko/20100101 Firefox/82.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: 26 Origin: http://192.168.1.90 Connection: close Referer: http://192.168.1.90/iphone-post.html Cookie: PHPSESSID=j8f2hcm4gbfj0oa3hkgb4n7f41 Upgrade-Insecure-Requests: 1 passwd=xvwa2&confirm=xvwa2 This request once again updates the user password without his knowledge.

Conclusion:

In this article, we have discussed how Cross Site Request Forgery vulnerabilities can be exploited in web applications. We have discussed how one can craft exploits for CSRF vulnerabilities both when the application is using GET and POST methods. CSRF vulnerabilities are often hard to mitigate due to the fact that developers find it hard to understand these. In a later article, we will discuss approaches that can be used to mitigate CSRF vulnerabilities.  

Sources:

https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html https://owasp.org/www-community/attacks/csrf https://owasp.org/www-project-top-ten/