You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Dan Poirier <po...@pobox.com> on 2011/01/21 19:20:18 UTC
Please vote - how to handle AllowEncodedSlashes
Can we take an informal vote on how best to handle AllowEncodedSlashes?
At present, AllowEncodedSlashes Off (the default) results in any request
containing an encoded slash, %2F, being rejected with a 404.
In 2.0 and trunk, AllowEncodedSlashes On allows the encoded slash, but
does not decode it. This keeps httpd from misinterpreting an encoded
slash in a request as a path separator. I believe this was always
the intended behavior.
In 2.2, AllowEncodedSlashes On allows the encoded slash, and decodes it.
This has caused problems for multiple people (see bugzilla, e.g. PR
35256), but has been the behavior since 2.2.0 (introduced in
2.1.something, I believe unintentionally).
All the doc, even in 2.2, reflects the 2.0/trunk behavior.
How to handle?
[ ] 1. change the 2.2 doc to reflect the actual 2.2 behavior
[ ] 2. backport the trunk behavior as-is, so 2.0/2.2/trunk behave the same
[ ] 3. backport the trunk behavior, but using a new option to avoid
breaking existing configurations that might depend on the current
behavior
Thanks,
Dan
Re: Please vote - how to handle AllowEncodedSlashes
Posted by Dan Poirier <po...@pobox.com>.
I checked and the server accepts encoded slashes in query strings,
regardless of AllowEncodedSlashes. So we're only concerned here with
path info.
Right now in trunk, the default is to not accept encoded slashes, and if
you turn AllowEncodedSlashes on, they are not decoded. This seems safe
and matches the documentation, so I don't think trunk needs to be
changed (unless somebody really needs the 2.x behavior, in which case
they could add an option for that, but I don't need that.)
In 2.2, the default is to not accept encoded slashes, but if you turn
AllowEncodedSlashes On, they are decoded. This is contrary to the
documentation and the trunk behavior, and seems potentially unsafe. But
just changing to the trunk behavior could break users when they upgrade
between 2.2 releases, so I think the best compromise for 2.2 is to add
a new option to accept the slashes without decoding them. I have a
patch to do that and I'll propose it in 2.2 STATUS for the usual vote.
For 2.0, I think backporting whatever is done in 2.2 can be proposed in
the usual way if anyone wants it, so we don't need to discuss that here.
Thanks for everyone's input on this.
Dan
RE: Please vote - how to handle AllowEncodedSlashes
Posted by "Plüm, Rüdiger, VF-Group" <ru...@vodafone.com>.
> -----Original Message-----
> From: Dan Poirier [mailto:poirier@pobox.com]
> Sent: Mittwoch, 26. Januar 2011 16:35
> To: dev@httpd.apache.org
> Subject: Re: Please vote - how to handle AllowEncodedSlashes
>
> On 01/21/2011 01:20 PM, Dan Poirier wrote:
> > Can we take an informal vote on how best to handle
> AllowEncodedSlashes?
> >
> > At present, AllowEncodedSlashes Off (the default) results
> in any request
> > containing an encoded slash, %2F, being rejected with a 404.
> >
> > In 2.0 and trunk, AllowEncodedSlashes On allows the encoded
> slash, but
> > does not decode it. This keeps httpd from misinterpreting
> an encoded
> > slash in a request as a path separator. I believe this was always
> > the intended behavior.
> >
> > In 2.2, AllowEncodedSlashes On allows the encoded slash,
> and decodes it.
> > This has caused problems for multiple people (see bugzilla, e.g. PR
> > 35256), but has been the behavior since 2.2.0 (introduced in
> > 2.1.something, I believe unintentionally).
>
> One correction for the record - 2.0 behaves like 2.2. I doubt it's
> worth fixing, though.
>
>
But this changes a lot. If 2.0 is like 2.2 then nothing breaks for people
moving from 2.0 to 2.2. So we should fix in trunk and set it to a sane default
(whatever this is, see discussion in the thread) and the backport to 2.2 should
preserve the current behaviour and just offer an option to enable the trunk default.
Regards
Rüdiger
Re: Please vote - how to handle AllowEncodedSlashes
Posted by Dan Poirier <po...@pobox.com>.
On 01/21/2011 01:20 PM, Dan Poirier wrote:
> Can we take an informal vote on how best to handle AllowEncodedSlashes?
>
> At present, AllowEncodedSlashes Off (the default) results in any request
> containing an encoded slash, %2F, being rejected with a 404.
>
> In 2.0 and trunk, AllowEncodedSlashes On allows the encoded slash, but
> does not decode it. This keeps httpd from misinterpreting an encoded
> slash in a request as a path separator. I believe this was always
> the intended behavior.
>
> In 2.2, AllowEncodedSlashes On allows the encoded slash, and decodes it.
> This has caused problems for multiple people (see bugzilla, e.g. PR
> 35256), but has been the behavior since 2.2.0 (introduced in
> 2.1.something, I believe unintentionally).
One correction for the record - 2.0 behaves like 2.2. I doubt it's
worth fixing, though.
Re: Please vote - how to handle AllowEncodedSlashes
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 1/21/2011 2:22 PM, William A. Rowe Jr. wrote:
>
> # Defaults to off, set to On to preserve %2F, Decode to use '/',
> # or choose a unique pattern to avoid path exploits directed at
> # back end servers. Note that either On or Decode can be very
> # risky to back end servers, and may circumvent either httpd's
> # or back end server access restrictions. A third option to
> # accept encoded slashes is to assign them to a special value
> # which would not cause httpd or back end servers to treat them
> # as special characters, as one example, for the private private
> # unicode point F02F to represent %2f, enable
> # AllowEncodedSlashes %ef%80%af
>
> I would suggest we push for recognition of second-meanings of the basic
> ASCII characters %00 - %7F As unicode private code points F000-F07F,
> and coordinate this allocation with the ConScript effort;
> http://en.wikipedia.org/wiki/ConScript_Unicode_Registry
That needs to be %ee%be%af in the example above. In fact, it should
not be replaced with an encoded string, but the actual unicode pattern,
e.g. a three octal sequence. Let me think about the syntax for a bit, so
that utf-8 is simpler to read and type in the config. I expect that this
will be a different between "%ee%be%af" and unquoted %ee%be%af, both of
which would be valid but would have completely different meanings (either
escaped or un-escaped/decoded, respectively).
I goofed, to dodge the WGL4, some win32 silliness, and the AGL, it looks
like it needs a different range. The EF00-EF7F range looks appropriate
and I'm willing to advance this first as a ConScript proposal, and later
raise it to the Unicode body.
Essentially the definition would state something like;
Many network transport, storage and carriage control layers use the
basic ASCII set of characters to define specific behaviors. One of
the earliest examples is the NULL termination behavior of the 0000
code point for string storage.
This convention proposes adoption of PUA code points EF00 - EF7F to
map such reserved characters for safe transport for presentation
purposes, avoiding all primary-use behaviors of their 0000-007F
encoding by transport, storage or carriage control protocols.
As two examples, the code point EF2F represents the '/' FORWARD_SLASH
character independent of and explicitly prohibiting the function of
002F as a file path delimiter, while the code point EF00 could be
used to pass a 0000 glyph which averts NULL termination of the
character string.
I just happen to like the EF00 code page since the implicit 'y' in the
middle of the word should be voiced in its pronunciation.
Re: Please vote - how to handle AllowEncodedSlashes
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 1/21/2011 12:20 PM, Dan Poirier wrote:
> Can we take an informal vote on how best to handle AllowEncodedSlashes?
s/vote/poll/ :)
> At present, AllowEncodedSlashes Off (the default) results in any request
> containing an encoded slash, %2F, being rejected with a 404.
>
> In 2.0 and trunk, AllowEncodedSlashes On allows the encoded slash, but
> does not decode it. This keeps httpd from misinterpreting an encoded
> slash in a request as a path separator. I believe this was always
> the intended behavior.
>
> In 2.2, AllowEncodedSlashes On allows the encoded slash, and decodes it.
> This has caused problems for multiple people (see bugzilla, e.g. PR
> 35256), but has been the behavior since 2.2.0 (introduced in
> 2.1.something, I believe unintentionally).
>
> All the doc, even in 2.2, reflects the 2.0/trunk behavior.
Whoops :)
> [X] 3. backport the trunk behavior, but using a new option to avoid
> breaking existing configurations that might depend on the current
> behavior
AllowEncodedSlashes should become a quad-state;
Off - Reject 404
On - Old 2.0 behavior
Decode - New 2.2 behavior
%nn[%nn...] - Replacement pattern for alternate encoding, which must
"[string]" be expressed in %-escaped form or quoted to distinguish
between the first three forms (valid bool keywords and
the Decode keyword).
The example could provide
# Defaults to off, set to On to preserve %2F, Decode to use '/',
# or choose a unique pattern to avoid path exploits directed at
# back end servers. Note that either On or Decode can be very
# risky to back end servers, and may circumvent either httpd's
# or back end server access restrictions. A third option to
# accept encoded slashes is to assign them to a special value
# which would not cause httpd or back end servers to treat them
# as special characters, as one example, for the private private
# unicode point F02F to represent %2f, enable
# AllowEncodedSlashes %ef%80%af
I would suggest we push for recognition of second-meanings of the basic
ASCII characters %00 - %7F As unicode private code points F000-F07F,
and coordinate this allocation with the ConScript effort;
http://en.wikipedia.org/wiki/ConScript_Unicode_Registry
Re: Please vote - how to handle AllowEncodedSlashes
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 1/21/2011 12:20 PM, Dan Poirier wrote:
> How to handle?
>
> [ ] 1. change the 2.2 doc to reflect the actual 2.2 behavior
> [ ] 2. backport the trunk behavior as-is, so 2.0/2.2/trunk behave the same
> [ ] 3. backport the trunk behavior, but using a new option to avoid
> breaking existing configurations that might depend on the current
> behavior
You have me a little confused. I actually believe we need to forward port
the 2.0 behavior, allowing people to retain the 'new' behavior in 2.2 if
they so wish (with the Decode option).
I believe more people than not are having problems with the new behavior,
and there are two POLA (pricipal of least astonishment) which are competing,
those not yet upgraded from 2.0 to 2.2, vs. those doing a minor upgrade in
the 2.2 line. The 2.2 behavior is so radically different that it makes
more sense to clearly document the change in 2.2 CHANGES and ship the 2.0
behavior, since for most users the 2.2 behavior looks broken to them.
Re: Please vote - how to handle AllowEncodedSlashes
Posted by Eric Covener <co...@gmail.com>.
> [ x] 3. backport the trunk behavior, but using a new option to avoid
> breaking existing configurations that might depend on the current
> behavior
Re: Please vote - how to handle AllowEncodedSlashes
Posted by Ivan Ristic <iv...@gmail.com>.
I've been following the discussion on this topic and, and I'd like to
share a thought with you.
>From the security perspective, allowing end users to control how %2f
is treated is problematic. Consider the situation in which you have
some sort of a HTTP monitoring device (either passive, or a reverse
proxy) in front of httpd. For this device to be effective, it must
interpret traffic in the way identical to the interpretation of the
web server. But if the %2f treatment is configurable, the device won't
know if /path%2fto is the same as /path/to. That creates a problem,
for example, when the device has to apply two different policies based
on the path (e.g., one policy for /path, another for /path/to).
A similar problem arises when httpd is used as a reverse proxy,
forwarding traffic to a backend server that handles %2f differently.
There are also other issues related to case sensitivity, the use of
other characters as path separators, and so on.
To sum it up, it would be best to choose one correct way to handle a
%2f and stick with it. That means getting rid of the
AllowEncodedSlashes directive, which was a bad idea to begin with. (On
the other hand, if you think that AllowEncodedSlashes should stay,
then Apache should add new directives to add all the other evasion
techniques that apply in reverse-proxy mode.)
On Mon, Jan 24, 2011 at 5:58 PM, Jim Jagielski <ji...@jagunet.com> wrote:
>
> On Jan 22, 2011, at 3:45 AM, Ruediger Pluem wrote:
>
>>
>>
>>
>> [X] 4. backport the trunk behavior, but using a new option to set the current 2.2
>> behavior to avoid breaking existing configurations from 2.0/trunk but enable
>> 2.2 users that rely on the new 2.2 behavior to get this back
>>
>>
>
> +1
--
Ivan Ristić
Re: Please vote - how to handle AllowEncodedSlashes
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Jan 22, 2011, at 3:45 AM, Ruediger Pluem wrote:
>
>
>
> [X] 4. backport the trunk behavior, but using a new option to set the current 2.2
> behavior to avoid breaking existing configurations from 2.0/trunk but enable
> 2.2 users that rely on the new 2.2 behavior to get this back
>
>
+1
Re: Please vote - how to handle AllowEncodedSlashes
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 1/24/2011 7:55 AM, Eric Covener wrote:
> On Mon, Jan 24, 2011 at 8:53 AM, Eric Covener <co...@gmail.com> wrote:
>>> But it could only break people who
>>> have the non-default "AllowEncodedSlashes On" configured - I wonder how
>>> common that is?
>>
>> Pretty common question/answer for %2f in PATH_INFO or query string,
>> much much rarer as a FAQ for wanting either %2f to be used verbatim to
>> map a file or for it to be used as a / to map a directory.
>>
>> We may be affecting even the former group of folks if they've taught
>> their CGI/etc that the encoded slashes will be decoded.
>
> Although I am admittedly just barely 51/49 over choice 3 and choice 4,
> so don't count this too strongly against any consensus for 4.
I believe we could and perhaps should treat query string parts separately
if we don't already. The PATH_INFO folks should not be using %2F constructs
at all ("encoded slashes considered harmful") in the path-part.
In any case, my suggestion for "value" as a fourth-way forward should be
considered an enhancement after we've normalized the usual reject/accept
with decode/undecoded rule set.
Taking my idea of 0xee 0xbe 0xaf one step further, mod_proxy can further
be trained to re-encode this not as %ee%be%af, but as %2f :)
Re: Please vote - how to handle AllowEncodedSlashes
Posted by Eric Covener <co...@gmail.com>.
On Mon, Jan 24, 2011 at 8:53 AM, Eric Covener <co...@gmail.com> wrote:
>> But it could only break people who
>> have the non-default "AllowEncodedSlashes On" configured - I wonder how
>> common that is?
>
> Pretty common question/answer for %2f in PATH_INFO or query string,
> much much rarer as a FAQ for wanting either %2f to be used verbatim to
> map a file or for it to be used as a / to map a directory.
>
> We may be affecting even the former group of folks if they've taught
> their CGI/etc that the encoded slashes will be decoded.
Although I am admittedly just barely 51/49 over choice 3 and choice 4,
so don't count this too strongly against any consensus for 4.
--
Eric Covener
covener@gmail.com
Re: Please vote - how to handle AllowEncodedSlashes
Posted by Eric Covener <co...@gmail.com>.
> But it could only break people who
> have the non-default "AllowEncodedSlashes On" configured - I wonder how
> common that is?
Pretty common question/answer for %2f in PATH_INFO or query string,
much much rarer as a FAQ for wanting either %2f to be used verbatim to
map a file or for it to be used as a / to map a directory.
We may be affecting even the former group of folks if they've taught
their CGI/etc that the encoded slashes will be decoded.
Re: Please vote - how to handle AllowEncodedSlashes
Posted by Dan Poirier <po...@pobox.com>.
On Sun. 2011-01-23 at 12:25 PM EST, Stefan Fritsch <sf...@sfritsch.de> wrote:
> On Sat, 22 Jan 2011, Ruediger Pluem wrote:
>>> How to handle?
>>>
>>> [ ] 1. change the 2.2 doc to reflect the actual 2.2 behavior
>>> [ ] 2. backport the trunk behavior as-is, so 2.0/2.2/trunk behave the same
>>> [ ] 3. backport the trunk behavior, but using a new option to avoid
>>> breaking existing configurations that might depend on the current
>>> behavior
>>
>> [X] 4. backport the trunk behavior, but using a new option to set the current 2.2
>> behavior to avoid breaking existing configurations from 2.0/trunk but enable
>> 2.2 users that rely on the new 2.2 behavior to get this back
>
> +1.
>
> AIUI, this is the same as on/off/decode in Bill's proposal.
Right, I think we have two new choices added to my original list:
[ ] 4. change "AllowEncodedSlashes On" in 2.2 to match the 2.0/trunk
behavior, but add a new option ("Decode") that would behave
like "AllowEncodedSlashes On" in 2.2 behaves now.
[ ] 5. Choice 4, and add another new option to specify what %2F should
decode to. (Maybe this would be an optional parameter to Decode
rather than a separate option.)
To my mind, (4) has the drawback of possibly breaking people who do a
minor upgrade from 2.2.x to 2.2.x+1. But it could only break people who
have the non-default "AllowEncodedSlashes On" configured - I wonder how
common that is?
Note that we could do (3) or (4) now, and add (5) later.
Bill would like (5) to provide a way to specify Unicode strings. I'm
fine with that, but if we do, perhaps we should consider providing that
in a more general form than just for this directive? (Maybe that's what
Bill is proposing?)
Dan
Re: Please vote - how to handle AllowEncodedSlashes
Posted by Stefan Fritsch <sf...@sfritsch.de>.
On Sat, 22 Jan 2011, Ruediger Pluem wrote:
>> How to handle?
>>
>> [ ] 1. change the 2.2 doc to reflect the actual 2.2 behavior
>> [ ] 2. backport the trunk behavior as-is, so 2.0/2.2/trunk behave the same
>> [ ] 3. backport the trunk behavior, but using a new option to avoid
>> breaking existing configurations that might depend on the current
>> behavior
>
> [X] 4. backport the trunk behavior, but using a new option to set the current 2.2
> behavior to avoid breaking existing configurations from 2.0/trunk but enable
> 2.2 users that rely on the new 2.2 behavior to get this back
+1.
AIUI, this is the same as on/off/decode in Bill's proposal.
Re: Please vote - how to handle AllowEncodedSlashes
Posted by Ruediger Pluem <rp...@apache.org>.
On 01/21/2011 07:20 PM, Dan Poirier wrote:
> Can we take an informal vote on how best to handle AllowEncodedSlashes?
>
> At present, AllowEncodedSlashes Off (the default) results in any request
> containing an encoded slash, %2F, being rejected with a 404.
>
> In 2.0 and trunk, AllowEncodedSlashes On allows the encoded slash, but
> does not decode it. This keeps httpd from misinterpreting an encoded
> slash in a request as a path separator. I believe this was always
> the intended behavior.
>
> In 2.2, AllowEncodedSlashes On allows the encoded slash, and decodes it.
> This has caused problems for multiple people (see bugzilla, e.g. PR
> 35256), but has been the behavior since 2.2.0 (introduced in
> 2.1.something, I believe unintentionally).
>
> All the doc, even in 2.2, reflects the 2.0/trunk behavior.
>
> How to handle?
>
> [ ] 1. change the 2.2 doc to reflect the actual 2.2 behavior
> [ ] 2. backport the trunk behavior as-is, so 2.0/2.2/trunk behave the same
> [ ] 3. backport the trunk behavior, but using a new option to avoid
> breaking existing configurations that might depend on the current
> behavior
[X] 4. backport the trunk behavior, but using a new option to set the current 2.2
behavior to avoid breaking existing configurations from 2.0/trunk but enable
2.2 users that rely on the new 2.2 behavior to get this back
Regards
Rüdiger