Bypassing CSRF token protection by abusing a misconfigured CORS policy

CORS

Brief explanation of SOP, CORS and CSRF (skip if you know already)

If we want to understand this attack we need to have knowledge first about the Same Origin Policy.

Same-Origin Policy (SOP)

This is the fundamental security model of the web: 2 web pages from different sources should not be allowed to interfere with each other.

  • JavaScript on Site A from reading the cookies of Site B.
  • JavaScript on Site A from reading the content of Site B.

Cross-Origin Resource Sharing (CORS)

This is a browser mechanism which enables controlled access to resources located outside of a given domain. It extends and adds flexibility to the Same-Origin policy (SOP). However, it also provides potential for cross-domain attacks if a website’s CORS policy is poorly configured and implemented.

Cross-Site Request Forgery (CSRF)

Attack which forces an end user to execute unwanted actions on a web app in which they’re currently authenticated. This attack can force a user to perform requests like transferring funds, changing email address, run commands in the server (if admin), etc by just visiting a malicious site with some malicious code on it (if the vulnerability is present in the target site). It is effective when the attacker can’t read the HTTP response.

  • A relevant action
  • Cookie-based session handling (no other auth method is used so cookies are sent)
  • No unpredictable request parameters: the attacker doesn’t have to guess any values. For example, when causing a user to change its password, the function is not vulnerable if an attacker needs to know the value of the current password. (A valid action would be changing the account’s email to one that the attacker controls).

Understanding our target before the attack

Ok, so now that we know the basic concepts we can get into the juicy part! As I said before, I will be using a Pentesterlab environment just for demonstration purposes but you don’t need to do anything! The site will be running in my local network in 192.168.0.13 and as you will see later I will host my own “site” in 192.168.0.4.

main page
Registration as user/user
Login request. Not important
Logged in and Change Password page
CSRF token in html form
Change password request
Change password response
Change password request testing CORS vuln
Change password response testing CORS vuln

The Attack

Because I am working in my local network, I will first get my local IP address. You can get it on Windows by opening cmd and executing ipconfig to then look for your private IP address. I am working with Linux so I can just type ip a to find it in my wlps40 network interface →192.168.0.4.

Exploit: Part 1

Exploit: Part 2

Great, now we got the first part completed. The last thing we need is the CSRF password reset function to change the victim’s password and try our attack. Below, you will find the complete exploit code for the whole attack with the second part that I will explain now.

Wrapping everything up!

First, I will log into the vulnerable site again as we previously did with my user user and the password user987 .

Malicious.html
Complete attack requests
2nd request. CSRF Token extraction request
2nd Request Response. CSRF Token extraction response
3rd Request. Actual CSRF attack with the token included and the password we chose!! ACCOUNT TAKEOVER

Final words

I hope that you learned something interesting and useful today. Developers make mistakes everyday and bugs will always exist. It is a matter of looking at the right place and understanding what the application is doing and what did the developers intend to do when coding it.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Lihaft

Lihaft

Security Researcher | Bug Hunter @LihaftSec