Blocking TRACE method by configuration files

Created on 20 November 2018, about 6 years ago

Updated 30 January 2023, almost 2 years ago

Problem/Motivation

As a whitepaper from 2003 introduced Cross-Site Tracing (XST) vulnerability, even it requires cross-site scripting vulnerability to be present, the main concept is to harden the blockage of TRACE method by default in configuration files - especially for Apache web server.

Comment by @mr.bailers → regarding exploitation:

- Client-side javascript cannot access httpOnly cookie data
- A TRACE-request will echo back the request data itself (including the httpOnly cookie data)
- Thus, if client-side code can trigger a TRACE request, it could access sensitive data it should not have access to.

Quote by @Wim Leers → from https://tools.ietf.org/html/rfc7231#section-4.3.8:

The TRACE method requests a remote, application-level loop-back of
the request message. The final recipient of the request SHOULD
reflect the message received, excluding some fields described below
[…]
A client MUST NOT generate header fields in a TRACE request
containing sensitive data that might be disclosed by the response.
For example, it would be foolish for a user agent to send stored user
credentials [RFC7235] or cookies [RFC6265] in a TRACE request.

Comment by @David Strauss → :

I agree with making this public.

The "TRACE" verb is only as powerful as it is implemented. It definitely isn't implemented in D7, and I can't find any implementation in D8 that actually performs the risk-creating step of reflecting back request data. (It's a little harder to verify the lack of risk in D8, as the Symfony components recognize the legitimacy of "TRACE" as a method, even though we appear to never handle it in the RFC way.) So, if anything is delivering support for "TRACE," then it's probably the web server or PHP, both of which I'd consider in the "hardening" territory for this.

Proposed resolution

A simple workaround for IIS and Apache is to just block the method in configuration, as in

IIS: "URL Scan" feature
Apache 2.x (the LIMIT feature does not block TRACE)

# .htaccess
RewriteEngine on
RewriteCond %{REQUEST_METHOD} ^TRACE
RewriteRule .* – [F]

Remaining tasks

Agree on the proposal.
Implement the change on configuration file(s).
Backport it to D7 (or even to D6 as well)

User interface changes

None.

API changes

None.

Data model changes

None.

Original report by fgm →

The issue was reported first on security.drupal.org where it was agreed to fix it in the public queue given the risks and the Security Team disclosure policy.

✨ Feature request

Status

Needs work

Version

10.1 ✨

Component

System →

Last updated 3 days ago

No maintainer

Created by

🇭🇺Hungary tatarbj Brussels

Live updates comments and jobs are added and updated live.

Security improvements
It makes Drupal less vulnerable to abuse or misuse. Note, this is the preferred tag, though the Security tag has a large body of issues tagged to it. Do NOT publicly disclose security vulnerabilities; contact the security team instead. Anyone (whether security team or not) can apply this tag to security improvements that do not directly present a vulnerability e.g. hardening an API to add filtering to reduce a common mistake in contributed modules.

ContributionWeekend2019

Incomplete comments

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

Comment almost 2 years ago →
needs-review-queue-bot
The Needs Review Queue Bot → tested this issue. It either no longer applies to Drupal core, or fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

Apart from a re-roll or rebase, this issue may need more work to address feedback in the issue or MR comments. To progress an issue, incorporate this feedback as part of the process of updating the issue. This helps other contributors to know what is outstanding.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

contrib.social Blog FAQ Discussions

Production build 0.71.5 2024