Red Teaming: Flaring CSP Report-URIs

Red Teaming: Flaring CSP Report-URIs

TL;DR: This is a flaring script for report-uri. It will distract the blue team by sending random false positives.

No question: CSP and report-uri is a strong team and it helps the blue team detecting you. So in the latest Red Team Assessment we had an externally available employee portal. It was kind of self-written, although I assumed it was built around a template engine. We also had a few other external sites. Perfect material for XSS. But wait – there is more: Multiple deployed CSP. Even if it wasn’t that sophisticated, it might make your life as a red team member harder.

In my mind’s eye I could see the blue team checking their reports while the assessments was going on.

But what if this could help us in some way? While you may trigger a WAF to report some false positives, with the report-uri this is even easier: You literally can send your own “alerts”. And you can determine when and what to be reported.

Let’s Flare

So my Idea was simple: Let’s feed something to the blue team to keep them busy.

A Flare is used to distract heat seeking missiles – that’s exactly what we gonna do. So I came up with the name flaReportUri for the script I’ve developed.

CSP – Content Security Policy

If you’re into pentesting, I assume you know about the Content Security Policy. It looks somewhat like this:

If the Browser determines a violation against those rules he will block them (if stated in “Content-Security-Policy”) and Report the violation to report-uri. If the Policy is within “Content-Security-Policy-Report-Only”, he won’t block the violation, but still report it. This is useful for testing the policy.

As you can see, I’ve used Scott Helmes Service for this example. You can see what your Browser is doing, if you visit (and have a fuzzing proxy enabled). The Browser will post something like this to the report-uri:

In the Report it will look like this:

So we will need different violations for the blue team to draw their attention away.

First of all, I randomised the agents from the following list:

Second, I randomised the violation script sample, I took a few lines from here (kudos to you sir!)

I also counted the lines in the document, to return a feasible number for line-number.

I stored the variables in text-files so it can be easily adapted.

Now, lets see what the script does to the Report:

The little variations are owed to the very small CSP itself.  In real life, the variations are much bigger. Also the script is not perfect – but it did its job: It distracted the blue team for like 6 hours (in the debriefing the blue team said, it kept them quite busy until the realised they cannot trust the reports).  In the first moment they searched for XSS vulnerabilities in the external Web App.

While they were busy we found a different way in, which I’m not allowed to disclose. I know now, that they have recognized the network monitoring alert, but were to distracted from the Report-URI reports (which was exactly what I hoped for).

You can download the FlareScript here:

Or just copy paste and create user-agent/violation/etc files for your own:


Lessons learned

  1. In the Debriefing the blue team mentioned the additional stress that this situation caused. Stress is a crucial factor in a red team assessment – as well as it is in a real life defense situation.
  2. Report-URI is a powerful tool, but the detection and alerting is delegated to the browser which makes it vulnerable for intended false positives.
  3. If the alerts are too obvious you might get distracted (but you might not ;-)).
  4. It would be great, if report_uri displays and let you filter the IP address of the sender
  5. If you receive reports, check your server logfiles, if the alerts are plausible

Comments are closed.