October: Disable TRACE / TRACK HTTP requests in .htaccess

[ghost]

Was thining it would be a good idea to add Cross-Site Tracing (XST) protection as default in October.

Basically, we should turn off the track and trace methods in the .HTaccess file.

This can be done by adding the following code:

RewriteEngine on
RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK)
RewriteRule .* - [F]

Most modern browsers turn this off, but October CMS still supports many old browsers and so this would add a positive security layer to October CMS, for users using old browsers. Likewise with Bots and Crawlers using old browsers in their User-Agents.

Background info

A Cross-Site Tracing (XST) attack involves the use of Cross-site Scripting (XSS) and the TRACE or TRACK HTTP methods. According to RFC 2616, "TRACE allows the client to see what is being received at the other end of the request chain and use that data for testing or diagnostic information.", the TRACK method works in the same way but is specific to Microsoft's IIS web server. XST could be used as a method to steal user's cookies via Cross-site Scripting (XSS) even if the cookie has the "HttpOnly" flag set and/or exposes the user's Authorization header.

The TRACE method, while apparently harmless, can be successfully leveraged in some scenarios to steal legitimate users' credentials. This attack technique was discovered by Jeremiah Grossman in 2003, in an attempt to bypass the HttpOnly tag that Microsoft introduced in Internet Explorer 6 sp1 to protect cookies from being accessed by JavaScript. As a matter of fact, one of the most recurring attack patterns in Cross Site Scripting is to access the document.cookie object and send it to a web server controlled by the attacker so that he/she can hijack the victim's session. Tagging a cookie as HttpOnly forbids JavaScript to access it, protecting it from being sent to a third party. However, the TRACE method can be used to bypass this protection and access the cookie even in this scenario.

Modern browsers now prevent TRACE requests being made via JavaScript, however, other ways of sending TRACE requests with browsers have been discovered, such as using Java.

[bennothommo]

@ayumihamasaki2019 Two comments:

• Are there any legitimate uses of the TRACE request method (not worried about TRACK, as that seems to be Microsoft only)?
• Would this not be better applied at the server level - especially as this particular change won't cover Nginx or another type of web server?

[ghost]

@bennothommo

1. Are there any legitimate uses of the TRACE request method?

Modern browsers now prevent TRACE requests being made via JavaScript.

1. Would this not be better applied at the server level - especially as this particular change won't cover Nginx or another type of web server?

It's recommended for Apache users to add this code.

On IIS, the same can be done with UrlScan.

Other types of Web server have specific configuration options to block TRACE.

The standard method, in Apache versions 1.3.34, 2.0.55 and later, set the TraceEnable directive to "off" in the main configuration file and then restart Apache.

When testing: TraceEnable off in October CMS you will get a Server error 500.

This method:

RewriteEngine on
RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK)
RewriteRule .* - [F]

I have been using with October since 2014 and have had no problem at all.

[bennothommo]

@ayumihamasaki2019 Thanks for the info. I'm curious as to why this is the case:

When testing: TraceEnable off in October CMS you will get a Server error 500.

Should this not have any effect unless the TRACE method is used in some capacity?

[ghost]

@bennothommo it's a bug with Apache's code, even though the trace method is not being used it says that the .HTaccess file has file permission 755, even when it's saying it has 644. The bug hits 50% of Apache users, but they are aware of it and do have an open issue on that method.

The method I suggested here is completely safe and been used for many years.

[bennothommo]

@ayumihamasaki2019 Alright, no problem. I'll leave this to @LukeTowers to make a decision on whether to include it or not. I see no harm in it myself, but there might be some edge case I'm not aware of.

[ghost]

@bennothommo sure, thanks for your feedback.

[LukeTowers]

@ayumihamasaki2019 I have literally never heard of TRACE / TRACK methods before this issue.

Most modern browsers turn this off, but October CMS still supports many old browsers and so this would add a positive security layer to October CMS, for users using old browsers. Likewise with Bots and Crawlers using old browsers in their User-Agents.

The oldest browser that OctoberCMS supports is IE11.

This seems like it's just adding unnecessary clutter for the sake of security without any actual real world benefits. I could be wrong though, feel free to provide more information to convince me otherwise.

