In the target application, you may find an input field that could be vulnerable to stored XSS, but the server truncates the input to a number of characters that seems insufficient to carry out a meaningful XSS attack. This restriction can be bypassed by using JavaScript comment delimiters appropriately.
Solution
The strings Example 1 combine to be a cross-site scripting attack if they are all concatenated together. Although none of them is an attack in its own right, they are all pieces of a standard, basic XSS attack string.
Example 1. Using JavaScript comments to bypass field length restrictions
<script>/*
*/alert(/*
*/"XSS")/*
*/</script>
Also, try inserting the sequence in reverse order.
This will work in several scenarios. It will work when there are multiple length-restricted fields that are concatenated together with some punctuation or HTML tags in between. It will also work when multiple instances of the same input field are displayed on the same page. The author has seen several examples in real applications where a list of status codes, for example, are displayed on a page. The status codes are provided by an end user and are not checked at all. The status codes are displayed in a table defined in HTML like that shown in Example 2.
Example 2. Sample application output where status code length is restricted by server
...
<tr><td>statusCode1
</td></tr>
<tr><td>
statusCode2
</td></tr>
...
Example 3 shows the resulting script from Example 2.
Example 3. Sample HTML output after using JavaScript comments appropriately
<tr><td><script>
/*</td></tr><tr><td>*/
alert(
/*</td></tr><tr><td>*/
"XSS")
/*</td></tr><tr><td>*/
</script></td></tr>
In most browsers, including Internet Explorer 7 and Mozilla Firefox 3.0, this is equivalent:
As with other similar XSS tests, the application is vulnerable if you see an alert box pop up as a result of injecting your input.
Discussion
In scenarios where the server restricts the length of an input field but fails to perform proper input validation or output encoding, sequences such as example 1 can be used to inject JavaScript into the page. The cases where this attack would work include those where the inputs from the attacker are all displayed on a single page (in a table, for example). Anything between the /* and */ delimiters is treated as a comment, and thus, any HTML code that the site inserts between the attacker's inputs is commented out.
We will not discuss in depth the exact locations where comments are allowed in JavaScript, because the answer is implementation-dependent. Internet Explorer 7, for example, allows comments in many more locations than Mozilla Firefox 3.0. Some experimentation may be required to get the attack to work.
Vinay Jagtap
A hard core Technocrat with over a decade of extensive experience in heading complex test projects coupled with real time experience of project management and thought leadership. Extensive experience in Performance, Security and Automation Testing and development of automation frameworks and ability to setup and execute Global service centers and Center of Excellences for testing.
Get Free Email Updates to your Inbox!
