CSP flaws: cookie fixation

January 12, 2017

TL;DR: CSP can’t block <meta http-equiv="Set-Cookie" content="a=b">. An XSS vulnerability on a page with CSP can still be source for attacks that are based on writing cookies. Let’s take a look at some examples of cookie fixation issues.

Double-submit cookie example

Double-submit cookie is a technique some applications and frameworks use to deal with CSRF. It means that all forms must contain a token that is also set in a cookie. If the token sent in the form is not the same as the token in the cookie, the request is discarded. This technique is recommended by OWASP as an alternative to session-based tokens.

Because the attacker overwrites the token, they can use the new token in the form on their page and the CSRF protection is bypassed.

Double session example

It’s not rare to see applications using multiple session cookies. For example when the main application has one and the “under-application” has another.

If an attacker can fixate cookies, they could make the victim use the attacker’s session cookie in the main application. This would make the victim logged in as the attacker in the main application and as the victim in the under-application.

If the application fetches shipping data from the main application, the products the victim buys in the under-application would be sent to the attacker’s address.

Subdomain cookie XSS example

If there is a cookie XSS vulnerability on a subdomain, an attacker could use cookie fixation to set the XSS cookie, then redirect to the vulnerable page:

Conclusion

A couple of different issues can arise from cookie fixation, and even though many client-side vulnerabilities can be mitigated by CSP, this cannot. When developing an application that uses CSP and cookies, be wary of these kinds of attacks.