I am trying to validate recent results in a WebInspect scan for Cross-site scripting
Typically when I test for this I insert the below code into a user post field in a web page:
<script>alert("XSS Vulnerable!")</script>
Once inserted I reload the page. If vulnerable, the page will pop up an alert box saying “XSS Vulnerable!”

A recent scan I did gave me several critical results that I’m trying to corroborate:
Here is a sample sanitized result.
http://www.blah.com:80/my.asp?p=</XSS/*-*/STYLE=xss:e/**/xpression(alert('XSS'))>

Now to verify the result I paste the above url into a browser url field and load the page….BUT I seen nothing.
Am I correct in assuming that the page is not vulnerable.

Just so you know I’ve checked your knowledgebase and did not find an article addressing this point.

Any assistance would be appreciated.

My general experience is that the check you're seeing is bad. Whenever there is a postback (meaning the asp script posts to itself), the entire URL is included in the dynamically generated link. This is actually the desired and required behavior. The URL is usually escaped out so there is no actual harm. When I called support about it they agreed that it was a bad check and that they would take care of it.

Something else to keep in mind when trying to validate vulnerabilities is that applications can distinguish between a POST and GET parameter. Depending on the environment the scope of the variable might have to be taken into account. In PHP for example you could have two different variables with the same name ($_GET['varname'] and $_POST['varname']). If the application is developed expecting a variable as a POST then passing a value as a GET will simply get ignored.

I just had this happen yesterday with a customer who could not verify a SQL injection. He was putting the injection in the URL much like your example above and the application would just come back not doing anything. But when we would put the same value into the form field and submitting the form we would get the SQL error.
 

---

Jerry Pena
Product Support Engineer
HP Software (SPI Dynamics)
www.hp.com/go/software
Toll Free 866-774-2700 x2

One additional item to point out is how useful the HTTP Editor tool can be for your validation efforts, versus using just the browser.  It permits you to resend the original Request, as well as tinker with the values and resubmit again.  It also affords a View > History feature so you can browse back a few sessions to recall what you already attempted.  If you need to record the sessions for later reviw, you can run it through an instance of Web Proxy and capture the traffic there.

By right-clicking the session in the WebInspect GUI, you can open the Editor pre-loaded with the Request.