How to prevent a cross-site tracing vulnerability exploit

Michael Cobb provides quick tips on how to protect your websites from cross-site tracing attacks.

My constant concern about rushed and unrealistic development timetables for websites was borne out the other day when I was called in to investigate what turned out to be a case of cross-site tracing (XST). This tip explains what cross-site tracing is and how to prevent it during the web developement process.

A cross-site tracing attack exploits ActiveX, Flash, Java and other controls that allow the execution of an HTTP TRACE request. The attack is not a new one; it was discovered by Web security researcher Jeremiah Grossman in 2003, and enables an attacker to gain access to an individual's cookies and authentication credential information.

A cross-site tracing attack combines a cross-site scripting (XSS) vulnerability – where an attacker injects malicious code into a link -- and the HTTP TRACE method -- hence the XST name. Most Web developers are familiar with the HTTP methods GET and POST, which send requests to and access information from a Web server, but there are several other less well-known methods, including TRACE.

HTTP TRACE asks a Web server to echo the contents of the request back to the client. The complete request, including HTTP headers, which can include sensitive information such as cookies or authentication data, is returned in the entity-body of a TRACE response. The request is primarily used by developers for testing and debugging HTTP applications and is available by default in most Web server software.

One way to carry out an XST attack is to create a webpage which includes some JavaScript that contains the TRACE request. The JavaScript can then exploit any cross-domain vulnerability in a visitor's browser to collect the cached credentials of any website, including those utilizing SSL.

Another more common method takes the JavaScript snippet containing the TRACE request and injects it into the vulnerable Web application. The JavaScript will be able to send the victim's request headers, including cookie data tagged as "httpOnly" to the attacker. "httpOnly" is an extra parameter added to cookies, which hides cookies from scripts and is supported in most browsers; the TRACE method, however, can be used to bypass this protection.

It is easy for an attacker, or system administrator, to test if a Web server supports the TRACE method. Using a utility such as the open source Netcat -- a networking service that can read network connections with TCP or UDP -- attackers can use the HTTP method OPTIONS to obtain a list of the methods supported by the Web server.

Quick tips: How to stop a cross-site tracing vulnerability exploit
To prevent this type of attack, it's essential that the PUT, DELETE, CONNECT and TRACE methods are disabled on your Web server as they all pose a potential security risk.

If an application needs one or more of these methods, such as REST Web Services (which may require PUT or DELETE), it is important to check that their usage is properly limited to trusted users and safe conditions. To disable HTTP TRACE support on an Apache Server, set TraceEnable Off. If you are running IIS and a Windows Server, use the URLScan tool to deny HTTP TRACE requests or to permit only the methods needed to meet your site's requirements and security policy.

About the author:
Michael Cobb, CISSP-ISSAP is the founder and managing director of Cobweb Applications Ltd., a consultancy that offers IT training and support in data security and analysis. He co-authored the book IIS Security and has written numerous technical articles for leading IT publications.

Read more on Web application security