If I'm not mistaken, there is a hypothetical situation where CSP can be used to the benefit of an attacker. Consider the scenario where: * the website contains a stored header injection vulnerability, * the website contains a XSRF vulnerability, and * the web client supports CSP.
To exploit a XSRF vulnerability, an attacker needs some way to direct the web client to the vulnerable URL. This usually requires a social engineering attack or a XSS vulnerability. A (stored) header injection vulnerability is generally not enough.
However, by injecting an X-Content-Security-Policy header with the policy-uri set to the vulnerable URL, the web client can be tricked into visiting the vulnerable URL.
In practice, this scenario will not often occur, as stored header injections are rare. And when it does occur, often also easier to execute attacks are conceivable. Still, there is a small risk.
A solution to this problem would be to require the policy document to have a fixed location on the website, instead of allowing it to be specified through a URI.
> Serge van den Boom wrote on 6/23/2009 8:13 AM: >> However, by injecting an X-Content-Security-Policy header with the >> policy-uri set to the vulnerable URL, the web client can be tricked into >> visiting the vulnerable URL.
> It would only work for those pages where a X-Content-Security-Policy > header has not already been set -- additional > X-Content-Security-Policy headers are ignored.
The injected header could be the first one though, with the genuine header being ignored.
> But beyond that, the proposed "Link" header would provide the same > attack surface, and can not be restricted to a known URI:
I was not familiar with that proposal, but skimming through it, it appears that these links are not resolved automatically, making this header less interesting for attackers. The same goes for the standard "Content-Location" header.
> On 2009-06-23, Bil Corry <b...@corry.biz> wrote: >> Serge van den Boom wrote on 6/23/2009 8:13 AM: >>> However, by injecting an X-Content-Security-Policy header with the >>> policy-uri set to the vulnerable URL, the web client can be tricked into >>> visiting the vulnerable URL. >> It would only work for those pages where a X-Content-Security-Policy >> header has not already been set -- additional >> X-Content-Security-Policy headers are ignored.
> The injected header could be the first one though, with the genuine > header being ignored.
True, but the attacker could simply split the header and issue a redirect to any page they desire and skip trying to exploit CSP entirely.
>> But beyond that, the proposed "Link" header would provide the same >> attack surface, and can not be restricted to a known URI:
> I was not familiar with that proposal, but skimming through it, it > appears that these links are not resolved automatically, making this > header less interesting for attackers. The same goes for the standard > "Content-Location" header.
Section 5 indicates it's "semantically equivalent to the <LINK> element in HTML" -- so presumably that means the browser will retrieve a stylesheet specified by the header before rendering the page.
> Serge van den Boom wrote on 6/23/2009 3:48 PM: >> On 2009-06-23, Bil Corry <b...@corry.biz> wrote: >>> Serge van den Boom wrote on 6/23/2009 8:13 AM: >>>> However, by injecting an X-Content-Security-Policy header with the >>>> policy-uri set to the vulnerable URL, the web client can be tricked >>>> into visiting the vulnerable URL. >>> It would only work for those pages where a X-Content-Security-Policy >>> header has not already been set -- additional >>> X-Content-Security-Policy headers are ignored.
>> The injected header could be the first one though, with the genuine >> header being ignored.
> True, but the attacker could simply split the header and issue a > redirect to any page they desire and skip trying to exploit CSP > entirely.
If you are thinking of adding a Location header: that shouldn't have any effect unless you have a 3xx status code, which you can't influence with a header injection. However, the attacker could end the header in their injection, and add a body of their own -- this was in fact what I was thinking of when I wrote "when it does occur, often also easier to execute attacks are conceivable." in my original posting. But it is conceivable that the header injection vulnerability only allows for the insertion of a small number of characters. In this case, CSP does actually make an exploit possible which wasn't otherwise realizable.
Though I agree that the likelihood of these circumstances occurring in practice is low. Still, the risk can be eliminated completely, if the loss of flexibility is deemed acceptable.
>>> But beyond that, the proposed "Link" header would provide the same >>> attack surface, and can not be restricted to a known URI:
>> I was not familiar with that proposal, but skimming through it, it >> appears that these links are not resolved automatically, making this >> header less interesting for attackers. The same goes for the standard >> "Content-Location" header.
> Section 5 indicates it's "semantically equivalent to the <LINK> > element in HTML" -- so presumably that means the browser will retrieve > a stylesheet specified by the header before rendering the page.
I see. If that is implemented in all browsers which implement CSP, then that would indeed make the CSP attack vector less interesting.
> If I'm not mistaken, there is a hypothetical situation where CSP can be > used to the benefit of an attacker. Consider the scenario where: > * the website contains a stored header injection vulnerability, > * the website contains a XSRF vulnerability, and > * the web client supports CSP.
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.
> To exploit a XSRF vulnerability, an attacker needs some way to direct > the web client to the vulnerable URL. This usually requires a social > engineering attack or a XSS vulnerability. A (stored) header injection > vulnerability is generally not enough.
> However, by injecting an X-Content-Security-Policy header with the > policy-uri set to the vulnerable URL, the web client can be tricked into > visiting the vulnerable URL.
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.
Given the numerous ways to initiate a GET to a particular URL, I don't believe CSP adds any significant new attack surface with the policy-uri directive. The attack scenario above also requires massive existing vulnerabilities in the victim site, which Serge points out up front.
The report-uri, however, does add a small twist. The report sent by the browser to the report-uri is a POST. I suppose this is a new way for an attacker to direct a POST at a CSRF vuln. However, the attacker will have no control over the POST body, only the URL. We can look into removing cookies and auth headers from the report request (not the report body) to address this risk if it seems valuable.
On 2009-06-24, Brandon Sterne <bste...@mozilla.com> 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.
|
