Contrib.social

Blocking TRACE method by configuration files

Open on Drupal.org →
Created on 20 November 2018, over 6 years ago
Updated 30 January 2023, over 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 2 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.

Sign in to follow issues

Comments & Activities

Not all content is available!

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

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024