Single and double dot segments in paths cannot be represented – Premature decoding of %2e character sequences.

[alwinb]

It is currently impossible to represent URLs (note: URLs, not URL-strings) that have paths that contain single or double dot segments, making it impossible, for example, to address files or directories named . or ...

Example: According to the specification, the URL-string http://asd/efg/%2e%2e/ should resolve to http://asd/. The /%2e%2e/ part is considered equivalent to /../ and is hence interpreted as a move to the parent directory. The same holds forhttp://asd/efg/.%2e/.

I propose to change this on account of the following:

• Currently (at least) Safari does not shorten the url, and maintains the /%2e%2e/ segment in the path. As long as there is no consensus, we may be still able to change this!

• It should be possible to represent URLs (not URL-strings) with single and double dot path components as URL-strings.

• It is not elegant and looks like a standardization of buggy parsing/ resolution algorithms. I cannot help but see this as a 'premature decoding' of the %2e sequences.

I see . and .. sequences in URL-strings as syntactic constructs, similar to the ?, # and / characters. URLs with path components that contain one of the ?, # or / characters can be represented by percent encoding them, e.g. by using %3f, %23, or %2f. Why not allow the same here – while we still can?

[annevk]

Because the difference between URL parsers can be exploited by attackers, so it's better to be conservative. Did you test Safari Technology Preview? I'm pretty sure they've fixed this.

[achristensen07]

Yes, I have indeed fixed this in current WebKit. You can verify this with Safari Technology Preview at https://developer.apple.com/safari/technology-preview/
We discussed this in #87

[achristensen07]

https://bugs.webkit.org/show_bug.cgi?id=164142 was WebKit conforming to the resolution of #87

[annevk]

Thanks for confirming. Closing this since we don't want to change this because of security. Happy to answer any further questions though @alwinb .

[alwinb]

So after reading up a bit, (I need to let it sink in for a while) is it correct that at the moment, no percent decoding (thus normalization) is done on the path at all except for only and exactly those single and double dot path sequences, and that this is special-cased to prevent servers from being tricked to move beyond their document root?

[annevk]

Yes.

[alwinb]

Thanks.

For the record, I do think the solution is somewhat unsatisfactory. I appreciate the safety issue, but I'm not sure about the tradeoff, nor the effectiveness. Servers that fall for such an attack may fall for http://example.com/..%2fsensitive_info.txt as well, for example.