Testing for DoS User Specified Object Allocation (OWASP-DS-004)
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.
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.
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.