0

I have recently added CSP headers to a rather complex web application, being -report-only at first.

I got some noise from browser extensions in the report, but two incidents caught my eye especially:

There is one occasion where this got reported

blocked_uri: blob
column_number: 155
effective_directive: script-src-elem

and for the same user and at the same time:

blocked_uri: https://overbridgenet.com/jsv8/offer
effective_directive: connect-src
source_file: blob

So, obviously a JavaScript blob: got injected that made a connection to overbridgenet.com. That very domain has a questionable reputation to say the least.

That happened once.

Another thingy happened twice:

blocked_uri: https://secured-pixel.com/inj/default.php?ext=12&tt=472-xx-12
column_number: 489
effective_directive: script-src-elem

That happened twice for two different users in two different countries. The URL query was slightly different (ext=12&tt=472-xx-12 vs ext=12&tt=024-xx-12). The rest is the same including the column number.

I coulnd't find out much about secured-pixel.com. But it is somewhat suss as well. There's nothing accessible there and nothing to be found on Google about the business behind it, just about the domain itself. If I understand IBM's entry https://exchange.xforce.ibmcloud.com/url/secured-pixel.com right, they are saying that secured-pixel.com has/had a ton of DNS entries, i.e. changes them frequently and some of the DNS records are associated by IBM with Malware etc.

Now, in my understanding, two things could have happened:

  1. There might be a XSS vulnerability in the web application and some attackers exploited it.
  2. Some users might have malware or a malicious browser extension on their machine which injects JavaScript in some (all?) web sites.

If that assumption is true: How can I find out which is the case here?

What I've tried:

From the report itself, I could find out that there are no URL params in the URL that the user accessed (and I tried and checked that params would be in the report if there were any). So, reflected XSS via URL params can be excluded.

I then took a database dump of the data the users in question have acceess to and looked for blob: and secured-pixel. To cover a simple obfuscating technique like 'b'+'l'+'o'+'b'+':', I also searched for "b" and 'b'. However, I couldn't find anything, no matter what I tried. There might be more sophisticated techniques here, but I could not find a single trace of stored XSS.

The app in question is a React app. So, the number of XSS vulnerabilities should be pretty low. I checked all cases of

  • innerHTML
  • outerHTML
  • eval
  • new Function
  • setTimeout
  • setInterval

but I couldn't find anything dangerous.

I don't exactly know that the column numbers 155 and 489 refer to, but I checked all the source files in question at those columns (on line 1) but couldn't see anything which remotely resembles a XSS vulnerability.

I have Dependabot warnings for the GitHub repo in question. But it doesn't warn about any XSS related vulnerabilities.

What more can I check?

Improve this question
1
  • 1
    not an answer, but you might also want to check if you use createObjectURL() anywhere. I could see how that might be used to inject a blob and execute some WASM. Seems likely to be a browser extension, though. Commented Nov 26 at 19:40

1 Answer 1

Reset to default
1

There's also a third option: CSP violations can be triggered by entirely benign extensions or scripts. It's not always a XSS attack or malware.

When you search for secured-pixel.com, you'll find plenty of sites which explicitly mention this domain in their cookie policy. Of course this doesn't guarantee that the particular script at /inj/default.php is harmless – maybe the domain has been taken over by malicious actors at some point, maybe an attacker has managed to upload or manipulate the file. But there's at least some indication this might be benign and used for, e.g., tracking users.

In the case of overbridgenet.com, the search results appear to point to a browser extension. If this is the case, you cannot do anything about it except notify the user (if possible).

Unfortunately, there's no simple approach to investing CSP violations. Unless the report points to one of your own scripts as the source, it can be a lengthy and complex investigation.

  • If possible, contact the user and ask them whether they've installed any extensions or add-ons. This might allow you to reproduce the issue.
  • Search your entire application code for occurrences of the keywords.
  • Consider logging response bodies for, e.g., particular users. This allows you to search the actual JavaScript code that was transmitted to the client (including stored XSS).

In any case, don't expect “perfect” CSP reports which contain nothing but actual XSS attempts. People use all kinds of browser customizations (knowingly or unknowingly) which mess with webpages and can trigger CSP violations.

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.