Testing for Writing User Provided Data to Disk (OWASP-DS-006)

From OWASP
Revision as of 16:35, 12 November 2006 by Mmeucci (Talk | contribs)

Jump to: navigation, search

[Up]
OWASP Testing Guide v2 Table of Contents

It may be difficult to detect the success of this type of attack unless the tester has access to the logs (white box) being created by the application. The nature of this DoS attack is to cause the application logs to record enormous volumes of data, possibly filling the local disks.

This attack could happen in two common ways:

  1. The tester submits an extremely long value to the server in the request, and the application logs the value directly without having validated that it conforms to what was expected.
  2. The application may have data validation to verify the submitted value being well formed and of proper length, but then still log the failed value (for auditing or error tracking purposes) into an application log.

Testing Black Box

This test is extremely difficult to detect through a black box test without some luck and a large degree of patience. Determine a value that is being submitted from the client that does not look to have a length check (or has one that is extremely long), that would have a high probability for being logged by the application. Textarea fields in the client are likely to have very long acceptable lengths; however, they may not be logged beyond a remote database. Use a script to automate the process of sending the same request with a large value for the field as fast as possible, and give it some time. Does the server eventually begin reporting errors when it tries to write to the file system?

Testing White Box

If the tester has access to the server while doing the penetration testing, they should send an overly large request to the server, and if possible, observe if the data is being written to an application log file without any limitation of the length. If there is no restriction, it should be possible to automate a short script to send these long requests and observe at what speeds the log file grows on the server. This can allow the tester to determine just how much time & effort would be required to fill the disk, without needing to run the DoS through to completion.

If examining the code directly, look at any logging methods used by the application to observe what data that originated in the request is logged. Be especially vigilant of log messages written in the case of a data validation failure, if the message was to be rejected for being too long. Many developers will still make the mistake of logging the overly long values to the logs anyway.


OWASP Testing Guide v2

Here is the OWASP Testing Guide v2 Table of Contents