Page MenuHomePhabricator

Investigate "AllowEncodedSlashes" Apache setting
Open, WishlistPublic

Description

See PHI2021. An install encountered an error similar to this in their logs:

AH00026: found %2f (encoded '/') in URI (decoded='...'), returning 404

Phabricator legitimately encodes / as %2F in some contexts, and expects Apache to route these requests normally.

The directive:

AllowEncodedSlashes NoDecode
https://httpd.apache.org/docs/2.4/mod/core.html#allowencodedslashes

...may be relevant here.

The reporting install uses Apache + PHP-FPM, which isn't common. It's possible this is specific to Apache + PHP-FPM.

Likely actions here are:

  • Try to reproduce the error.
  • See if AllowEncodedSlashes NoDecode fixes it.
  • Add a setup self-test for encoding / as %2F, and raise guidance about AllowEncodedSlashes NoDecode.

Event Timeline

epriestley triaged this task as Wishlist priority.Mar 13 2021, 5:40 PM
epriestley created this task.

See also T13644, which appears to be the origin of the particular requests observed in PHI2021.

This reproduces locally.

In Diffusion, we also encode slashes in the URI (for example, when viewing branch a/b), but double-encode them during responses and single-decode them from requests, with the expectation that the webserver will do one decoding pass. This is why this issue doesn't manifest in Diffusion.

The symbol logic does not do the same thing, but should. This would avoid the problem in all known natural cases (i.e., leaving us with no known case where Phabricator itself legitimately generates a URI containing %2F).

AllowEncodedSlashes On and AllowEncodedSlashes NoDecode are both likely safe, and On is "more correct": it treats these characters like any other characters. However, AllowEncodedSlashes On has some security warnings in the Apache docs. These are almost certainly about applications doing something silly, but who knows.

It doesn't seem worth the effort to do a setup test for this since all the settings are basically moot. The upshot is:

  • For any value of this setting, Phabricator's behavior is correct in all known, legitimate cases, where the user is accessing a URI that Phabricator itself generated.
  • If a user accesses a URI containing %2f (which Phabricator will never generate), Apache has different behavior depending on the setting. Here's what Apache will pass to Phabricator for the requests /x%2Ey and /x%2Fy. The values it is "supposed" to pass are /x.y and /x/y, respectively:
Request/x%2Ey/x%2FyNotes
AllowEncodedSlashes Off/x.yRaw 404Default, Emits Error Log
AllowEncodedSlashes NoDecode/x.y/x%2FyIncorrect Behavior
AllowEncodedSlashes On/x.y/x/yCorrect Behavior, Strongly Discouraged in Documentation

If you don't like the raw 404 or the log warning, you can set AllowEncodedSlashes NoDecode to silence the log, albeit with technically incorrect (but safe) routing behavior for these URIs. If you don't like technically incorrect behavior and trust that Apache's dire warning about security implications is just about application behavior, you can set AllowEncodedSlashes On.

epriestley claimed this task.

Given the generally high degree of mootness here, I'm not planning to add a setup test or recommend installs adjust the setting.

A point against AllowEncodedSlashes Off which I hadn't connected the dots on is that "security researchers" from HackerOne will report URLs like this as "content injection vulnerabilities" for all time:

https://secure.phabricator.com/%2FOFFICIAL_Send_All_Your_Bitcoin_to_Elon_Musk

This URI includes the sequence %2F, which results in a default Apache 404 page with the URI in the body if AllowEncodedSlashes is Off.

Since these reports are mildly annoying, I intend to change Phacility production hosts to AllowEncodedSlashes NoDecode or AllowEncodedSlashes On depending on how brave I'm feeling. I still don't plan to issue any guidance to other installs about this setting.