1042347 - %2e entered in URL bar not normalized leading to denormalized request

Reporter

Description

•

10 years ago

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.153 Safari/537.36 Steps to reproduce: 1. I started a local server in bash to log request paths. """ $ python -m SimpleHTTPServer Serving HTTP on 0.0.0.0 port 8000 ... """ 2. I started Firefox (30.0 for Mac OS). 3. I entered "http://127.0.0.1/%2e" in the URL bar. (U+2e is '.'. See ASCII equivalence in spec sections quoted below) 4. I switched back to my shell and hit enter to create a break in the log 5. I entered "http://127.0.0.1/." in the URL bar. Actual results: I saw in the console running SimpleHttpServer: """ 127.0.0.1 - - [22/Jul/2014 17:26:56] "GET /%2e HTTP/1.1" 301 - 127.0.0.1 - - [22/Jul/2014 17:26:56] "GET / HTTP/1.1" 200 - [some favicon related requests elided] 127.0.0.1 - - [22/Jul/2014 17:26:56] "GET / HTTP/1.1" 200 - """ Expected results: I was surprised by the "GET /%2e". I believe the correct result should be a single request of "GET /" for both URLs like """ 127.0.0.1 - - [22/Jul/2014 17:26:56] "GET / HTTP/1.1" 200 - [some favicon related requests elided] 127.0.0.1 - - [22/Jul/2014 17:26:56] "GET / HTTP/1.1" 200 - """ ---- Since paths are used to decide which cookies to send, doing as much normalization on the path component before sending it reduces the attack surface of web applications. Perhaps some normalization step ignores encoded dots. I have not tried to see if I can trick Firefox into sending cookies for a more specific path instead of ones for a more general path based on encoded dot segments. Since cookie paths are not widely used and this would probably require socially engineering a user, I consider this low potential risk. ---- RFC 3986 says """ URIs that differ in the replacement of an unreserved character with its corresponding percent-encoded US-ASCII octet are equivalent """ and "." is an unreserved character. So "http://127.0.0.1:8000/" is equivalent, post path normalization, to "http://127.0.0.1:8000/." which is equivalent to "http:/127.0.0.1:8000/". RFC 3986 says """ The path segments "." and "..", also known as dot-segments, are defined for relative reference within the path name hierarchy. However, unlike in a file system, these dot-segments are only interpreted within the URI path hierarchy and are removed as part of the resolution process (Section 5.2). """ RFC 7230 (HTTP Request Syntax) suggests that the GET request path is syntactically an absolute-path and is not required to be an absolute&resolved path, but it seems odd to skip dot segment resolution when a dot is encoded.

Mike Samuel

Reporter

Comment 1

•

10 years ago

The URLs I entered had port 8000 in them, so steps 3 and 5 should have "http://127.0.0.1:8000/%2e" and "http://127.0.0.1:8000/." instead of "http://127.0.0.1/%2e" and "http://127.0.0.1/."

YF (Yang)

Updated

•

9 years ago

Status: UNCONFIRMED → NEW

Component: Untriaged → Networking

Ever confirmed: true

OS: Mac OS X → All

Product: Firefox → Core

Hardware: x86 → All