I was able to reproduce this behavior.  I am also able to reproduce with "Location: //malicious.com".

Why does this have security implications?  The server controls the response headers, so it might just return "Location: malicious.com" directly.

By the way, this behavior seems to be intended based on the comment above DoResolveRelativeHost implementation, see
https://code.google.com/p/chromium/codesearch#chromium/src/url/url_canon_relative.cc&sq=package:chromium&q=DoResolveRelativeHost&l=373.

cc'ing original author of that area of the code.

Marking available and tagging OS-All.

Agreed with intended behavior to support protocol-relative URLs. It's useful and universally supported across all browsers.

The security implications arise when an attacker attempts to take advantage of an application with poor server-side validation by injecting a malicious redirect/destination URL via query parameter, where the application does a poor job of validating absolute vs relative URLs. Some real world examples, from a login flow with a pre-defined destination.

// Example 1: Intended use, relative path
https://example.com/login?destination=/home

// Example 2: Intended use, absolute URL
https://example.com/login?destination=https://whitelistedsite.com

// Example 3: Intended use, protocol-relative URL
https://example.com/login?destination=//whitelistedsite.com

// Example 4: Potential for abuse, protocol-relative URL with tab character
https://example.com/login?destination=/%09/malicious.com

I came across this situation recently during a security audit, where we were handling the first three examples, but treated the fourth example like a relative URL, enabling a potential malicious redirect. While we fixed the issue, it was worth noting that the behavior documented in the bug was only observable in Chrome.

This isn't to imply that it's Chrome's responsibility to handle what may fall through the cracks in applications with less-than-perfect validation. However, given the difference in behavior with other browsers and the high potential for abuse, we felt compelled to report the fact that Chrome seems to ignore the tab character in a protocol-relative URL and follow the header regardless.

As you say, this isn't necessarily a bug but it might be nice to fix. Certainly we've done similar things in other cases where small behavior changes can make it easier to write correct web sites.

The only reason this might take a while is that it needs research and changing this kind of thing is high-risk. The code here is used to resolve all URLs, not just in redirects but also web pages, so we need to study our whitespace removal strategies as well as other browsers in various places to make sure everything is right.

I wrote this code very specifically this way (it also allows newlines and line feeds) and I based it on studying other browsers. Either other browsers have changed, or maybe redirects have different rules than links in pages in other browsers.

I would very much like to avoid different rules for links vs. redirects.

This issue has been available for more than 365 days, and should be re-evaluated. Please re-triage this issue.
The Hotlist-Recharge-Cold label is applied for tracking purposes, and should not be removed after re-triaging the issue.

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