Issue metadata
Sign in to add a comment
|
Iframe Spoofing via subframe navigation
Reported by
wadih.ma...@gmail.com,
Oct 3 2016
|
||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.116 Safari/537.36 Steps to reproduce the problem: 1- open http://localhost/run.html 2- click on the start button 3- wait till the print dialog appears and cancel it 4- the renderer process will be killed 5- if you go back from or refresh the crashed page, https://developer.mozilla.org/en-US/docs/Web/HTML/Element/iframe will open and its first iframe's content is replaced with https://www.wikipedia.org. What is the expected behavior? https://developer.mozilla.org/en-US/docs/Web/HTML/Element/iframe should load normally with its own iframes. What went wrong? By executing from the window.unload event "history.forward();print();" inside an iframe, it is possible to spoof the iframes of any web page. Did this work before? N/A Chrome version: 53.0.2785.116 Channel: n/a OS Version: 6.1 (Windows 7, Windows Server 2008 R2) Flash Version: Shockwave Flash 23.0 r0 Using the same technique it is also possible to replace iframes from a domain with other iframes contained in the same domain and without the crash in step 4.
,
Oct 4 2016
,
Oct 14 2016
Thanks for the report! I can repro this on 53.0.2785.143 but not on 56.0.2890.0. I suspect it's fixed in M54, which is now shipping to stable (54.0.2840.59)-- I'll try to confirm. The fix would be because we switched on the new subframe FrameNavigationEntry logic in M54 and no longer use HistoryController. (That also explains why the crash in step 4 is gone, because that was a NC_AUTO_SUBFRAME renderer kill from issue 613732, which no longer occurs in M54. Granted, the repro steps would have helped us track down and prevent more of these kills in M53 if we'd known them earlier in the M53 release cycle, but I think it's moot now.) Comment 1: Issue 597322 was rated medium because it had a URL spoof (with some mitigating factors) in addition to loading the wrong iframe. Loading the wrong iframe is certainly a bug, but I think it's much less severe from a security perspective. It's already possible to navigate a victim page's iframes to a URL of your choice if you load the victim page as an iframe on your own page, for example. Since we don't really cover changes to iframe URLs in the security severity guidelines, I'm reducing this to low severity.
,
Oct 14 2016
Confirmed-- this doesn't repro in 54.0.2840.59. I suspect it was fixed by r410150 from issue 236848 . (Feel free to post an update if there's a way to get it to still work, though!)
,
Oct 15 2016
,
Jan 21 2017
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 |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by kenrb@chromium.org
, Oct 3 2016Components: UI>Browser>Navigation
Labels: -Pri-2 Security_Severity-Medium Security_Impact-Stable Pri-1
Owner: creis@chromium.org
Status: Assigned (was: Unconfirmed)