CSRF Tokens using macros in Burp suite (I)

CSRF is a quite old vulnerability but still today is quite popular. If we take a look at the last OWASP top ten available, we can locate it in the 8th place. Honestly, I don’t think this has changed too much. There is still a great misunderstanding on what CSRF is and what is really a good implementation to prevent it. I think the information in the OWASP CSRF prevention cheatsheet is really good about this matter so, please refer to it if you haven’t done it before.

I will give you some insights on the vulnerability itself so you can understand the root of the vulnerability. The problems stands in the possibility of an attacher to fake a request on behalf of an authenticated user. This would allow him to take advantage of certain operations available in the buggy application at the expense of the victim.

There are some conditions that have to be meet in order to take advantage of the vulnerability.

  1. The attacker needs access to the same application and the same operation lacking of protection than the victim. If not he can’t grab the necessary request to craft the malicious one.
  2. The attacker has to trick the victim into visiting a specially crafted link once the victim has performed the authentication.

The next diagram summarises the vulnerability.

screen-shot-2016-11-04-at-19-04-27
CSRF in a visual way

As you can see the attack is not the easiest one to execute but the consequences can be arbitrary impacting.

The correct way to protect against this attack is generating a random and non-guessable token server side per each transaction and user. This token is known as nonce token and is invalidated right after its use. This token is normally sent to the browser in response to a get request and sent back to the application in a post request as a hidden field. This way is impossible for an attacker to craft the request which the victim has to access to once authenticated. Even when the attacker was able to craft the request and make it available with a token, that token would be generated for the attacker’s user and not for the victim which causes the attack to fail.

If you find a CSRF protection correctly implemented, you will find really difficult to properly perform a DAST (Dynamic Application Security Testing) since you need to retrieve a valid token per each post request directed to the server.

In the next posts we are going to explore how to automate this kind of scan using macros in burp suite.

We are going to use as a example one available thanks to John Paulin in the nvisium blog:

https://nvisium.com/blog/2014/02/14/using-burp-intruder-to-test-csrf/

You can access the service through this link to start exploring it. We will get hands on in the next post.

http://sleepy-tor-8086.herokuapp.com/

++Security

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s