Difference between revisions of "Testing for DoS Buffer Overflows (OWASP-DS-003)"

From OWASP
Jump to: navigation, search
 
Line 1: Line 1:
{{Template:OWASP Testing Guide}}
+
[[http://www.owasp.org/index.php/Web_Application_Penetration_Testing_AoC Up]]<br>
 +
{{Template:OWASP Testing Guide v2}}
  
 
Any language where the developer has direct responsibility for managing memory allocation, most notably C & C++, has the potential for a buffer overflow. While the most serious risk related to a buffer overflow is the ability to execute arbitrary code on the server, the first risk comes from the denial of service that can happen if the application crashes. Buffer overflows will be discussed in more detail elsewhere in this testing document, but we will briefly give an example as it relates to an application denial of service.   
 
Any language where the developer has direct responsibility for managing memory allocation, most notably C & C++, has the potential for a buffer overflow. While the most serious risk related to a buffer overflow is the ability to execute arbitrary code on the server, the first risk comes from the denial of service that can happen if the application crashes. Buffer overflows will be discussed in more detail elsewhere in this testing document, but we will briefly give an example as it relates to an application denial of service.   
Line 28: Line 29:
 
Please refer to the Buffer Overflow section of this document for detailed information on this testing.
 
Please refer to the Buffer Overflow section of this document for detailed information on this testing.
  
[[OWASP Testing Guide Table of Contents]]
+
{{Category:OWASP Testing Project AoC}}
 
[[category:Denial of Service Attack]]
 
[[category:Denial of Service Attack]]
 
[[category:Buffer Overflow Attack]]
 
[[category:Buffer Overflow Attack]]

Revision as of 16:32, 12 November 2006

[Up]
OWASP Testing Guide v2 Table of Contents

Contents


Any language where the developer has direct responsibility for managing memory allocation, most notably C & C++, has the potential for a buffer overflow. While the most serious risk related to a buffer overflow is the ability to execute arbitrary code on the server, the first risk comes from the denial of service that can happen if the application crashes. Buffer overflows will be discussed in more detail elsewhere in this testing document, but we will briefly give an example as it relates to an application denial of service.

Code Example

The following is a simplified example of vulnerable code in C:

void overflow (char *str) {
   char buffer[10];
   strcpy(buffer, str); // Dangerous!
}

int main () {
  char *str = "This is a string that is larger than the buffer of 10";
  overflow(str);
}

If this code example were executed, it would cause a segmentation fault and dump core. While this above example is an extremely simple case, the reality is that in a web based application there may be places where the str value was not static, but rather taken from a value provided within a name/value pair.

Testing Black Box

Refer to the Buffer Overflow section for how to submit a range of lengths to the application looking for possible locations that may be vulnerable. As it relates to a DoS, if you have received a message that makes you believe that the overflow has occurred, attempt to make another legitimate request from the server and see if it still responsds.

Testing White Box

Please refer to the Buffer Overflow section of this document for detailed information on this testing.


OWASP Testing Guide v2

Here is the OWASP Testing Guide v2 Table of Contents