XSRF via CSP policy-uri
Serge van den Boom
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.
Regards,
Serge
Serge van den Boom
> 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.
>
> 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.
Serge
Bil Corry
> 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.
- Bil
Serge van den Boom
> 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.
Serge
Brandon Sterne
> Hi,
>
> 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.
Regards,
Brandon
Serge van den Boom
> 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