location.reload() should preserve referrer
Reported by
gsec...@gmail.com,
Mar 7 2017
|
|||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36 Example URL: Steps to reproduce the problem: location.replace() and <meta http-equiv="refresh"> should preserve the current document.referrer value. 1. Observe the current document.referrer value. 2. Reload the page by calling location.reload() 3. Observe that the referrer has changed. What is the expected behavior? What went wrong? The referrer should be preserved upon reload the page. Did this work before? N/A Chrome version: 56.0.2924.87 Channel: stable OS Version: Flash Version:
,
Mar 8 2017
@gsecvic-- Could you please provide a sample file or test case or test steps in detail or expected result screenshot if possible , that would really help us in traiging the issue better. Thanks!
,
Mar 8 2017
Not a network issue.
,
Mar 8 2017
Attaching a sample file to demonstrate the issue:
<!DOCTYPE html>
<script>
var referrer1, referrer2;
function f1() {
referrer1 = ifr.contentWindow.document.referrer;
console.log('initial referrer:', referrer1);
ifr.onload = f2;
ifr.contentWindow.location.reload();
}
function f2() {
referrer2 = ifr.contentWindow.document.referrer;
console.log('referrer after reload:', referrer2);
if (referrer1 != referrer2) {
console.warn("Expected referrers to be the same but they were different");
}
}
</script>
<iframe src="blank.html" id=ifr onload="f1()"></iframe>
,
Apr 12 2017
Assigned to reload master toyoshim@
,
Apr 12 2017
This is intentional implementation to meet a security requirement. See comments at https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/loader/FrameLoader.cpp?dr&l=156
,
Apr 12 2017
Copy and paste comments from the source code I described above: // ClientRedirectPolicy is an indication that this load was triggered by some // direct interaction with the page. If this reload is not a client redirect, // we should reuse the referrer from the original load of the current // document. If this reload is a client redirect (e.g., location.reload()), it // was initiated by something in the current document and should therefore // show the current document's url as the referrer.
,
Apr 13 2017
This bug was filed because the current was found to be prone to causing security problems, and was inconsistent with expectations and with behavior in other browsers. The rationale in the above comment sounds okay in theory, but in practice actually seems to cause more harm than good. The security problem occurs when the server responds to a request with a 5XX error page that calls `location.reload()` after a timeout. Sensitive data in the URL can leak via the Referer header this way. Example of this occurred: 1) User loads page site1.example.com/login.html. This page redirects to site2.example.com/login.html?auth={sensitive_token}. 2) The server on site2.example.com/ responds with a 5XX page with a `location.reload()` call due to an ephemeral error. 3) The browser reloads the page. This time the server responds with a redirect to attacker.com. 4) The sensitive token is leaked via the Referer header to attacker.com.
,
Apr 14 2017
Do you know if there is a spec to define this behavior?
,
Apr 14 2017
FYI, bug entry for WebKit is here; https://bugs.webkit.org/show_bug.cgi?id=104905 The spec for Location.reload() is here. https://html.spec.whatwg.org/multipage/browsers.html#dom-location-reload
,
Apr 14 2017
,
Apr 17 2017
,
Apr 27 2017
Tested the repro on webkit bug:
<a href="?one=1">with query string</a><br/>
<script>document.write("referrer: "+document.referrer)</script><br/>
<button onclick="location.reload(true)">reload</button><br/>
Chrome, Firefox, Edge: fails
Tested repro from comment #4:
Chrome: fails
Firefox, Edge: success.
I read the spec a bit but couldn't quite tell which behavior is "right".
In general, aligning to the predominant behavior and fixing the spec is a fine option for interop issues.
Let's make this available.
If needed, we could talk to the security folks to get their take.
,
Apr 27 2018
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Aug 17
|
|||||||||||
►
Sign in to add a comment |
|||||||||||
Comment 1 by manoranj...@chromium.org
, Mar 7 2017