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 Failure to Release Resources (OWASP-DS-007)"

From OWASP
Jump to: navigation, search
(Undo revision 61590 by ElougEtvar (Talk))
 
(9 intermediate revisions by 5 users not shown)
Line 1: Line 1:
{{Template:OWASP Testing Guide}}
+
{{Template:OWASP Testing Guide v3}}
  
If an error occurs in the application that prevents the release of an in-use resource, it can become unavailable for use. The first example would be locking a file for writing, and then an exception occurring which does not explicitly close and unlock the file.
+
== Brief Summary ==
 +
With this test, we check that the application properly releases resources (files and/or memory) after they have been used.  
  
A second example occurs in languages where the developer is responsible for memory management such as C & C++, if memory is leaked because of a failure. In the case where an error causes normal logic flow to be circumvented, the allocated memory may not be removed and may be left in such a state that the garbage collector does not know it should be reclaimed.
+
== Description of the Issue ==
 
+
If an error occurs in the application that prevents the release of an in-use resource, that resource can become unavailable for further use. Possible examples include:
A third example would be the use of DB connection objects where the objects are not being freed if an exception is thrown. A number of such repeated requests can cause the application to consume all the db connections, as the code will still hold the open DB object, never releasing the resource.
+
* An application locks a file for writing, but when an exception occurs, it does not explicitly close and unlock the file
 
+
* Memory leaking in languages where the developer is responsible for memory management such as C and C++. In the case where an error causes the normal logic flow to be circumvented, the allocated memory may not be removed and may be left in such a state that the garbage collector does not know it should reclaim it
==Code Example==
+
* Use of DB connection objects where the objects are not being freed if an exception is thrown. A number of such repeated requests can cause the application to consume all the DB connections, as the code will still hold the open DB object, never releasing the resource.
  
 
The following is an example of vulnerable code in Java.  In the example, both the Connection and the CallableStatement should be closed in a finally block.
 
The following is an example of vulnerable code in Java.  In the example, both the Connection and the CallableStatement should be closed in a finally block.
Line 31: Line 32:
 
</pre>
 
</pre>
  
==Testing Black Box==
+
==Black Box Testing and Examples==
  
Generally, it will be very difficult to observe these types of resource leaks in a pure black box test.  If you can find a request you suspect is performing a database operation, which will cause the server to throw an error that looks like it might be an unhandled exception, you can automate the process of sending a few hundred of these requests very quickly.  Observe any slowdown or new error messages from the application while using it during normal, legitimate use.
+
Generally, it will be very difficult to observe these types of resource leaks in a pure black box test.  If you can find a request that you suspect is performing a database operation, and that will cause the server to throw an error which may not be properly handled, then you can automate the process of sending a few hundred of these requests very quickly.  Observe any slowdown or new error messages from the application while using it during normal, legitimate use.
  
==Testing White Box==
+
==Gray Box Testing and Examples==
  
If access to the servers is available during testing, it may be possible to observe the memory or disk usage on the server while trying to inject data into the application, with the intent of causing an exception or error that may not be handled cleanly by the application.  Attempts to cause these types of errors should include special characters that may not have been expected as valid data (e.g., !, |, and ‘).
+
It might be possible, in some cases, to monitor the disk space and/or the memory usage of the target. That can happen usually when the test is performed over a local network. Possible ways to obtain this information include the following scenarios:
 +
# The server that hosts the application allows the tester to mount its filesystem or some parts of it
 +
# The server provides disk space and/or memory usage information via SNMP
  
If reviewing the code directly, look for places within the application that relate to the three types of leaks mentioned in the summary:
+
In such cases, it may be possible to observe the memory or disk usage on the server while trying to inject data into the application, with the intent of causing an exception or error that may not be handled cleanly by the application. Attempts to cause these types of errors should include special characters that may not have been expected as valid data (e.g., !, |, and ‘).
# Are files locked for write any place within the application?  This can cause problems in a multi-user web application even without a failure condition, so should be flagged for closer observation.  If an error occurs, will the lock be removed?
 
# If dealing with C/C++ or any other language where the developer is directly responsible for memory management, is all allocated memory freed, even during an error condition?
 
# Anywhere that connection pools are being used, such as for database connectivity, will objects be returned to the pool even during a failure condition? Does the pool have a cap on how many objects it will eventually create for use if an object is not available?
 
  
[[OWASP Testing Guide Table of Contents]]
+
<br>
 
[[category:Denial of Service Attack]]
 
[[category:Denial of Service Attack]]

Latest revision as of 18:47, 24 May 2009

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

With this test, we check that the application properly releases resources (files and/or memory) after they have been used.

Description of the Issue

If an error occurs in the application that prevents the release of an in-use resource, that resource can become unavailable for further use. Possible examples include:

  • An application locks a file for writing, but when an exception occurs, it does not explicitly close and unlock the file
  • Memory leaking in languages where the developer is responsible for memory management such as C and C++. In the case where an error causes the normal logic flow to be circumvented, the allocated memory may not be removed and may be left in such a state that the garbage collector does not know it should reclaim it
  • Use of DB connection objects where the objects are not being freed if an exception is thrown. A number of such repeated requests can cause the application to consume all the DB connections, as the code will still hold the open DB object, never releasing the resource.

The following is an example of vulnerable code in Java. In the example, both the Connection and the CallableStatement should be closed in a finally block.

public class AccountDAO {
    … …
    public void createAccount(AccountInfo acct)  
                 throws AcctCreationException {
       … …
	try {
	   Connection conn = DAOFactory.getConnection();
	   CallableStatement  calStmt = conn.prepareCall(…);
          … …	
          calStmt.executeUpdate();
	   calStmt.close();
          conn.close();
       }  catch (java.sql.SQLException e) {
	   throw AcctCreationException (...);
       }
    }
}

Black Box Testing and Examples

Generally, it will be very difficult to observe these types of resource leaks in a pure black box test. If you can find a request that you suspect is performing a database operation, and that will cause the server to throw an error which may not be properly handled, then you can automate the process of sending a few hundred of these requests very quickly. Observe any slowdown or new error messages from the application while using it during normal, legitimate use.

Gray Box Testing and Examples

It might be possible, in some cases, to monitor the disk space and/or the memory usage of the target. That can happen usually when the test is performed over a local network. Possible ways to obtain this information include the following scenarios:

  1. The server that hosts the application allows the tester to mount its filesystem or some parts of it
  2. The server provides disk space and/or memory usage information via SNMP

In such cases, it may be possible to observe the memory or disk usage on the server while trying to inject data into the application, with the intent of causing an exception or error that may not be handled cleanly by the application. Attempts to cause these types of errors should include special characters that may not have been expected as valid data (e.g., !, |, and ‘).