I am currently working on exploiting a potential DOM based XSS on a web app. Currently all of my XSS attempts have been thwarted by Internet Explorers XSS auditor, even after disabling it. While investigating I noticed that the query parameter was outputting weird results if I replace the "=" with "[ ]" which reflects on the web app.

Example site: www.example.com/search/?q=apples

 Output: expected

Removing the "=": www.example.com/search/?q[1]

 Output: {"1"=>nil}

The {"1"=>nil} reflects in the website, so the URL is being interpreted with odd results in the website.

Another example: www.example.com/search/?q[Object.prototype.foo][cool]=chill

Output: {"Object.prototype.foo"=>"chill"} permitted: true>}

From my understanding, the above is Ruby. Could this be exploited with the DOM based XSS?

Currently the vulnerable libraries the web app is using are: jQuery v1.12.4 React v0.13.3 React (Fast path)v0.13.3 Moment.js v2.13.0

Any help would be greatly appreciated.

1 Answer 1


If your exploit works but is being stopped by the XSS auditor then you have found a real and reportable XSS vulnerability. The XSS auditors are very finicky, all of them have workarounds, and they have already been deprecated in the latest versions of Chrome. Therefore, if you are seeing the XSS auditor take action then you have found an XSS vulnerability that will be causing real world trouble shortly.

If you're doing penetration testing, I would try to figure out how to disable the XSS auditor in your browser. Just pretend it isn't there, because for the purposes of bug bounties it really shouldn't matter.

Of course it is always possible that a company somewhere may reject a vulnerability report because when they try to reproduce it they are stopped by the XSS Auditor. However rejecting a vulnerability for that reason would represent a gross misunderstanding of the purpose of the Auditor, and the simple fact that browsers have started removing it because it causes more problems than it solves. It is certainly a point I would argue. The Auditors are meant to be a stopgap measure, not an actual line of defense (and will be gone soon enough). However if a company stands firm in rejecting a vulnerability report because of the Auditor stepping in, then you would obviously have to find a workaround for it. As I mentioned, all the Auditor's have workarounds, but they are also browser dependent which can make it a bit tricky.

  • Thank you. I'm happy to read what you wrote and bummed out too. I have actually discovered many XSS exploits that Internet Explorer catches. It'll redirect the page to just a "#" symbol and say: Internet Explorer has modified this page to prevent cross-site scripting. Unfortunately, you can't actually disable the XSS filter for whatever reason. If you strip all the security features from Internet Explorer, Windows will bug out and harass you to re-enable all the toggled off features.
    – Jayson
    Jan 10, 2020 at 17:33
  • @Jayson I would try a new browser then. You can disable the XSS auditor in chrome. Also, if you are using a proxy you can also configure it to send down a header to disable the Auditor - that might trick IE: developer.mozilla.org/en-US/docs/Web/HTTP/Headers/… Jan 10, 2020 at 17:58
  • Thank you! Still no luck but I'll figure this out somehow.
    – Jayson
    Jan 12, 2020 at 0:06

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .