When a client makes a request, that request may have to travel through firewalls, proxies, gateways, or other applications. Each of these has the opportunity to modify the original HTTP request. The TRACE method allows clients to see how its request looks when it finally makes it to the server. A TRACE request initiates a "loopback" diagnostic at the destination server. The server at the final leg of the trip bounces back a TRACE response, with the virgin request message it received in the body of its response. A client can then see how, or if, its original message was munged or modified along the request/response chain of any intervening HTTP applications
“Trace” is used simply as an input data echo mechanism for the http protocol. This request method is commonly used for debug and other connection analysis activities. The http trace request (containing request line, headers, post data), sent to a trace supporting web server, will respond to the client with the information contained in the request. Trace provides any easy to way to tell what an http client is sending and what the server is receiving. Apache, IIS, and iPlanet all support trace as defined by the HTTP/1.1 RFC and is currently enabled by default. Very few system administrators have disabled this request method either because the method posed no known risk, default settings were considered good enough or simply had no option to do so.
Cross Site Tracing
There are multiple ways to make a browser issue a TRACE request, such as the XMLHTTP ActiveX control in Internet Explorer and XMLDOM in Mozilla and Netscape. However, for security reasons the browser is allowed to start a connection only to the domain where the hostile script resides. This is a mitigating factor, as the attacker needs to combine the TRACE method with another vulnerability in order to mount the attack. Basically, an attacker has two ways to successfully launch a Cross Site Tracing attack:
Leveraging another server-side vulnerability: the attacker injects the hostile JavaScript snippet that contains the TRACE request in the vulnerable application, as in a normal Cross Site Scripting attack
Leveraging a client-side vulnerability: the attacker creates a malicious website that contains the hostile JavaScript snippet and exploits some cross-domain vulnerability of the browser of the victim, in order to make the JavaScript code successfully perform a connection to the site that supports the TRACE method and that originated the cookie that the attacker is trying to steal.
Code To Steal Cookies Using XST
function sendTrace() {
var xmlHttp = new ActiveXObject("Microsoft.XMLHTTP");
xmlHttp.open("TRACE", "https://www.foobar.com/extranet/",false);
xmlHttp.send();
xmlDoc=xmlHttp.responseText;
alert(xmlDoc);
}
<input type=button OnClick="sendTrace();" value="Send Trace Request">
“Trace” is used simply as an input data echo mechanism for the http protocol. This request method is commonly used for debug and other connection analysis activities. The http trace request (containing request line, headers, post data), sent to a trace supporting web server, will respond to the client with the information contained in the request. Trace provides any easy to way to tell what an http client is sending and what the server is receiving. Apache, IIS, and iPlanet all support trace as defined by the HTTP/1.1 RFC and is currently enabled by default. Very few system administrators have disabled this request method either because the method posed no known risk, default settings were considered good enough or simply had no option to do so.
Cross Site Tracing
There are multiple ways to make a browser issue a TRACE request, such as the XMLHTTP ActiveX control in Internet Explorer and XMLDOM in Mozilla and Netscape. However, for security reasons the browser is allowed to start a connection only to the domain where the hostile script resides. This is a mitigating factor, as the attacker needs to combine the TRACE method with another vulnerability in order to mount the attack. Basically, an attacker has two ways to successfully launch a Cross Site Tracing attack:
Leveraging another server-side vulnerability: the attacker injects the hostile JavaScript snippet that contains the TRACE request in the vulnerable application, as in a normal Cross Site Scripting attack
Leveraging a client-side vulnerability: the attacker creates a malicious website that contains the hostile JavaScript snippet and exploits some cross-domain vulnerability of the browser of the victim, in order to make the JavaScript code successfully perform a connection to the site that supports the TRACE method and that originated the cookie that the attacker is trying to steal.
Code To Steal Cookies Using XST
function sendTrace() {
var xmlHttp = new ActiveXObject("Microsoft.XMLHTTP");
xmlHttp.open("TRACE", "https://www.foobar.com/extranet/",false);
xmlHttp.send();
xmlDoc=xmlHttp.responseText;
alert(xmlDoc);
}
<input type=button OnClick="sendTrace();" value="Send Trace Request">
Shall I turn this setting on or off?
ReplyDelete