I’m a firm believer that software can be bug-free. Rather than test every possible combination of inputs–which is impossible–we can test for the presence of certain kinds of bugs.
It’s reasonable to say, if a certain kind of bug exists, there’s a cause for it. We can then ask ourselves, “Where else could this show up?” and proactively fix weak code. We can also affirm that, if the conditions for causing the bug aren’t present in a part of the system, the bug cannot exist there.
Taxonomy Tuesday is meant to showcase a certain kind of bug, what its symptoms are, ways to test for it, and strategies for creating high-value automation to detect that bug again later. Coupled with Tripwire Automation and Change Detection, we can have a powerful test suite with less maintenance.
- Modifying how the webpage looks or acts,
- Collect cookie data,
- Redirect a user to a fake site, or,
- Communicate critical data back to an attacker’s site or server.
How It Works
As a webpage is displayed, the browser will interpret HTML as either stuff to display or stuff to execute.
If you open up most webpages and do a View Source on it, you may notice some [script] tags somewhere in the code. These are scripts that assist in displaying the webpage in a browser. The problem is when data is supplied to the webpage through a form, and the page interprets it as executable code instead of just straight text. When we don’t sanitize incoming data as text, we introduce the risk of allowing malicious code to be exercised on our webpage.
(and: apologies for enclosing the tag in angle brackets, like what you’d actually see. WordPress doesn’t easily let people put script tags in blog posts, and I spent too long trying to figure out how to do it already.)
How to Detect It
If you have a form with textfields, enter the following, replacing  with <>:
If you submit or save the data, and you see a popup like this:
…then you’ve successfully found a vulnerability! Congrats.
There are two main types of XSS attack–reflective and persistent.
Reflective ones are one-shot attacks. You can exploit the form and execute code, but to do it again, you have to enter the attack string in again. These can do some damage, but they’re somewhat contained to working for the attacker’s session only.
Persistent ones are the worse of the two. If your form enters data into a database and then retrieves it later, then the attack will occur for anyone that views the page, not just the attacker.
Catching It With Automation
As soon as you find a form field that shows this vulnerability, you can write fairly simple test automation around them.
For reflective attacks: For each field, enter the attack string, submit the form, and look for a popup.
For persistent attacks: Follow up by going to a page that would retrieve that field out of a database and display it. If you get a popup here, it’s an example of a persistent attack.
Most UI automation tools will fail with some kind of “UnexpectedPopupError” when a popup of this kind comes up, because these popups actually block any interaction with the webpage until you address it. So you may not even have to handle the case for looking for the popup–just let the test bonk on its own.