Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

I saw many posts here on this site dishing out advice on disabling HTTP TRACE method to prevent cross site tracing. I sought to do the same thing. But when I read the Apache documentation, it gives the opposite advice:

Note

Despite claims to the contrary, TRACE is not a security vulnerability and there is no viable reason for it to be disabled. Doing so necessarily makes your server non-compliant.

Which should I follow?

share|improve this question

3 Answers 3

up vote 10 down vote accepted

One of the wisest security principles says that what is unused should be disabled.

So the first questions is: Are you really going to use it? Do you need it to be enabled?

If you are not going to use TRACE method then in my opinion it should be switched off. It will prevent your app not only against XST, but also against undiscovered vulnerabilities related to this channel, which can be found in the future.

share|improve this answer

In order to send a TRACE command to a given server, you must have the right to do so, which is normally prevented by the Same-Origin Policy (the famous "SOP"). If a piece of malicious JavaScript, intent on stealing your cookie on site example.com, is able to send a TRACE request to example.com, then that evil JavaScript has already won and you are in deeper trouble. Disabling TRACE does not solve the real problem (and that problem is client-side).

To make an outrageous analogy: there are people who murder others by stabbing them with knives. Would banning knives really solve the issue? (I'm using knives and not guns here, because it is pretty obvious that knives are very useful tools for tasks other than murdering people, e.g. I use knives daily for cooking; the same cannot be said about guns. Similarly, the HTTP TRACE method is a useful debugging tool.)

share|improve this answer
    
Most (all?) browsers prevent TRACE from working in javascript, so there's that. Doesn't prevent a java/flash app from doing it though. –  Nathan C Apr 30 at 14:59

Which should I follow?

You're going to be scanning your website, what... Annually? Quarterly? Monthly, weekly? And that'll show up on all those scans. Until you tell your scanner to skip that check, or to make an exception... at which point it'll sit there until you have a third party run a scan for you, or one of your partners scans your site and puts it under your nose as "How can you leave such a basic checklist item unaddressed?

Conversely, you're going to be scanned for compliance to the HTTP spec... never. You'll need to actually use TRACE... pretty much never. The practical effect on interoperability with your clients will be... nada.

I understand and agree with @Tom-Leek's point that it's not much of a security issue. However, I disagree in that the downside of disabling is miniscule, and the upside of disabling it is to avoid a lot of annoyance that would otherwise end up in your lap.

I'm not the only one to think that way - which is why Apache added a directive in 1.3.34 and 2.0.55 to simply shut TRACE off:

TraceEnable Off

Here's a good page discussing it, including manual test steps.

share|improve this answer
    
Wow, according to Apachehaus (not sure if it's trustworthy), those 2 versions of Apache were released in 2005! –  trysis Apr 30 at 15:26
2  
+1 for pointing out that we are often defending against auditors, CISSPs, and other earnest security folks questioning our decisions later. This is why I often use the phrase "still vulnerable to CISSP attacks" in my security reports. –  mcgyver5 Apr 30 at 16:00

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.