QAInsight.net, QABlog.com, QABlog.net
Brent Strange's thoughts on Software Quality Assurance and technology

 
Sunday, January 08, 2006
 
 

JavaScript injection to change form values

 
 

Back in the day, before I started using proxies to bypass Web form validation (Achilles, Paros, Fiddler), I used to use the tool Paessler Site Inspector to help me bypass some types of form validation (one of Corillian QA's many security tests). Site Inspector uses JavaScript to access the DOM and allow you change the values. Simply put, the tool allowed you to do a JavaScript injection attack. A simple thing to do but Site Inspector made it simpler by wrapping a pretty UI around it. An article I found when perusing through the latest 2600: Hacker Quarterly at Barnes and Noble the other day reminded how truly easy this was to do without a tool. Provided below is a simple example of a JavaScript injection attack:

Consider the following text field in a balance transfer form:

<input name="amount" type="text" maxlength="3">

Let's say this form has a $999 transfer limit controlled by the HTML maxlength property set to 3 (yes, it's cheesy & foolish validation).

From the browser URL bar we can easily bypass this check by using the DOM through JavaScript to change the amount value:

Example 1 (using form name and form textbox element name):
javascript:document.forms['transfer'].elements['amount'].value = '10000'

Example 2 (using the index number of the form and element arrays):
javascript:document.forms[0].elements[0].value = '10000'

You'll get a JavaScript error if your syntax is incorrect or are attempting to access an object that doesn't exist. If you have no error you can double check that the value actually stuck by displaying it in a JavaScript alert. You can do this by typing the following in the browser URL bar:

javascript:alert(document.forms[0].elements[0].value)

The expected result of the test case would be that even though you could do this JavaScript injection attack at the UI, the duplicated server side validation would catch and stop the attack. If it isn't stopped on the server side then you have yourself a serious defect!

Happy testing! I'll talk about bypassing validation with a proxy another day...

 
   
   
   
Comments are closed.