Published on: 06/8/14 11:34 AM

Cross Site Tracing

Summery

Cross Site Tracing (XST) enables an attacker to steal the victim’s session cookie and possibly other authentication credentials transmitted in the header of the HTTP request when the victim’s browser communicates to destination system’s web server. The attacker first gets a malicious script to run in the victim’s browser that induces the browser to initiate an HTTP TRACE request to the web server. If the destination web server allows HTTP TRACE requests, it will proceed to return a response to the victim’s web browser that contains the original HTTP request in its body. The function of HTTP TRACE, as defined by the HTTP specification, is to echo the request that the web server receives from the client back to the client. Since the HTTP header of the original request had the victim’s session cookie in it, that session cookie can now be picked off the HTTP TRACE response and sent to the attackers’ malicious site. XST becomes relevant when direct access to the session cookie via the “document.cookie” object is disabled with the use of httpOnly attribute which ensures that the cookie can be transmitted in HTTP requests but cannot be accessed in other ways. Using SSL does not protect against XST.

If the system with which the victim is interacting is susceptible to XSS, an attacker can exploit that weakness directly to get his or her malicious script to issue an HTTP TRACE request to the destination system’s web server. In the absence of an XSS weakness on the site with which the victim is interacting, an attacker can get the script to come from the site that he controls and get it to execute in the victim’s browser (if he can trick the victim’s into visiting his malicious website or clicking on the link that he supplies). However, in that case, due to the same origin policy protection mechanism in the browser, the attackers’ malicious script cannot directly issue an HTTP TRACE request to the destination system’s web server because the malicious script did not originate at that domain. An attacker will then need to find a way to exploit another weakness that would enable him or her to get around the same origin policy protection.

A Cross-Site Tracing (XST) attack involves the use of Cross-site Scripting (XSS) and the TRACE or TRACK HTTP methods. According to RFC 2616, “TRACE allows the client to see what is being received at the other end of the request chain and use that data for testing or diagnostic information.”, the TRACK method works in the same way but is specific to Microsoft’s IIS web server. XST could be used as a method to steal user’s cookies via Cross-site Scripting (XSS) even if the cookie has the “HttpOnly” flag set and/or expose the user’s Authorization header. The TRACE method, while apparently harmless, can be successfully leveraged in some scenarios to steal legitimate users’ credentials.

How attacker can attack ?

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

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.

Referances

https://www.owasp.org/index.php/Cross_Site_Tracing
http://capec.mitre.org/data/definitions/107.html
http://www.computerweekly.com/tip/How-to-prevent-a-cross-site-tracing-vulnerability-exploit