Really Simple XSS and a Solution

Really Simple Cross Site Scripting

I came across a site tonight actually that infuriated me quite a bit because the site looked to be mature, had been around for quite some time, yet I found a really simple XSS vulnerability in one of their forms. This bothers me as a security professional because if they have this type of a vulnerability, where else is their code insecure?

To illustrate the point and situation that I encountered I have produced an example. If you feel like experimenting with the vulnerability yourself, visit Really Simple XSS. Or you can just follow along with what I'll show you.

Here you have a basic input form that takes some input which could actually be anything, a user name, password, whatever you want it to be. When the user behaves and the form works correctly as you can see, the input page redirects your input to a page that does some processing, in my case the processing page simple echoes the output back out to you, as observed below.

This page has an XSS vulnerability in it, immediately because all this page does is echo the data back, it's suspicious but not 100% obvious. The easiest way for me as a primitive attacker is to test my theory out, watch what happens when I test that theory.

As you can see from the images above I attempt to test my theory with a little bit of JavaScript. Notice how in the second image that, my JavaScript is appearing as the value for the input parameter exactly as I entered it on the page before? This tells me I don't even have to waste my time going through the first page, I can immediately send out a link with whatever XSS vulnerabilities I want to my potential victims, I just have to decide how I want to exploit the vulnerability I've found, whether it be through JavaScript, HTML, or some other mechanism. Fortunately in this case the input is not actually being stored in a file or a database so the attack will only attack one victim at a time, once they click on the link. If the input was stored anywhere!, cookie, db, file, web service, and loaded every time, that would be great for me as an attacker because I'd only have to attack the site once, and have my input recalled for every user who visited the site. It's worth noting that I don't actually have to keep the user on the page, my JavaScript could do a new window open or a window redirect. If that were the case I could navigate them away from the page every time without accomplishing the goal of the page.

Another Detection Mechanism

I understand that in a large web app, manually testing every form for a potential XSS issue is unrealistic for QA and even more so for developers/engineers. I am a huge fan of the ZAP attack Proxy, this is an intercepting proxy that is quite powerful.

As you can see with the ZAP attack proxy, I fire it up, and enter the URL of the site that I want to scan (attack). Zap will test the site against standard definitions and attack behaviors.

When Zap is done its scan, anything that the proxy thinks is worth my attention shows up in the alerts window. As you can see I have some XSS concerns here, three of them to be exact.

When I click on one of the alerts I get a very detailed description of the issue, it tells me the vulnerability, the input parameter(s) that were vulnerable, and where I should have caught this issue for remediation, as well it provides me with some references for more info should I wish to follow up on the issue.

The dangerous thing with the ZAP proxy is, as much as it can be used for beneficial purposes, it can also be used for malicious purposes. An attacker is just as capable for downloading ZAP and scanning your website with it to find all the vulnerabilities that one can detect. The attacker now has a very good idea where to start hitting your site for potential XSS vulnerabilities, and what URLs they can take advantage of.

A Remediation

One might think that a solution to this problem should be implemented on the first input page and scan inputs before the page is redirected, well they would be wrong! Remember how earlier I said that I did not process a request through the first input page, I could take advantage of the vulnerability directly on the second page? That's where the solution needs to come from. As of .NET 4.0 Microsoft does a decent job with .NET projects to scan HTTP requests and block them if they contain potential XSS issues.

I tend to not trust this approach because:

1. It can be turned off in the web.config
2. It can be turned off at the page level

This approach only works within the confines of a .NET Web app. The only safe way to re-mediate an XSS scripting attack, is through diligent white listing of all inputs. That's a discussion for another time. In the mean time, would developers and QA please start testing their projects? It only takes a few minutes to run a ZAP attack scan, which can quite possibly save your firm and you a lot of trouble in the future! Tune in soon, as I dig deeper into more complex XSS vulnerabilities, how they are created, how they are exposed, and how to prevent them!