I was thinking about the problem of Cross Site Request Forgery and current mitigation strategies used in the Industry. In many of the real world applications I have tested so far, I see the use of random tokens appended as part of url. If the request fails to provide any token or provide a token with incorrect value, then the request is rejected. This prevents CSRF or any cross domain unauthorized function execution.
Uptil now, it was considered infeasible for an attacker to discover your CSRF token using Brute Force Attacks on the server.
The reasons being:
I am going to change this belief by showing you a technique to quicky find csrf tokens without generating alerts. This technique is a client side attack, so there is almost no network traffic generated and hence, your server and IDS/Web App Firewalls won’t notice it at all. This attack is based on the popular CSS History Hack found by Jeremiah Grossman3 years ago.
In this exploit, we discover the csrf token by brute forcing the various set of urls in browser history. We will try to embed different csrf token values as part of url and check if the user has visited that url. If yes, there is a good chance that the user is either using the same CSRF token in the current active session or might have used that token in a previous session. Once we have a list of all such tokens, we can just try our csrf attack on the server using that small list. Currently this attack is feasible for tokens with length of 5 characters or shorter. I tried it on a base16 string of length 5 and was able to brute force the entire key space in less than 2 minutes.
Some of the prerequisites for this attack to work are either
Proof of Concept is available here.
Before running the PoC, you need to change the url and csrftoken paramater values.
For testing using the defaults, you need to first visit one of the following urls, e.g.
Note: http://www.securethoughts.com and http://securethoughts.com are treated differently while storing in browser history.
For making this attack unfeasible,
And last, but not the least, XSS obliterates all the CSRF protections possible. So, get rid of XSS first.
I would like to thank Jeremiah for providing his insightful feedback on this post.