Lazy XSS in the wild
Our journey begins and ends on a weekend a month ago. As per usual, I had decided to play around and do some bug hunting in the wild. This time, though, I didn’t go straight to the good stuff like SSRFs or RCEs. No, this time I wanted to just play around with something simple, yet common — XSS.
The task
As mentioned above, the task was simple and straightforward — find random websites, look for XSS, document it, report, and try to locate the same vulnerabilities on different sites.
The first part was easy, I just found the biggest websites in my country and searched for them.
The discovery
First, I started looking for possible attack vectors and almost instantly hoped on the comment sections of articles and the product review boards of products. After some time I discovered nothing!
I decided to take a break by looking for something else. Most sites had search fields that looked generic, so I decided to probe them for SQL injection vulnerabilities. Still nothing there. Or not? Wait, as I was looking at the search response, I saw that the search bar was kind of different, and on its right side was a string containing part of my SQL injection “payload”. That was a strange, right-click, inspect element, and here it was. I have accidentally the part of the payload that was after my quote into the HTML of the page.
It seems like the value property of the search field was accepting whatever was in the search bar directly, without filtering, sanitization, or encoding.
The exploit
The exploit was pretty simple. Insert
">in order to close the input field and then insert the payload. In our case
<script>alert(1);</script>and then press enter. And voilà, you get the browser message box!
To be fair, that’s a really simple vulnerability with a simple exploit. I was almost sure that I won’t be able to reproduce it anywhere else. But I decided to try it anyway. Guess what, it worked on more than 70% of the “targets” that I tried it on.
Conclusion
That quick hunt of mine proved that even large companies with great can have simple and easy-to-fix vulnerabilities.
Today’s takeaway is that you should always filter or encode the value parameter in your input fields because, otherwise, you will have an open XSS vulnerability.
PP: Feel free to check other stories on blog.
