Difference between revisions of "Testing for Storing too Much Data in Session (OWASP-DS-008)"

From OWASP
Jump to: navigation, search
 
(8 intermediate revisions by 3 users not shown)
Line 1: Line 1:
[[http://www.owasp.org/index.php/Web_Application_Penetration_Testing_AoC Up]]<br>
+
{{Template:OWASP Testing Guide v3}}
{{Template:OWASP Testing Guide v2}}
+
  
Care must be taken not to store too much data in a user session object. Storing too much information, such as large quantities of data retrieved from the database, in the session can also cause denial of service issues. This problem is exacerbated if session data is also tracked prior to a login.
+
== Brief Summary ==
 +
In this test, we check whether it is possible to allocate big amounts of data into a user session object in order to make the server exhaust its memory resources.
  
==Testing Black Box==
+
== Description of the Issue ==  
 +
Care must be taken not to store too much data in a user session object. Storing too much information in the session, such as large quantities of data retrieved from the database, can cause denial of service issues. This problem is exacerbated if the session is populated when serving unauthenticated users, because, in this case, an attacker can launch the attack without having to obtain an account.
  
This is again a difficult case to test in a pure black box setting.  Likely places will be where a large number of records are retrieved from a database based on data provided by the user during their normal application use.  Good candidates may also include functionality related to viewing pages of a larger record set a portion at a time.  The developer may have chosen to cache the records in the session instead of returning to the database for the next block of data.  If this is suspected, create a script to automate the creation of many new sessions with the server and run the request that is suspected of caching the data within the session for each one.  Let the script run for a while, and then observe the responsiveness of the application for new sessions.  It may be possible that a Virtual Machine (VM) or even the server itself will begin to run out of memory because of this attack.
+
==Black Box Testing and Examples==
  
==Testing White Box==
+
This is again a difficult case to test in a pure black box setting.  Likely places to look for this vulnerability are those where a large number of records are retrieved from a database, based on data provided by the user during their normal application use.  Good candidates may also include paging code, i.e., the functionality of viewing a large record set a portion at a time.  The developer may have chosen to cache the records in the session instead of returning to the database for the next block of data.  If this is suspected, create a script to automate the creation of many new sessions with the server and run the request that is suspected of caching the data within the session for each one.  Let the script run for a while, and then observe the responsiveness of the application for new sessions.  It may be possible that a Virtual Machine (VM) or even the server itself will begin to run out of memory because of this attack.
  
Look within the code to observe what data is being stored within a user session object. Any locations where large amounts of data either submitted directly by the user or returned from the database are placed into the session should be marked as a potential problem.
+
==Gray Box Testing and Examples==
 +
If available, SNMP can provide information about the memory usage of a machine. Being able to monitor the target memory usage can greatly help when performing this test, as the tester would be able to see what happens when the script described in the previous section is launched.
  
==Other References==
 
  
De Vries, S. (2004, April 1). Application denial of service (DoS) attacks. Retrieved August 11, 2005, from http://www.corsaire.com/white-papers/040405-application-level-dos-attacks.pdf
 
 
* Looking for fields that take a number as input that may control a number of objects or rows to create on the server, so that sending one large number may DoS app.
 
* Misuse of CPU-intensive operations? (Imagine a SQL query that draws from million of records and any user can execute it as whim, it might be legitimate, there's no flooding, but the web server cannot cope with say, 5 parallel requests)
 
 
==Access Control==
 
* Authorization process [ ]
 
* Parameter analysis [ ]
 
* Bypassing logon process [ ]
 
* Control of access to seasonal facilities: Impossibility of invoke and access application facilities outside the established periods. For example with a Human Resource application, the evaluation process facility only works from January to May and the rest of the year it must be not active. [ ]
 
 
{{Category:OWASP Testing Project AoC}}
 
 
[[category:Denial of Service Attack]]
 
[[category:Denial of Service Attack]]

Latest revision as of 18:34, 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

Contents


Brief Summary

In this test, we check whether it is possible to allocate big amounts of data into a user session object in order to make the server exhaust its memory resources.

Description of the Issue

Care must be taken not to store too much data in a user session object. Storing too much information in the session, such as large quantities of data retrieved from the database, can cause denial of service issues. This problem is exacerbated if the session is populated when serving unauthenticated users, because, in this case, an attacker can launch the attack without having to obtain an account.

Black Box Testing and Examples

This is again a difficult case to test in a pure black box setting. Likely places to look for this vulnerability are those where a large number of records are retrieved from a database, based on data provided by the user during their normal application use. Good candidates may also include paging code, i.e., the functionality of viewing a large record set a portion at a time. The developer may have chosen to cache the records in the session instead of returning to the database for the next block of data. If this is suspected, create a script to automate the creation of many new sessions with the server and run the request that is suspected of caching the data within the session for each one. Let the script run for a while, and then observe the responsiveness of the application for new sessions. It may be possible that a Virtual Machine (VM) or even the server itself will begin to run out of memory because of this attack.

Gray Box Testing and Examples

If available, SNMP can provide information about the memory usage of a machine. Being able to monitor the target memory usage can greatly help when performing this test, as the tester would be able to see what happens when the script described in the previous section is launched.