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

Issue 681297 link

Starred by 1 user
Status: WontFix
Owner:
█ mkwst@chromium.org
Buried. Ping if important.
Closed: Jan 2017
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug-Security



Sign in to add a comment

Sandbox Bypass using iFrame via ctrl+click

Reported by mishra.d...@gmail.com, Jan 14 2017 
UserAgent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:50.0) Gecko/20100101 Firefox/50.0

Steps to reproduce the problem:
Reproduce :

1. Open http://hackies.in/iframe.html 
2. Ctrl+click the link inside iframe sandbox

Works for all OS and Versions attached video poc for reference. 

What is the expected behavior?
Link in sand-box iframe should not open new tab unless allow-pop ups is specified. Further more, opened tab should not execute script unless original sandbox has allow-scripts.

What went wrong?
Script Executes on the tab which is open.

Did this work before? N/A 

Chrome version: 56.0.2924.59 (Official Build) beta (64-bit)  Channel: n/a
OS Version: 
Flash Version: Shockwave Flash 24.0 r0
Chrome_Beta.mp4
310 KB View Download

Comment 1 by mbarbe...@chromium.org, Jan 17 2017

Components: Blink>SecurityFeature Blink>HTML>IFrame
Labels: -OS-Linux Security_Severity-Low Security_Impact-Stable OS-All
Owner: mkwst@chromium.org
Status: Assigned (was: Unconfirmed)
I'm not totally sure what the expected behavior here is, but I believe this is working as intended. Either way, I'm not too worried about it from a security standpoint.

mkwst: Could you take a look? I've applied labels in case this is something we'd want to fix, but feel free to close it out if it's expected.

Comment 2 by mkwst@chromium.org, Jan 17 2017 

We generally allow users to do things that we wouldn't allow the page to do itself. If the user intentionally ctrl-clicks (or right clicks and chooses an option from the context menu), I don't think there's a good reason to ignore it.

This also seems to be the behavior that Firefox, Safari, and Edge have landed upon, and seems consistent with the spec (https://html.spec.whatwg.org/#the-rules-for-choosing-a-browsing-context-given-a-browsing-context-name): the page can't pop up a window, but the user can do so.

Comment 3 by aarya@google.com, Jan 17 2017

Status: WontFix (was: Assigned)
Closing based on c#2.
Project Member

Comment 4 by sheriffbot@chromium.org, Apr 26 2017

Labels: -Restrict-View-SecurityTeam allpublic
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