Testing XSS - Special Cases

For testing Cross-Site Scripting it is required to prove that the server reflects user data without validating it (In most cases this would be a JavaScript reflected back from the server). But, testing for XSS frequently requires a knack of manipulating test cases.

For example if we have a page which displays values within text boxes, the HTML for the form would be as follows:

<input type = text name="address" value="xyz" >

In the above HTML if the value was “<script>alert("Vulnerable to XSS");</script>”, it would not bring up a alert pop-up box. This happens because the input is returned from the server in the value parameter, hence the above HTML with a script injection would look like:

<input type = text name="address" value="<script>alert("Vulnerable to XSS");</script>" >

Effectively the value parameter is “<script>alert(”, and this is displayed in the text box.

Now how do we test for XSS in such a situation? It is as simple as forming a test case that is well-formed with the HTML and does not include the script as the value of the “value” parameter. So for the above example the following test cases may be used:

Test Case:

"><script>alert("Vulnerable to XSS "); </script><"

The resulting HTML would look like:

<input type = text name="address" value=" "><script>alert("Vulnerable to XSS ");</script><"" >

So if you see, we have effectively closed the HTML input tag after inserting our script. This would allow us to test if the form is vulnerable to XSS or not. If we get an alert pop-up then it proves that the server returns the user input without validation and hence makes that particular form a candidate for an XSS attack.

Very simple but effective technique to detect pages displaying text fields without validation. So happy appsec auditing… :-)

Plynt provides penetration testing and code review services to clients worldwide. If you are interested, please contact us for a quote. We’ll get back to you within one working day.

Add yours.closed for this post.