New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 779646 link

Starred by 3 users

Issue metadata

Status: WontFix
Owner: ----
Closed: Nov 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows , Chrome , Mac
Pri: 2
Type: Bug



Sign in to add a comment

pushState/replaceState bug allows history injection

Project Member Reported by rsch...@chromium.org, Oct 30 2017

Issue description

Chrome Version       : 62.0.3202.75
OS Version: tested on Win10 and Chrome OS (Pixel 2)
URLs (if applicable) : see repro


What steps will reproduce the problem?
1. Go to google.com and do a search for "amazon smile"
2. Find the result from huffingtonpost.com ("Why Amazon Is Smiling and Charities May Be Losing")
3. Right-click and open in new tab
4. Switch to the new tab

What is the expected result?

Back button stays grayed out, since there's no page to go back to (new tab)


What happens instead of that?

After a few seconds, the back button becomes available. Clicking it takes me to https://www.huffingtonpost.com/?icid=hjx004, a site I never visited.

Inspecting the site, I found this relevant code:


 window.HP.functions.initOnPageLoad = function() {
       window.HP.events.publish("page_loaded"),
       window.HP.functions.resizeFBEmbed(),
       (navigator.userAgent.match(/iPhone/i) || navigator.userAgent.match(/iPad/i)) && setTimeout(function() {
           0 === i.scrollTop() && window.scrollTo(0, 1)
       }, 250),
       window.HP.params.original_url = window.location.href;
       var e = history.state
         , t = "desktop" === HP.params.device && !!HP.params.entryId && "us" === HP.params.edition.id;
       t && 1 === history.length && history.replaceState ? (history.replaceState({
           reload: !0
       }, "Huffington Post", HP.params.edition.baseURL + "?icid=hjx004"),
       history.pushState(e || {
           reload: !0
       }, document.title, HP.params.original_url)) : history.replaceState(e || {}, "", HP.params.original_url)
   }


I'm unclear what exactly it's trying to do, but it seems like it shouldn't be able to alter history.


 
Cc: abdulsyed@chromium.org
Labels: Needs-Triage-M62 Needs-Bisect
Labels: OS-Mac

Comment 3 by dcheng@chromium.org, Oct 30 2017

Cc: creis@chromium.org

Comment 4 by dcheng@chromium.org, Oct 30 2017

It's worth noting that Firefox seems to exhibit the same behavior. It definitely seems undesirable though.

Comment 5 by sdy@chromium.org, Nov 1 2017

Components: -UI>Browser>History UI>Browser>Navigation
that looks like WAI to me. the history API allows for creating arbitrary same-origin history entries

Comment 7 by nasko@chromium.org, Nov 2 2017

I agree with jochen@, this is just pushState executed by the page, which creates navigation entries as per spec. Collecting a trace confirms this:

RenderFrameImpl::didNavigateWithinPage
RenderFrameImpl::didCommitProvisionalLoad id 3, url https://www.huffingtonpost.com/?icid=hjx004

I don't think there is anything actionable here, since it is site behavior and the browser is following the spec.
Status: WontFix (was: Unconfirmed)
Okay, then working as intended. Thanks!

Sign in to add a comment