[ghost]

@LukeTowers hard to convince you, not sure what to suggest.

Basically, Cross-Site Tracing (XST) is a combination of XSS and Trace it's purpose is to steal login data. My reason of suggesting to add it to October is to protect the admin login screen and the user plugin from attackers using this method to try and steal login data.

Most modern browsers turn this off, but it can be bypassed using java and that's why it's a good idea to add it to your .HTaccess

[LukeTowers]

@ayumihamasaki2019 walk me through a theoretical attack.

[bennothommo]

@ayumihamasaki2019 Before you edited your comment (and deleted your comment edit history), there was a mention in the response that you hit a "405 Method not Allowed" response code, which means it actually is not susceptible to TRACE calls. Can you please explain why that is now missing?

[bennothommo]

@ayumihamasaki2019 Ok thanks, it just seemed strange to edit that part out, but no harm - no foul.

I'm still not able to grasp what example you're trying to demonstrate though - the response headers all look reasonable and don't reveal anything sensitive. If you are able to demonstrate a response that reveals sensitive information, you may want to forward it through to Luke at [email protected] or Sam at [email protected] and explain it in detail to them, that way they can determine if it's necessary to include something like this in .htaccess.

For what it's worth, I've had a cursory look at other web-based frameworks (Laravel, Drupal, CakePHP, Slim) and no-one seems to have any sort of mitigation for this method, so either everyone is completely slack with security or this method isn't as dangerous as we thought.

[w20k]

@bennothommo @LukeTowers @ayumihamasaki2019
I will add my 50cent to this issue. It's only relevant to apache version x < 1.3.34 || x < 2.0.55. It was patched in newer versions of apache with a default value set to TraceEnable off.

[ghost]

@bennothommo @w20k @LukeTowers

I deleted my previous two comments as they weren't clear what I was trying to show and exaplain, sorry wrote them at 6am.

Let me try to explain it better:

Apache

In Apache machines you need to block Trace and Track at two various levels, one in the machine scope (httpd.conf) with the code:

RewriteEngine On 
RewriteCond %{REQUEST_METHOD} ^TRACE 
RewriteRule .* - [F] 

And one at the virtual host (.HTaccess) with the code:

RewriteEngine on
RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK)
RewriteRule .* - [F]

Note that Apache versions 1.3.34, 2.0.55 and 2.2 support disabling the TRACE method natively via the ‘TraceEnable’ directive. The key word is support - not turned off by default or patched (you will need to turn it off both sides yourself).

Microsoft IIS

The TRACK method can be added to Microsoft’s URLScan DenyVerbs section. It should not be in the AllowVerbs section in the urlscan.ini file.

Use the URL Scan Tool to deny HTTP TRACE requests or to permit only the methods needed to meet site requirements and policy. The default configurations of Urlscan 2.5 (both baseline and SRP) only permit GET and HEAD methods.

NGINX

The majority of web sites only require the GET, HEAD & POST HTTP methods. Enabling the TRACE or DELETE method can pose a risk to your server leaving it vulnerable to a Cross-Site Tracking attack.

Modify the default.conf file and add the following under “server block” to mitigate the risk of a Cross-Site Tracking attack.

if ($request_method !~ ^(GET|HEAD|POST)$ )
{
    return 405;
}

Modifying the code will return a “405 – Not Allowed” if anyone attempts to use the DELETE, TRACE, PUT or OPTIONS method.

Testing

When testing to identify both the TRACE and TRACK vulnerabilities in the web server you look for two things:

1. The target returns any status code < 400 or >= 600 (405 or 403 is a pass - but can fail the second test still)

2. The target returns the headers which you passed in. (this is the important part of the test)

Basically, _I can inject something into the header and get a 405 Server Response_ and then when a person visit's that website the thing injected into that header is loaded to that user and all the other user's that visit that website.

Hope that makes better sense of what I'm trying to say, sorry my previous comments were not clear at all.

[Samuell1]

https://httpd.apache.org/docs/2.4/mod/core.html#traceenable

