Skip to main content


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");
 "TRACE", "",false);
<input type=button OnClick="sendTrace();" value="Send Trace Request">


Post a Comment

Popular posts from this blog

Hacking Windows 10 UWP App: DLL Injection & common Vulnerabilities

I recently started working on  widows 10 Apps( Apps not Applications) security. Before diving deep in hacking terms lets try to understand what's new in Windows 10 UWP( Universal Platform) as compared to old Apps. Lets begin with how apps actually work on windows 10(desktop/tablet). Now windows 10 comes with a container only for running apps inside the isolated environment. By default, /APPCONTAINER(Linker Flag) is off. This option modifies an executable to indicate whether the app must be run in the appcontainer process-isolation environment. Specify /APPCONTAINER for an app that must run in the appcontainer environment—for example, a Windows Store app. (The option is set automatically in Visual Studio when you create a Windows Store app from a template.) For a desktop app, specify /APPCONTAINER:NO or just omit the option. The /APPCONTAINER option was introduced in Windows 8. Now there is no registry entry concept for these app in the System HIVE rather they install they own hiv

Animated Cursor Vulnerability

Step1: create two file on attacker side 1) default index.html and 2) cursor file to load Now save the proof of concept in a txt file(cursor.txt). use above command to cut down the hex part from proof of concept and paste it in buffer.ani Step2 :upload the above two files in your apache webserver.  Step3: Try to open index.html from window-xp and analyse the behavior of IE using ollydgb in order to find the offset address where EIP will get over written. Attach IE in ollydgb and put malicious url in it. As we can see now that EIP is overwritten with 42424242 that means this place is our offset. Now we will put the address of jump instruction in place of 42424242 which we will get from user32.dll by searching for command JUMP DWORD [EBX],now we jumped at ebx because it contain the malicious .ani file address. Just go into view=>executable=>user32.dll , press enter. Now try to find a jump [ebx] instruction in user32.dll by pressing ctrl

Assignment 01(Enroll TO Offensive-Security Course)

Steps 1:download the page. 2:open fc4.js in your favourite editor and add following lines in it or just replace it with vode given below. 3:then open the download html file in browser and fill the form with your email and a garbage value string. 4:thats it? it will show you the real security string?? yeah but  ...theirs another challenge waiting for you ... :D function fc4me(srvstr) {    if(! || !document.pleazfc4me.securitystring.value) {       alert("Please fill in all the required fields!");       return false;    }    else {       document.pleazfc4me.submit();     }    var t=hexMD5("\x74\x72\x79\x68\x61\x72\x64\x65\x72"+srvstr) alert(t) document.write(t) } Finally Got In :-)