Today, in our favorite finding series, I will be talking about one of my favorite vulnerability classes. Cross Site Scripting (XSS) and how untrustworthy actors can use it to do unexpected things to your website.
Before we begin, I want to explain what XSS is for the uninitiated. The official definition is something akin to “malicious scripts injected into benign websites,” but what does that actually mean?
The basics: what is Cross Site Scripting?
The first thing to understand is how websites work (in a very simplistic fashion). When you request a web page using your web browser, a remote server pulls the webpage’s file out of its library, makes any server-side computations necessary, and then packages the page up as a chunk of new code that is received by the browser.
Your web browser then executes the commands of the code (HTML, javascript, etc.), generally in order, to render your page and make it look pretty. XSS happens when someone somehow adds new code (usually javascript) into the website in its raw form that was not included in the code delivered from the server. This can happen on your computer by a compromised browser or other malware, or by someone who has compromised the data traffic.
When the browser sees the script on the page, it does what it was made to do—execute the script—thereby adding unexpected or untrusted functionality to the rendered page.
With the basics out of the way, I’d like to share a story.
A long time ago, in a forum far away...
A few years ago, Packet Ninjas was performing an assessment on a website for a client. During the assessment, we noticed a forum section. Forums are generally default, off-the-shelf code installed separately from the main site and not generally of the highest-quality code. Since the basic functionality of forums is to allow users to add content (usually words or pictures to web pages, we wondered if we could somehow sneak some code into a post and get it to execute.
After observing the post request behavior and attempting to inject several scripts and tags, we came across the variable “Format=” in one of the post requests.
The value of this variable was set to “BBCode.” BBCode is commonly used for forums and is a set of limited tags based on HTML (but not full HTML) that allow users to add formatting to their messages to make them look better. At this point, I had a thought: What if we change this variable from the default “BBCode” to “HTML”?
Let the good times, and the bad script, roll
You may notice that in the Body variable above, I have entered some javascript that loads a video. Normally, this wouldn’t work as BBCode. But with the format set to HTML, the script executes without issue. I couldn’t believe it accepted that.
Yes, I posted an autoplay rick-roll video. Now, anybody who loads this page will be greeted by the time-honored tradition of the crooning voice of Rick Astley.
But did this work on anyone else’s end?
Yes! We know it did because the mods promptly removed my video for trolling and I received a warning. Even the best ninjas get spotted sometimes (when we intend to be).
No harm, no foul
Of course, Rick-rolling is a benign use of XSS. In lesser-friendly hands, this vulnerability could have been used for much more nefarious purposes. We included this in our findings report and recommended that they harden their forum code to disallow HTML use in their forum.
Hopefully, this gives a few of you some ideas when attempting to exploit Cross Site Scripting. If script tags are being filtered out or sanitized, check for other variables within the post parameters that can change how the payload is interpreted.
As always, see you next time with more fun findings. Keep plugging away at those websites and apps. Never give it up. It will never let you down. And never miss a chance to Rick-roll someone. ;)