Despite claims to the contrary, enabling the TRACE method does not expose any security vulnerability in Apache httpd. The TRACE method is defined by the HTTP/1.1 specification and implementations are expected to support it.

[ghost]

@Samuell1 I'm fully aware of that message and they plan to change it over to something like this:

The TRACE method, while apparently harmless, can be successfully leveraged in some scenarios to steal legitimate users' credentials.

[Samuell1]

What tests? Are you sure you know what you doing? Because i can simply open network in browser and see all stuff publicly that you writing :D Sorry but this sounds to me like when frontend dev starts doing backend :D

[ghost]

@Samuell1 #Trolling

[LukeTowers]

@Samuell1 please refrain from making assumptions about the skill / knowledge of other contributors.

@ayumihamasaki2019 I'm still confused. Modern browsers block JS-triggered TRACE requests, which are required to pivot the availability of TRACE response handling by the server into something malicious:

modern browsers now block the TRACE method in XMLHttpRequest to help mitigate XST.

From https://www.owasp.org/index.php/Cross_Site_Tracing

In regards to your comments on the security setup of OctoberCMS.com (an entirely separate issue that if you have concerns about you should be following the Security Policy):

1. As far as I understand, TRACE is enabled but you can only trigger it yourself manually through hand crafted requests?

2, 3, 4, & 5 is all publicly available information discoverable through a multitude of other methods and not a security concern AFAIK

1. Not sure what you're talking about

2. Meh, you could create a separate issue for that and I'll assign @daftspunk to take care of it when he has time, otherwise it's not super high priority for us

3. "easily hacked". As always, if you have a specific attack that works then please follow the security policy and responsibly disclose it. Otherwise just "enabling security settings" for the sake of having them enabled is not something we're interested in doing.

4. How? Again, responsibly disclose specific vulnerabilities by following our security policy

5. Again, separate issue not related to this one at all.

[LukeTowers]

@ayumihamasaki2019 it seems like you're still just listing items off of a generic security checklist of things to do to make an application more "secure". If you have specific examples of how each of these reported issues can be exploited to cause a security breach then please send them to me via email or at the very least provide a theoretical attack that could take advantage of each of the vectors. We are never going to add something just because it's on a checklist somewhere, every change that is made has to have a solid justification behind it and the understanding / backing of the core developers.

[ghost]

@LukeTowers I give up! You got the wrong attitude as per your previous comment:

adding unnecessary clutter for the sake of security

I was trying to help and it seems like you just can't be bothered or too set in your ways...

[LukeTowers]

@nathan-van-der-werf @Klaasie @martendej @jacobdekeizer Feel free to provide your thoughts in response to my comment instead of just leaving a thumbs down 😛

[jacobdekeizer]

@LukeTowers ayumihamasaki2019 had some good points from a security standpoint. It's not a direct security vulnerability to expose the php and apache versions, but it's good practice to hide these versions from the user. See this link for why it's bad to expose the php and apache versions. Also see securityheaders.io to scan your site for security header issues. I'm not familiar with the other points made.

[nathan-van-der-werf]

@nathan-van-der-werf @Klaasie @martendej @jacobdekeizer Feel free to provide your thoughts in response to my comment instead of just leaving a thumbs down 😛

https://www.owasp.org/index.php/Top_10-2017_A6-Security_Misconfiguration

[Klaasie]

I personally feel like this issue got dismissed on the basis of "not understanding". If that is the case then I think someone with knowledge should've been the judge as to wether this is something to include or not.

[LukeTowers]

@Klaasie the issue was being dismissed due to the specific issues not being explained sufficiently. I'm all for having discussions to make improvements, but they need to be discussions, not just blind adherence to a list someone somewhere posted.

@jacobdekeizer

it's good practice to hide these versions from the user

Personally I'm of the opinion that that's security through obscurity and does nothing except promote a false sense of security as the fact of the matter is that as soon as vulnerabilities become known they are added to the playbook of automated bots scanning the web attempting to take over servers with known vulnerabilities; and those bots don't care if you're telling them what version you're using or not.

@nathan-van-der-werf I don't understand what you're trying to say with the link you sent, could you expand on what you mean?