Print Page | Close Window

Web Application Security Testing - Part 4

Printed From: One Stop Testing
Category: Types Of Software Testing @ OneStopTesting
Forum Name: Security Testing @ OneStopTesting
Forum Discription: Discuss All that is need to be known about Security Testing, All Security Issues and its Tools.
Printed Date: 27May2024 at 4:59pm

Topic: Web Application Security Testing - Part 4
Posted By: Mithi25
Subject: Web Application Security Testing - Part 4
Date Posted: 28Nov2009 at 3:24am
Web Application Security Testing - Part 4
This article is fourth article in the series of web application security testing. In the first three articles, we have built the base by making you familiar with the difference in web application and client server application, how gathering data about the application is important and popular attacks like SQL injection, Cross site scripting and directory traversing.

In this part we will explore how to attack server by exploiting the known limitations of language in which they are implemented. Broadly, we will cover buffer overflow, Canonicalization and Null strings related attacks.

 Buffer Overflow

Buffer overflow is probably one of the most notorious and oldest attack. This vulnerability has been around for more than three decades. In the very simplistic term, A buffer overflow is the result of stuffing more data into a buffer than it can handle. This vulnerability is mostly exposed in situations where programs processing the input data is failed to check the size of input data it is processing.

You might think how it can affect security of the system ? When input data is larger than the space allocated for it, it overflows into other memory location on the execution stack. This overflow results into the corrupted memory locations in the execution stack because it overwrites the data present in the execution stack. In most cases, application will crash because of this, because it can not handle the corrupted execution stack.

This vulnerability becomes very dangerous when input data overflow into memory that will be used in choosing which instruction to execute next. In carefully crafted data, input data can become the instruction to the computer. This causes input data to change the execution sequence of the machine and allow attacker to run arbitrary code on the web server, This vulnerability is exposed most notoriously by the worms such as CodeRed, Nimda, Slammer etc. If you are interested more in the topic, you might find reading Smashing the Stack for Fun and Profit very interesting.

It is very easy to conduct this attack, you need to give input much larger than your program is designed to handle. You also need to make sure that you do not rely completely on the client side validation. You need to supply large input data by bypassing the client side validation and ensure that server side code handles this as well. If your web application or environment is not secured against this attack, it can crash your web server or operating system as well. You can also use tool such as SPIKE Proxy  for automated buffer overflow testing of Web Application. When using any tool for this testing, be aware of the false positives. This vulnerability, if present in your web application can have very dire consequences and hence it is very important to make sure that you filter out all the false positives generated from any tool.

It is very easy to protect your application against this attack. You can either find out the size of data and allocate memory accordingly. Alternatively, you can also terminate input data at a sensible size and ignore everything else.


Before finding out how security of your web application can be compromised by canonicalization (A lso known as C14N ), it is important to understand the meaning of canonicalization. Canonicalization means ensuring that all data is represented in a standard, common form. In the absence of canonicalization, validation might miss some important attack. C14N is needed, because we need to encode certain characters because they have extended meaning in some context. For example, a simple white space character sent by browser is converted in '+' because white space can cause break in CGI parameter sequence.

There are many character sets like ASCII, UNICODE or UTF-8 in use. There could be chances of security risk when browser is working on one set of character representation and server is working on another.  For example, standard characters / is represented as / in HTTP but it can also be represented as %5c and %c0%af . This vulnerability was exposed in IIS 4 or 5 Web server with commands which will potentially allow you access command prompt and execute any commands on that. Another level of complexity can be introduced by double encoding where characters used in encoding are encoded again.

Along with canonicalization, vulnerabilities related to NULL strings can also have major security loop holes in your web application if left undetected. NULL string can also be represented by \0 or %00 . NULL strings related vulnerabilities can become security loop holes because different languages treat NULL characters differently. In some languages or libraries, NULL character added in the end can or can not have any effect. Best way to deal with this type of attack is to make sure that NULL characters are stripped from from the original data at the first opportunity. Normally, they do not serve any purpose.

Though attacks described in this articles are well known and most of the application and languages can already have protection for these attacks, still it is our responsibility to make sure that there is no security loophole in the web application. In the next article we will discuss how servers can be attacked and issues related to authentication and privacy.

------------- - Send Unlimited FREE SMS to Any Mobile Anywhere in INDIA,
Click Here

Print Page | Close Window