Testing for User Input as a Loop Counter (OWASP-DS-005)

From OWASP
Revision as of 16:34, 12 November 2006 by Mmeucci (Talk | contribs)

Jump to: navigation, search

[Up]
OWASP Testing Guide v2 Table of Contents

Contents


Similar to the above problem of User Specified Object Allocation, if the user can directly or indirectly assign a value that will be used in a loop function, this can cause problems on the server.

Code Example

The following is an example of vulnerable code in Java:

public class MyServlet extends ActionServlet {
   public void doPost(HttpServletRequest request, HttpServletResponse response)
		   throws ServletException, IOException {
	. . . 
	String [] values = request.getParameterValues("CheckboxField");
      // Process the data without length check for reasonable range – wrong!
	for ( int i=0; i<values.length; i++) {
		// lots of logic to process the request
	}
	. . . 
       
   }
   . . . 
}

Testing Black Box

If a request is sent to the server with a number that will, for example, be used to read many similar name/value pairs that change only by an ending value (for example, sending “3” to read input1, input2 and input3 name/value pairs), this can cause the application to loop for extremely large periods. The tester in this example may send an extremely large, yet well-formed number to the server, such as 99999999.

Another problem is if a malicious user sends an extremely large number of name/value pairs directly to the server. While the application cannot directly prevent the application server from handling the initial parsing of all the name/value pairs, to prevent a DoS the application should not loop over everything that has been submitted without putting a limit on the number of name/value pairs to be handled. For example, multiple name/value pairs can be submitted by the tester, each with the same name, but with different values (simulating submission of checkbox fields). So looking at the value of that particular name/value pair will return an array of all the values submitted by the browser.

If it is suspected that such an error may have been made in the application, the tester can submit an increasingly large number of repeating name/value pairs in the request body with a small script. If there is a noticeable difference in response times between submitting 10 repetitions and submitting 1000 repetitions, it may indicate a problem of this type.

Testing White Box

Examine the logic in the code as it relates to the two above cases. In the first case, look for any logic loops that are using a value that originated as a name/value pair taken from the web request. In the second case, look to see if the code loops over all submitted name/value pairs with no restrictions or limits. If so, see how much work each name/value pair could create on the server if large numbers of extra name/values were also submitted.


OWASP Testing Guide v2

Here is the OWASP Testing Guide v2 Table of Contents