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 Storing too Much Data in Session (OWASP-DS-008)"
| Line 2: | Line 2: | ||
{{Template:OWASP Testing Guide v2}} | {{Template:OWASP Testing Guide v2}} | ||
| − | + | == 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 to 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, such as large quantities of data retrieved from the database, in the session can cause denial of service issues. This problem is exacerbated if session data is also tracked prior to a login, as a user can launch the attack without the need of an account. | ||
| + | |||
| + | ==Black Box Testing and Examples== | ||
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. | 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. | ||
| − | ==Testing | + | ==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. | |
| − | |||
| − | |||
| − | |||
| − | + | ==References== | |
| − | + | Stephen de Vries, Application denial of service (DoS) attacks: http://www.corsaire.com/white-papers/040405-application-level-dos-attacks.pdf | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
{{Category:OWASP Testing Project AoC}} | {{Category:OWASP Testing Project AoC}} | ||
[[category:Denial of Service Attack]] | [[category:Denial of Service Attack]] | ||
Revision as of 18:34, 14 November 2006
[Up]
OWASP Testing Guide v2 Table of 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 to 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, such as large quantities of data retrieved from the database, in the session can cause denial of service issues. This problem is exacerbated if session data is also tracked prior to a login, as a user can launch the attack without the need of an account.
Black Box Testing and Examples
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.
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.
References
Stephen de Vries, Application denial of service (DoS) attacks: http://www.corsaire.com/white-papers/040405-application-level-dos-attacks.pdf
OWASP Testing Guide v2
Here is the OWASP Testing Guide v2 Table of Contents
