40

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?

Question Overflow
  • 5,250
  • 6
  • 27
  • 48
  • 2
    Interestingly Apache's comment here is incorrect: the lack of TRACE does not make the server non-compliant. TRACE is marked a "SHOULD" in RFC-2616 and can therefore be ignored *if there is good reason* and *low practical impact*. – Philip Couling Jun 14 '16 at 15:12

3 Answers3

29

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.

boleslaw.smialy
  • 1,627
  • 2
  • 15
  • 25
22

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.)

Thomas Pornin
  • 322,884
  • 58
  • 787
  • 955
Tom Leek
  • 170,038
  • 29
  • 342
  • 480
  • 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 '14 at 14:59
  • @NathanC But if someone's running a Java / Flash app in their browser, they have bigger problems. – Parthian Shot Jul 25 '15 at 20:16
  • 1
    @TomLeek, Your answer asserts that `TRACE` is safe because attacks are already prevented by SOP and SOP alone. This is a halfhearted and **narrow-minded** way of analyzing security. Fact is, regardless of SOP status, malicious `TRACE` can still be sent to servers by using SSL renegotiation attacks. And what about in the future? The secure viewpoint should be that there is Every Reason to disable `TRACE` **because its such a tasty vector** of abuse. It's like playing russian roulette with blank cartridges. Just don't. – Pacerier Nov 10 '16 at 18:58
  • *[cont]* Re "*Similarly, the HTTP TRACE method is a useful debugging tool*", what would be the other use cases of playing russian roulette with an actual server and are there **no safer alternative** methods? `TRACE` is actually closer in analogy to a Katana than a typical small kitchen knife. – Pacerier Nov 10 '16 at 19:02
16

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.

gowenfawr
  • 72,355
  • 17
  • 162
  • 199
  • Wow, according to Apachehaus (not sure if it's trustworthy), those 2 versions of Apache were released in 2005! – trysis Apr 30 '14 at 15:26
  • 7
    +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 '14 at 16:00
  • 1
    I'd like to add a very gentle word of warning about second guessing security recommendations. Hacks can be *painfully obscure*. Just because you can't exploit a vulnerability doesn't mean a hacker can't. To that end, keeping the auditors happy *can* be a useful security exercise even when it looks meaningless. – Philip Couling Jun 14 '16 at 15:11