Week 11 - XS-Search: Cross-Origin Enumeration
Last updated
Last updated
It’s hard to believe we’re already 11 weeks into the Web series! Stay tuned for a PDF copy of my first 10 week’s tips all in one place. For this week, we’ll be covering the XS-Search technique and how it can be used to abuse Chrome’s deprecated XSS-Auditor. The vulnerability is centered around the following server response header:
X-XSS-Protection: 1; mode=block
If this header is enabled on your server, it will prevent responses containing XSS payloads from loading properly. Instead, the page will display an error like “This page isn’t working… ERR_BLOCKED_BY_XSS_AUDITOR”.
Now imagine we have an attacker site hosted at {{attacker-url}}. We are targeting a vulnerable site existing at {{vulnerable-site}}. The vulnerable site has a page called ‘search.php’ that takes user input through a GET parameter and searches for the existence of a file. If the search returns a file, the page displays a message “Your file was found!” and includes the following JavaScript: <script>console.log(“File found”)</script>. If the search does not return a file, the page just displays “No file found.”
A key thing to note from the paragraph above is the ‘search.php’ page includes JavaScript when a file is found. We can specify this exact JavaScript in a separate GET parameter and trick the XSS-Auditor into thinking we found a Cross-Site Scripting, since JS specified in the request parameter matches JS in the page.
Now within our {{attacker-url}}, we embed an <iframe> with the source pointed to {{vulnerable-site}}/search.php?q=abc&xss=<script>console.log(“File found”)</script>
When a vulnerable user visits {{attacker-url}}, the <iframe> is rendered. If the <iframe> loads normally (meaning the XSS-Auditor was not triggered) then we know we received the “No file found” message. But if the XSS-Auditor was triggered, then the <iframe> will issue an onload event/error, letting us know the JavaScript was included in the page and a file does exist with the title “abc”.
Using this technique, we can guess a filename or CTF flag character by character, simply by taking advantage of the deprecated XSS-Auditor. It is important to note that the fragment at the end of the <iframe> URL () must be changed to a different string for the frame to load a second time, which allows the error to occur.
Special thanks to for recommending this vulnerability. I had never seen it before and really enjoyed studying it. Please check out the linked YouTube video in the comments for a much more practical example. My attempt here was to make this easy to understand, as many online resources make XS-Search difficult to learn.
