Closed Bug 1037381 Opened 10 years ago Closed 10 years ago

A link within an iframe that opens a new window applies the sandbox restrictions of the iframe to the new window

Categories

(Core :: Security, defect)

30 Branch
x86_64
Linux
defect
Not set
normal

Tracking

()

RESOLVED INVALID

People

(Reporter: rhys.davis, Unassigned)

References

Details

Attachments

(1 file)

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.153 Safari/537.36

Steps to reproduce:

Click on a new window link that is within an iframe with the sandbox attribute that will allow pop ups but not allow scripts to be executed. (Click on the link in the attached iframePage.html)


Actual results:

The link is opened in a new window and the restrictions of the sandbox are still in place meaning no Javascript is loaded.
(Using the attached files "No Javascript" is displayed)


Expected results:

From what I can gather from the HTML specification I would expect the new browsing context to not be subjected to the restrictions of the sandbox. So I would expect any Javascript in the new window to be loaded.
(Using the attached files "Hello Javascript" is displayed")
Component: Untriaged → Security
Product: Firefox → Core
Looking at the spec, when a target="_blank" link is clicked we land in the algorithm at http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#following-hyperlinks-2

In step 3, we look for the right browsing context (in this case a new one) and end up in http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#the-rules-for-choosing-a-browsing-context-given-a-browsing-context-name 

If you read to the end of that section, it says:

  If the current browsing context's active document's active sandboxing flag set has the
  sandboxed navigation browsing context flag set and the chosen browsing context picked
  above, if any, is a new browsing context (whether top-level or auxiliary), then all 
  the flags that are set in the current browsing context's active document's active
  sandboxing flag set when the new browsing context is created must be set in the new
  browsing context's popup sandboxing flag set, and the current browsing context must
  be set as the new browsing context's one permitted sandboxed navigator.

In the attached testcase, the "sandboxed navigation browsing context flag" is in fact set, because it's always set on sandboxed iframes.

In other words, any popup opened from inside a sandbox is sandboxed with the same sandbox flags.

If you think about it, you really have to do it that way.  Otherwise the sandboxed document could just do:

  <a href="." target="_blank">Click me</a>

and escape the sandbox.
Status: UNCONFIRMED → RESOLVED
Closed: 10 years ago
Resolution: --- → INVALID
I filed https://code.google.com/p/chromium/issues/detail?id=393401 on Chrome and https://bugs.webkit.org/show_bug.cgi?id=134850 on Safari.  I also tested IE11, and they get this right.
What about Ctrl+Click (or middle click), Shift+Click ?

IE1 disallow JS, but Firefox allows JS.
Flags: needinfo?(bzbarsky)
> What about Ctrl+Click (or middle click), Shift+Click ?

The spec has nothing to say about the behavior of those, but arguably we should be propagating the sandbox flags in those cases, yes.  Worth filing a bug on that on the Firefox UI, which is where those are implemented.
Flags: needinfo?(bzbarsky)
(In reply to Boris Zbarsky [:bz] from comment #4)
> > What about Ctrl+Click (or middle click), Shift+Click ?
> 
> The spec has nothing to say about the behavior of those, but arguably we
> should be propagating the sandbox flags in those cases, yes.  Worth filing a
> bug on that on the Firefox UI, which is where those are implemented.

Filed Bug 1037766
Thank you!
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: