Serge van den Boom wrote: > 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 _______________________________________________ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
