On 2009-06-24, Brandon Sterne <[email protected]> wrote: > So the premise is that the site already has a CSRF vuln and a header > injection vuln, and Content Security Policy provides a new way for an > attacker to forge a request from the victim to the target site.
Right. > How did the attacker get the victim to visit the URL with the header > injection vuln in the first place? If the attacker could get this far, > they could skip the CSP step altogether and have the victim go straight > to the CSRF URL. The victim doesn't have to visit the URL with the header injection vulnerability, as I'm talking about a *stored* header injection vulnerability. An example: A web application allows users to submit their own content. With new content, the user may specify its language from a drop-down box. When another user views the content, the language is sent along in the Content-Language header. Now the developers of the web appliction forgot to add code to check server-side whether the specified language is valid. The attacker manipulates the language field of the submission form, and tries to use it to inject some dangerous URL. But as the Content-Type header is already set to something harmless, there is no point in manipulating the body. But policy-uri to the rescue! The attacker sets the language to "en\n X-Content-Security-Policy: policy-uri http://example.org/setpass?pass=hello";. Now when someone views the uploaded content with a CSP-capable browser, the security-policy-but-not-really is requested. And because the website uses the Referer header for CSRF-protection, and the browser sets the Referer header to the originally requested page when requesting the policy-uri (and because the password change form did not ask for the old password), the CSRF-protection fails, and the password is changed. So once the attacker has set the trap, there is no need to trick people into visiting some specially crafted URL while they have a session open on the site; anyone who passes by, in their own time, is pwned. Regards, Serge _______________________________________________ dev-security mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security
