This may be deemed a security vulnerability in a particular website or service, but I'm unconvinced that this is a browser security vulnerability.

Within the web platform, the security principal is the origin (Scheme+Host+Port). The remainder of the URL (specifically, the path and fragment) is not a part of the security identifier and does not serve as a security boundary. That's why, for instance, a page at https://example.com/a/ is allowed to freely navigate a frame to https://example.com/b/ and then document.write arbitrary HTML and script into that latter page.

To clarify upon the original report, the issue here isn't about anything being overwritten, it's about how URLs are canonicalized on the client vs. on the server.

The client requests:

  https://example.com/real/attackerchosen/..%2f 

The server returns

  https://example.com/real/

... having normalized the /..%2f sequence into /../ which it then uses to traverse up to the parent folder (see also Path Traversal Attacks).

However, the client does not know or care about the server's normalization and as such it resolves relative URIs against the path component of the current URL (https://example.com/real/attackerchosen/) instead of relative to the path component of the URL that the server ended up using.

In terms of exploitability, this would seem to require the server to allow an attacker to host content within a subfolder of the root. A server that permits this would almost certainly be vulnerable to direct script injection, because as noted in #1, the same origin policy does not care about URL path.  

Thanks for the reply, and for clarifying the description.

This is indeed a canonicalization issue,  All major web browsers (e.g. Firefox, Chromium, Edge) and HTTP servers (e.g. nginx, Apache HTTPd) with default or basic settings (server-side URL process with PHP/NodeJS can potentially affect the result) are vulnerable to this issue.

This is indeed a issue relating to canonicalization, as references to RFC-1738 suggest in the full report (https://git.bmoine.fr/relative-path-overwrite/blob/master/README.md).

When I talk about overwriting, I'm actually talking about the visible effect following the interpretation of the relative link by the web browser as depicted on frame 2 of the screenshot.

When the client send a request to https://example.com/real/attackerchosen/..%2f (frame 1 of the screenshot), the index page corresponding to https://example.com/real/ is delivered by the server following the standardization of the URI (frame 2), but the client doesn't use this standardized/canonicalized URI and interprets relative links (frame 3) from a base URI that shouldn't exist (e.g. https://example.com/real/attackerchosen/). Then, by using this "overwrite" process, a arbitrary resource (e.g. script, stylesheet) can be loaded (frame 4) allowing attack to perform XSS, phishing attack, etc.

Deleted: rpo.png 70.5 KB

	rpo.png 70.5 KB View Download

The point here is that a website that allows upload of files in this way is already vulnerable, even without mismatching canonicalizations.

An attacker with permission to upload untrusted HTML+Script to an "untrusted" subfolder of the domain can run script in the security context of the affected site, reading its cookies and storage, issuing Same-Origin XMLHttpRequests etc.

For phishing, trojan content can simply call

   window.history.pushState('obj', 'newtitle', '/AnythingIWant');

...to change the displayed URL to any path they like without actually navigating anywhere.

In fact, it's not a matter of URI phishing but a script injection here...

The resource inclusion works even if the arbitrary uploaded resource (such as javascript file) is returned with text/plain MIME type, hence the web browser will load the payload (while it would not be possible with direct access, even with HTML file because of MIME type) without having to perform any kind of HTML tag reflection to the DOM.

For example, assuming that we're only able to upload image file to the HTTP server, we can still perform script injection if we're able to control the output filename. I was able to spot this case on a WEB platform running an Amazon AWS bucket for hosting its resources...

Update on 2018/01/09: This report has been shared with Mozilla via Bugzilla and The Internet Bug Bounty Project via HackerOne.

Report links:

 - https://bugzilla.mozilla.org/show_bug.cgi?id=1428737
 - https://hackerone.com/reports/303271

Please note that these reports are private, but are shared so that disclosure and decision can be coordinated with browser and server vendors.

Please let me know if you need more information!

RE #6: The mention of "phishing" as a threat comes from your comment #4.

With regard to stored XSS (aka "script injection"), yes, if we consider a website that:

  1. Performs URI normalization and allows path traversal 
  2. Permits file uploads to a subfolder of the root path
  3. Allows attacker control of the uploaded filename
  4. Re-serves untrustworthy uploaded content with a MIME type that is permitted[i] as a SRC for a SCRIPT (specifically, NOT any of the types image/*, audio/*, video/*, CSV or any non-script type with a |X-Content-Type-Options: nosniff| response header)

Then yes, such a site would be vulnerable to a stored XSS attack.

However, to reiterate, I don't think this represents a vulnerability in web browsers.

[i] see Issue 433049

Thank you all for your answers, I fully understand your position regarding this bug.

Despite the results found when participating in Bug Bounty programs where the HTTP server operated was Apache HTTPd, after setting up a test Apache HTTPd server, it seems that versions next to v2.2.32 are no longer vulnerable.

In fact, operating a container-based infrastructure, I couldn't check versions prior to Apache HTTPd version 2.2.32 (see https://hub.docker.com/r/library/httpd/tags/).

So for the time being, I can only confirm that all version of nginx are affected by this vulnerability, since the latest version of nginx (v1.13.8) still seems vulnerable.

Tests links (see test lab sources: https://git.bmoine.fr/rpo-lab):

 - Apache HTTPd v2.4.29: http://vps.bmoine.fr:8080/upload/..%2F
 - nginx v1.13.8: http://vps.bmoine.fr:8081/upload/..%2F

I would be very grateful if you could help me in any manner so that nginx can take remedial action on this vulnerability.

RE #11: Per their reporting page, "All nginx security issues should be reported to security-alert@nginx.org." 

I'm curious: For the patched version of Apache, what happens? Does the server return a 404? Or does it return a redirect to the normalized path name?

I just realized that HSTS prevents user to browse test links...

Apache HTTPd returns a 404 as it should be done with nginx.

Deleted: Screenshot_20180110-181802.png 48.5 KB

	Screenshot_20180110-181802.png 48.5 KB View Download

Update on 2018/01/13: This report has been mailed to nginx (security-alert@nginx.org).

Thanks for filing the issue with the nginx team! 

As I don't think there's any work for Chrome to do here, I'll resolve this issue.

Update on 2018/01/15: nginx confirmed that Microsoft IIS is also affected by this vulnerabilty.
Update on 2018/01/20: This report has been mailed to Microsoft Security team (secure@microsoft.com).

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot