CSP 1.1 (Content Security Policy) is a suite of directives for browsers to better protect against Cross-site Scripting (XSS) and Clickjacking attacks. Browsers supporting CSP headers will ignore X-FRAME-OPTIONS headers if framing directives are in place. CSP also provides more advanced controls for client side DOM access.
One of the capabilities of CSP 1.1 is to allow for browsers to send ‘violation reports’ to a web server in the event of a violation of any directives specified in the policy. So if one of your users is the victim of a clickjacking attack, their web browser will let you know some details of the attack. While this can be very useful to security teams to know if the policy is effective, it’s also ripe for abuse. Below shows a CSP header including a report URI:
X-Content-Security-Policy: default-src self;
report-uri http://reportcollector.example.com/collector.cgi
The reporting URI instructs browsers where to send a POST request with violation info. In the event of an attack, or any violation of CSP directives, the user agent is instructed to craft a JSON object detailing the violation and POST it to the reporting URI. The CSP specification shows an example report:
{
"csp-report": {
"document-uri": "http://example.org/page.html",
"referrer": "http://evil.example.com/haxor.html",
"blocked-uri": "http://evil.example.com/image.png",
"violated-directive": "default-src 'self'",
"original-policy": "default-src 'self';
report-uri http://example.org/csp-report.cgi"
}
}
This functionality suffers one major weakness, which is there is no guarantee of authenticity of the reports. An attacker can very easily send an administrator clicking an entire trail of malicious links in attempt compromise an admin system. Here are a few possible attack scenarios:
- Attacker crafts fake violation reports with malicious links. The links are loaded with BeEF modules to attack and possibly compromise the machine used to view logs.
- Attacker fuzzes payloads within the violation report to attack the backend application used to handle reports.
- Attacker floods the reporting URI with invalid data in a Denial of Service attack.
- Attacker creates several fake violation reports with innocuous but unique links which he or she owns. The attacker monitors web logs and waits for security teams to review violation reports. The attacker may learn of new networks by which the security team used to connect.
Conclusion
Violation reports should be implemented carefully. While this functionality is generally considered “an extra layer of protection”, there are still more things to consider before using this in production. Code used to handle incoming violation reports should be subject to the same web application testing as the rest of the application. A persistent XSS bug in this code will likely have elevated consequences. It should be understood that the reports have no guarantee of authenticity, and there is a very high incentive for an attacker to use this to send malicious links directly to admin staff.
Further reading:
https://developer.mozilla.org/en-US/docs/Security/CSP/Using_CSP_violation_reports