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.

Canonicalization

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.

These articles are influenced by the book ( “How to Break Web Software” from Mike Andrews and James A. Whittaker ) I have recently read and should be a good read for you if you need information on web application security testing.