This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org
Difference between revisions of "Testing for DoS User Specified Object Allocation (OWASP-DS-004)"
Weilin Zhong (talk | contribs) |
Weilin Zhong (talk | contribs) |
||
Line 1: | Line 1: | ||
− | + | {{Template:OWASP Testing Guide}} | |
If users can supply, directly or indirectly, a value that will specify how many of an object to create on the application server, it is possible to cause the environment to run out of available memory. The server may begin to allocate the required number of objects specified, but if this is an extremely large number, it can cause serious issues on the server. | If users can supply, directly or indirectly, a value that will specify how many of an object to create on the application server, it is possible to cause the environment to run out of available memory. The server may begin to allocate the required number of objects specified, but if this is an extremely large number, it can cause serious issues on the server. |
Revision as of 19:25, 28 July 2006
If users can supply, directly or indirectly, a value that will specify how many of an object to create on the application server, it is possible to cause the environment to run out of available memory. The server may begin to allocate the required number of objects specified, but if this is an extremely large number, it can cause serious issues on the server.
Code Example
The following is a simple example of vulnerable code in Java:
String TotalObjects = request.getParameter(“numberofobjects”); int NumOfObjects = Integer.parseInt(TotalObjects); ComplexObject[] anArray = new ComplexObject[NumOfObjects]; // wrong!
Testing Black Box
As a tester, look for places where numbers submitted as a name/value pair might be used by the application code in the manner shown above. Attempt to set the value to an extremely large numeric value, and see if the server continues to respond. You may need to wait for some small amount of time to pass as performance begins to degrade on the server as it continues allocation.
In the above example, by sending a large number to the server in the “numberofobjects” name/value pair, this would cause the servlet to attempt to create that many complex objects. While most applications do not have a user directly entering a value that would be used for such purposes, instances of this vulnerability may be observed using a hidden field, or a value computed within JavaScript on the client when a form is submitted.
Testing White Box
If source code is available, observe how each function within the application uses values passed in from the client. Frequently variable names used to store the passed values will be a good indication of their intended use within the application, and may indicate if a problem such as the one in the above code example exists. Track the variables, especially numbers, as they are used through the logic-flow of the application.
Developers validating a number will frequently use data typing (e.g. the number is an int, it must be okay!) or an equivalent regular expression to determine if the value is acceptable or not. However, usually there is an expected range of valid values that should be enforced beyond this basic check. This valid range logic should be looked for in the application to prevent these (and other common) types of errors.