> For the complete documentation index, see [llms.txt](https://www.webhackingtips.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://www.webhackingtips.com/weekly-tips/week-11-xs-search-cross-origin-enumeration.md).

# Week 11 - XS-Search: Cross-Origin Enumeration

## Abusing Chrome's Deprecated XS-Auditor

It’s hard to believe we’re already 11 weeks into the Web [#Hacking](https://www.linkedin.com/feed/hashtag/?keywords=hacking\&highlightedUpdateUrns=urn%3Ali%3Aactivity%3A6911681650741407744) 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.”\
&#x20;\
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.\
&#x20;\
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>[#leak](https://www.linkedin.com/feed/hashtag/?keywords=leak\&highlightedUpdateUrns=urn%3Ali%3Aactivity%3A6911681650741407744)\
&#x20;\
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”.\
&#x20;\
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 ([#leak](https://www.linkedin.com/feed/hashtag/?keywords=leak\&highlightedUpdateUrns=urn%3Ali%3Aactivity%3A6911681650741407744)) must be changed to a different string for the frame to load a second time, which allows the error to occur.\
&#x20;\
Special thanks to [Nick Smith](https://www.linkedin.com/in/ACoAACnVDR0BiQ_xJVI7pSsuXDNBTpl1SSAa8xA) 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.

![](/files/pMFwd5KxOos3SyPEsFxt)

![SRC: https://www.youtube.com/watch?v=HcrQy0C-hEA](/files/rkjGfV3pSsI6YlD0fY8O)