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)"
m (→Black Box Testing and Examples) |
m (Testing for DoS User Specified Object Allocation moved to Testing for DoS User Specified Object Allocation (OWASP-DS-004)) |
||
(One intermediate revision by one other user not shown) | |||
Line 1: | Line 1: | ||
− | + | {{Template:OWASP Testing Guide v3}} | |
− | {{Template:OWASP Testing Guide | ||
== Brief Summary == | == Brief Summary == | ||
Line 28: | Line 27: | ||
Knowing some details about the internals of the application might help the tester in locating objects that can be allocated by the user in large quantities. The testing techniques, however, follow the same pattern of the black box testing. | Knowing some details about the internals of the application might help the tester in locating objects that can be allocated by the user in large quantities. The testing techniques, however, follow the same pattern of the black box testing. | ||
− | |||
[[category:Denial of Service Attack]] | [[category:Denial of Service Attack]] |
Latest revision as of 23:08, 15 December 2008
OWASP Testing Guide v3 Table of Contents
This article is part of the OWASP Testing Guide v3. The entire OWASP Testing Guide v3 can be downloaded here.
OWASP at the moment is working at the OWASP Testing Guide v4: you can browse the Guide here
Brief Summary
In this test, we check whether it is possible to exhaust server resources by making it allocate a very large number of objects.
Description of the Issue
If users can supply, directly or indirectly, a value that will specify how many copies of an object to create on the application server, and if the server does not enforce a hard upper limit on that value, it is possible to cause the environment to run out of available memory. The server may begin to allocate the number of objects specified, but if this is an extremely large number, it can cause serious issues on the server, possibly filling its whole available memory and corrupting its performance.
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!
Black Box Testing and Examples
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, an attacker 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.
If the application does not provide any numeric field that can be used as a vector for this kind of attack, the same result might be achieved by allocating objects in a sequential fashion. A notable example is provided by e-commerce sites: if the application does not pose an upper limit to the number of items that can be in any given moment inside the user electronic cart, you can write an automated script that keeps adding items to the user cart until the cart object fills the server memory.
Gray Box Testing and Examples
Knowing some details about the internals of the application might help the tester in locating objects that can be allocated by the user in large quantities. The testing techniques, however, follow the same pattern of the black box testing.