Technofriends

My earlier posts on Learning the Basics of Hacking and Hacking Ruby on Rails Application must have given you a good start with Web Application Security Testing approach. We all have heard a lot about Zero Day IE Exploit, SQL Injection and other various types of attack tactics. However, there also exist other exploits which certainly are potentially more dangerous because once proven through a successful attack on these lesser known applications they can rapidly be adapted to exploit more common web applications, and no one is specifically concentrating on preventing them because they’re, well, not so obvious. 

Recently, SANS Internet Storm Center featured a write up on attempts to exploit Roundcube Webmail via the HTTP Accept header. Such an attack is generally focused on exploitation of operating system, language, or environmental vulnerabilities, as the data contained in HTTP headers (aside from cookies) is rarely used by the application as user-input.

An example provided by SANS of an attack targeting Roundcube via the HTTP Accept header:

POST /roundcube/bin/html2text.php HTTP/1.1 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5 
Host: xx.xx.xx.xx 
Accept: ZWNobyAoMzMzMjEyKzQzMjQ1NjY2KS4iICI7O3Bhc3N0aHJ1KCJ1bmFtZSAtYTtpZCIpOw== 
Content-Length: 54

What the attackers in this example were attempting to do is trick the application into evaluating system commands encoded in the Accept header in order to retrieve some data they should not have had access to. The purpose of the attack, however, could easily have been for some other nefarious deed such as potentially writing a file to the system that could be used as a cross-site scripting attack, or deleting files, or just generally wreaking havoc with the system.

Regardless of the technology you use, the process is the same for all: you must determine what is allowed in HTTP headers and verify them just as you would any other user-generated input or you need to invest in a solution that provides this type of security for you. A solution which can read and validate the HTTP Headers and reject all that is not valid from a RFC perspective. RFC 2616 (HTTP), specifically section 14, provide a great deal of guidance and detail on what is acceptable in an HTTP header field. 

As an important rule, Never ever blindly evaluate or execute upon data contained in an HTTP header field. Treat any input, even input that is not traditionally user-generated, as suspect. That’s a good rule of thumb for protecting against malicious payloads anyway, but especially a good rule when dealing with what is likely considered a non-traditional attack vector (until it is used, and overused to the point it’s considered typical, of course).

What are the various ways to protect yourself from such HTTP Header Exploits

1.) Read and validate all the HTTP Headers to ensure that the fields and values contained in them are valid from RFC perspective. 

2.) Stripping out metacharacters like <>”:;’}{][|\)(*&^%$#!` from HTTP Headers. This can help prevent html, JavaScript, php, sql injection,and SSI insertion.

3.) Replacing < and > with &gt; &lt;this helps prevent tag execution.One obvious problem would be scripts with potential backtick “`” problems.

4.) Invest in a security solution capable of sanitizing transport (TCP) and application layer (HTTP) protocols and use it to do so.

5.) Investigate whether an existing solution - either security or application delivery focused - is capable of providing the means through which you can enforce protocol compliance.

 

You can follow me on Twitter at http://twitter.com/vaibhav1981

Do stay tuned to Technofriends for more, one of the best ways of doing so is by subscribing to our feeds. You can subscribe to Technofriends feed by clicking here.

Related posts:

1. View HTTP Request and Response Header Online Using Web-Sniffer
2. [Security] How a Distributed Denial of Service Attack on your DNS Server can bring down your Website
3. Bug Lets Hackers Take Over iPhone
4. [Security] Writing Hacker Safe PHP Code
5. [Notes]: Web Application Security Testing