Cross-site tracing explained

Cross-site tracing explained

I have some understanding of cross-site scripting, but what about cross-site tracing? How do I protect against this attack?

    Requires Free Membership to View

    Login

    When you register, you'll receive targeted emails designed to keep you informed of the most relevant information on Agile development, application security, testing & QA, software requirements, and more.

    Hannah Smalltree, Editorial Director

    By submitting your registration information to SearchSoftwareQuality.com you agree to receive email communications from TechTarget and TechTarget partners. We encourage you to read our Privacy Policy which contains important disclosures about how we collect and use your registration and other information. If you reside outside of the United States, by submitting this registration information you consent to having your personal data transferred to and processed in the United States. Your use of SearchSoftwareQuality.com is governed by our Terms of Use. You may contact us at webmaster@TechTarget.com.

Cross-site tracing (XST) is a type of reflected cross-site scripting (XSS) that exploits the TRACE request defined in the HTTP specification. TRACE was designed as a simple test method for HTTP servers. When the server receives a TRACE request, it is supposed to respond by echoing back all the content of the request (including the cookie header). An attacker tricks a victim's browser into running a script that generates a TRACE request and sends it to the target server. When the request is reflected back to the browser, the script can pull out any cookies and sent them to the attacker. This type of attack is generally used when ordinary cross-site scripting won't work because the site uses the "HTTP Only" flag on its cookies.

To protect against this attack is, fortunately, simple. All you have to do is disable the TRACE method in your Web server or application server. This white paper discusses XST in greater detail The bigger point is that you should use a positive security model when allowing access to your application. The default rule should be to deny all HTTP methods, and only allow those you absolutely need, generally GET and POST. Continue with this model to only allow access to extensions, URLs, business functions, actions, and data that are specifically allowed.

More information:

This was first published in September 2006