Intro:

Series Index

1. Cross Site Scripting Indepth
2. XSS Vectors Exploited

I am back to posting about security information again, I’ve decided to do a series on cross site scripting (xss). My motivation for this is pretty simple, developers, engineers, server admins, qa, still don’t simply get it. How do I know? I continue to see multiple examples of xss vulnerabilities today; I am going to document xss from the really simple to the really complex and come up with a few ways to address such an attack, as well as provide some info on how developers & QA folks alike can test for such an attack.

 

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 there code insecure?

To illustrate the point and situation that I encountered I have produced an example. If 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 echos 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 with from the images above I attempt to test my theory with a little bit of JavaScript. Notice how in the second image that, my JavasSript 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, webservice & 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 for 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 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 it’s scan, anything that, proxy thinks is worth my attention shows up in the alerts window, As you can see I have some xss concerns here, 3 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 of the vulnerability the input parameter(s) that were vulnerable, and where I should have caught this issue to remediation it 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 URL’s they can take advantage of.

A Remediation

One might think that  a solution this problem would should be implemented on the first, input page and to scan the inputs, before the page is redirected, well they would be wrong! Remember how earlier I said, that i did not to process a request through the first input page, I could take advantage of the vulnerability directly on the 2nd 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 a 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 & 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!