I can reproduce this flakily on a Linux laptop, though I cannot interact with the spoofed page (and it eventually goes blank). Mind taking a look at this, nasko@

Just reading the attached repro files, it looks like it will flood the browser process with navigations, which will make the page indeed be unresponsive. The eventually going blank is when the paint IPCs are processed after all of the navigation IPCs in the queue before the paint ones are processed.

Assigning to creis@ for now, since I won't be able to look at it in depth for a couple of days.

I think this boils down to  issue 497588 , where a tab becomes unresponsive immediately after committing a new navigation.  That's a fairly low severity spoof because the user can't interact with it, and kenrb@ implemented a mitigation where it goes blank after 2 seconds.

In my attempts to repro, the page always goes blank after a short delay, both on Linux and Windows.  I'm sure that it's possible to tweak the parameters to DoS the browser and delay the blank paint, but that's fragile and is unlikely to work well across machines.  It also boils down to IPC DoS in general (which is  issue 394296 ).

I don't think there's much else to do here.  Ken, do you see anything else we should change or tweak here, or should this be a duplicate of  issue 497588 ?  (Is there some way that this page could deterministically break the paint timer that we should look into?)

The timer is actually set to 4 seconds. Locally, the spoofed content doesn't display for longer than that, which would be working as intended. Has anybody been able to make it display for longer than that?

For the record, the opinion on security risk was that a page could contain instructions to do something like call a phone number, and a spoofed URL above it could give it unwarranted credibility. A relatively short threshold seemed like it would mitigate this risk, so you would need the content displayed for a significant amount of time underneath the spoofed URL.

Yes by changing the setTimeout() or the timer value will make the fake page stable and longer.


Thank you  

Hi , 

However i would like to add few more points the above bug works in Android OS  i.e Chrome, Dev , Beta , Canary as well.
Just replacing  location parameter to http://m.facebook.com/index.php 

w.location.replace('http://www.m.facebook.com/index.php?'+n);n++;

Some Attachment for reference. 
Thank you 

Deleted: Chrome-1.png 24.8 KB

	Chrome-1.png 24.8 KB View Download

Deleted: Chrome-2.png 24.2 KB

	Chrome-2.png 24.2 KB View Download

Dear Team , 

Any updates on the above issue , please let me know.

Thank you 

This looks exactly like  bug 648117 , neither of which repro after https://codereview.chromium.org/2702433002.

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