Reviewing Code for Data Validation - Revision history

Thomas Herlea: Added navigation to facilitate sequential reading online

2010-09-09T16:16:42Z

Added navigation to facilitate sequential reading online

KirstenS: /* Example–JavaScript */

2009-02-11T01:17:21Z

‎Example–JavaScript

KirstenS: /* Canonicalization of Input */

2009-02-11T01:11:14Z

‎Canonicalization of Input

KirstenS: /* Example-Perl */

2009-01-28T14:01:46Z

‎Example-Perl

KirstenS: /* Never Rely on Client-Side Data Validation */

2009-01-28T13:59:30Z

‎Never Rely on Client-Side Data Validation

KirstenS: /* Length Checking */

2009-01-28T13:58:10Z

‎Length Checking

KirstenS: /* Framework Example:(.NET) */

2009-01-28T13:56:22Z

‎Framework Example:(.NET)

KirstenS: /* Framework Example: (Struts 1.2) */

2009-01-28T13:54:08Z

‎Framework Example: (Struts 1.2)

KirstenS: /* Framework Example: (Struts 1.2) */

2009-01-28T13:53:46Z

‎Framework Example: (Struts 1.2)

KirstenS: /* Data Validation Strategy */

2009-01-28T13:46:26Z

‎Data Validation Strategy

@@ Line 1: / Line 1: @@
-[[OWASP Code Review Guide Table of Contents]]__TOC__
+{{LinkBar
@@ Line 423: / Line 428: @@
 The 3rd line of the script ensures that the characters are restricted to uppercase and lowercase for the user name. Should the value provided violate this, an invalid input error will be returned to the user.
 [[Category:OWASP Code Review Project]]

← Older revision		Revision as of 01:17, 11 February 2009
Line 399:		Line 399:

	The vulnerable script is displayed below:		The vulnerable script is displayed below:
−

	<SCRIPT>		<SCRIPT>

@@ Line 14: / Line 14: @@
 Input can be encoded to a format that can still be interpreted correctly by the application, but may not be an obvious avenue of attack.
-The encoding of ASCII to Unicode is another method of bypassing input validation. Applications rarely test for Unicode exploits and hence provides the attacker a route of attack.
+The encoding of ASCII to Unicode is another method of bypassing input validation. Applications rarely test for Unicode exploits and hence provide the attacker a route of attack.
 The issue to remember here is that the application is safe if Unicode representation or other malformed representation is input. The application responds correctly and recognises all possible representations of invalid characters.

@@ Line 316: / Line 316: @@
   print "You entered $value";
-The code blindly accepts and data supplied in the parameter labeled 'value'. To add to this problem of accepting data with no validation, the code will display the inputted data to the user. If you have read this far into the paper I hope the light bulb is now flashing above your head with the realisation that this particular vulnerability would allow a Reflected XSS attack to occur.
+The code blindly accepts data supplied in the parameter labeled 'value'. To add to this problem of accepting data with no validation, the code will display the inputted data to the user. If you have read this far into the paper I hope the light bulb is now flashing above your head with the realisation that this particular vulnerability would allow a Reflected XSS attack to occur.
 The 'value' parameter should validate the supplied data and only print data which has been 'cleaned' by the validation filter. There are multiple options available with Perl to validate this parameter correctly. Firstly, a simple and crude filter is shown below:

@@ Line 249: / Line 249: @@
 ==Never Rely on Client-Side Data Validation ==
-''Client-side validation can always be bypassed.''
+Client-side validation can always be bypassed.
-''Server-side code should perform its own validation. What if an attacker bypasses your client, or shuts off your client-side script routines, for example, by disabling JavaScript? ''
+Server-side code should perform its own validation. What if an attacker bypasses your client, or shuts off your client-side script routines, for example, by disabling JavaScript?
-''Use client-side validation to help reduce the number of round trips to the server but do not rely on it for security.''
+Use client-side validation to help reduce the number of round trips to the server but do not rely on it for security.
 '''Remember: Data validation must be always done on the server side.'''

@@ Line 241: / Line 241: @@
 Another issue to consider is input length validation. If the input is limited by length, this reduces the size of the script that can be injected into the web app.
-Many web applications use operating system features and external programs to perform their functions. When a web application passes information from an HTTP request through as part of an external request, it must be carefully data validated for content and min/max length. Without data validation the attacker can inject Meta characters, malicious commands, or command modifiers, masquerading as legitimate information and the web application will blindly pass these on to the external system for execution.
+Many web applications use operating system features and external programs to perform their functions. When a web application passes information from an HTTP request through as part of an external request, it must be carefully data validated for content and min/max length. Without data validation the attacker can inject Meta characters, malicious commands, or command modifiers masquerading as legitimate information, and the web application will blindly pass these on to the external system for execution.
 Checking for minimum and maximum length is of paramount importance, even if the code base is not vulnerable to buffer overflow attacks.

@@ Line 207: / Line 207: @@
    <asp:ValidationSummary runat=server HeaderText="There were errors on the page:" />
    <form runat=server>
-   <p>Please enter your User Id</p>
+   <p>Please enter your User ID</p>
    <tr>
        <td>

@@ Line 146: / Line 146: @@
 The field “username” is also case sensitive and refers to the String username in the LoginForm class.
-The “depends” directive dictates that the parameter is required. If this is blank the error defined in '''Application.properties'''. This configuration file contains error messages among other things. It is also a good place to look for information leakage issues:
+The “depends” directive dictates that the parameter is required. If this is blank the error defined in '''Application.properties'''. This configuration file contains error messages among other things. It is also a good place to look for information leakage issues.
 ===Error Messages for Validator Framework Validations===

@@ Line 97: / Line 97: @@
 This tells the framework to load the validator plug-in. It also loads the property files defined by the comma-separated list. By default a developer would add regular expressions for the defined fields in the validation.xml file.
-Next we look at the form beans for the application. In struts, form beans are on the server side and encapsulate the information sent to the application via a HTTP form. We can have concrete form beans (built in code by developers) or dynamic form beans. Here is a concrete bean below: e by developers) or dynamic form beans. Here is a concrete bean below:
+Next we look at the form beans for the application. In struts, form beans are on the server side and encapsulate the information sent to the application via a HTTP form. We can have concrete form beans (built in code by developers) or dynamic form beans. Here is a concrete bean below:
    package com.pcs.necronomicon

@@ Line 52: / Line 52: @@
 e.g.: an email address, we know it shall contain one and only one @. It may also have one or more full stops “.”. The rest of the information can be anything from [a-z] or [A-Z] or [0-9] and some other characters such as “_ “or “–“, so we let these ranges in and define a maximum length for the address.
-* '''Reject Known bad''': We have a list of known bad values we do not wish to be entered into the system. This occurs on free form text areas and areas where a user may write a note. The weakness of this model is that today known bad may not be sufficient for tomorrow.
+* '''Reject Known bad''': We have a list of known bad values we do not wish to be entered into the system. This occurs on freeform text areas and areas where a user may write a note. The weakness of this model is that today known bad may not be sufficient for tomorrow.
 * '''Encode Known Bad''': This is the weakest approach. This approach accepts all input but HTML encodes any characters within a certain character range. HTML encoding is done so if the input needs to be redisplayed the browser shall not interpret the text as script, but the text looks the same as what the user originally typed.
 '''HTML-encoding and URL-encoding user input when writing back to the client'''. In this case, the assumption is that no input is treated as HTML and all output is written back in a protected form. This is sanitisation in action.
 ==Good Patterns for Data validation ==