The easter bunny came by Zerocopter’s offices today and while he didn’t leave any eggs, he did leave 5 ways to bypass CSRF protection for you!

Brace yourself..

1. Verify that the token is really random.

The CSRF token isn’t always as random as it seems to be. For example, does "c4ca4238a0b923820dcc509a6f75849" look like a good CSRF token to you?

If you think that is does….. c4ca4238a0b923820dcc509a6f75849 is the md5 equivalent of "1". Doing a quick Google Search for a CSRF token might help you to gain more information about how the tokens are generated.

Sometimes the CSRF token is stored in a cookie. When there is a vulnerability that allows you to set/read a cookie, for example a cross-site scripting or a HTTP response splitting scenario, you might be able to overwrite the existing token with a weak one.

3. Cross-site scripting

With a cross-site scripting you are allowed to read content from the same domain, so you are likely able to read the CSRF token from CSRF protected post.

4. Overly CSRF protection

One method to make sure that the CSRF token is always attached to a POST request is to add it automatically to a request using JavaScript or a server side method. If you find a way to make a post request to your own website (often possible via login systems or misinterpreted file paths), then you might be able to capture the CSRF token.

5. crossdomain.xml

A cross-domain policy file is an XML document that grants a web client, such as Adobe Flash Player or Adobe Acrobat, permission to handle data across domains. If the cross-domain file is configured weakly -with for example a wildcard ("*") or an expired domain- it might be possible to read the CSRF token using a simple flash file.