Capturing User Data: HTML Forms
The other principal way in which applications use client-side controls to restrict data submitted by clients occurs with data that was not originally specified by the server but was gathered on the client computer itself. HTML forms are the simplest and most common mechanism for capturing input from the user and submitting it to the server. In the most basic uses of this method, users type data into named text fields, which are submitted to the server as name/value pairs. However, forms can be used in other ways, which are designed to impose restrictions or perform validation checks on the user-supplied data. When an application employs these client-side controls as a security mechanism, to defend itself against malicious input, the controls can usually be trivially circumvented, leaving the application potentially vulnerable to attack.
Length Limits
Consider the following variation on the original HTML form, which imposes a maximum length of 3 on the quantity field:
<form action=”order.asp” method=”post”>
<p>Product: Sony VAIO A217S</p>
<p>Quantity: <input size=”2” maxlength=”3” name=”quantity”>
<input name=”price” type=”hidden” value=”1224.95”>
<input type=”submit” value=”Buy!”></p>
</form>
Here, the browser will prevent the user from entering any more than three characters into the input field, and so the server-side application may assume that the quantity parameter it receives will be no longer than this. However, the restriction can be easily circumvented either by intercepting the request containing the form submission to enter an arbitrary value, or by intercepting the response containing the form to remove the maxlength attribute.
Script-Based Validation
The input validation mechanisms built into HTML forms themselves are extremely simple, and are insufficiently fine-grained to perform relevant validation of many kinds of input. For example, a user registration form might contain fields for name, email address, telephone number, and ZIP code, all of which expect different types of input. It is therefore very common to see customized client-side input validation implemented within scripts. Consider the
following variation on the original example:
<script>
function ValidateForm(theForm)
{
var isInteger = /^\d+$/
if(!isInteger.test(theForm.quantity.value))
{
alert(“Please enter a valid quantity”);
return false;
}
return true;
}
</script>
<form action=”order.asp” method=”post” onsubmit=”return
ValidateForm(this)“>
<p>Product: Sony VAIO A217S</p>
<p>Quantity: <input size=”2” name=”quantity”>
<input name=”price” type=”hidden” value=”1224.95”>
<input type=”submit” name=”buy” value=”Buy!”></p>
</form>
The onsubmit attribute of the form tag instructs the browser to execute the ValidateForm function when the user clicks the submit button and to submit the form only if this function returns true. This mechanism enables the client-side logic to intercept an attempted form submission, perform customized validation checks on the user’s input, and decide whether to accept that input accordingly. In the above example, the validation is extremely simple and checks whether the data entered in the amount field is an integer. Client-side controls of this kind are usually trivial to circumvent, and it is normally sufficient to disable JavaScript within the browser. If this is done, the onsubmit attribute is ignored, and the form is submitted without any custom validation.
However, disabling JavaScript altogether may break the application if it depends upon client-side scripting for its normal operation (such as constructing parts of the user interface). A neater approach is to enter a benign value into the input field in the browser, and then intercept the validated submission with your proxy and modify the data to your desired value.
Alternatively, you can intercept the server’s response that contains the JavaScript validation routine and modify the script to neutralize its effect — in the previous example, by changing the ValidateForm function to return true in every case.
Disabled Elements
If an element on an HTML form is flagged as disabled, it appears on-screen but is usually grayed out and is not editable or usable in the way an ordinary control is. Also, it is not sent to the server when the form is submitted. For example, consider the following form:
<form action=”order.asp” method=”post”>
<p>Product: <input disabled=”true” name=”product” value=”Sony VAIO
A217S”></p>
<p>Quantity: <input size=”2” name=”quantity”>
<input name=”price” type=”hidden” value=”1224.95”>
<input type=”submit” value=”Buy!”></p>
</form>
This includes the name of the product as a disabled text field and appears on screen as shown in Figure -1.
Figure -1: A form containing a disabled input field
The behavior of this form is identical to the original example: the only parameters submitted are quantity and price . However, the presence of a disabled field suggests that this parameter may originally have been used by the application. Earlier versions of the form may have included a hidden or editable field containing the product name. This would have been submitted to the server and may have been processed by the application. Modifying the name of the product may not appear to be as promising an attack as modifying its price. However, if this parameter is processed, then it may be vulnerable to many kinds of bugs such as SQL injection or cross-site scripting, which are of interest to an attacker.
..NEXT is..Capturing User Data: Thick-Client Components……..,,,,,,,
