-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Navigation "exceptions-enabled" flag obsolete? #4640
Comments
I think this very much depends on how #313 is resolved and it's hard to say before that is done. |
Allowed to navigate is almost entirely about sandboxing. Maybe it was about something else at the time this issue was raised? You can have pages which same-origin and sandbox using allow-same-origin, while not allowed to navigate each other (because they don't have allow-top-navigation or similar). So this flag is not obsolete; it's necessary for such cases. |
It's not entirely about sandboxing. It's about whether you get to navigate a browsing context you can get a handle to, e.g., with named targeting. |
Hmm, how so? Every step of "allowed to navigate" that returns false does so because of a sandbox flag. (Apologies if I'm missing something obvious or my eyes are just skipping over some crucial clause...) |
Good point. I was thinking about "familiar with". And although that's not currently involved specification-wise, I vaguely recall it is in practice. Anyway, #313 will hopefully one day sort that out. |
Navigation currently comes with a exceptions-enabled flag, which is set in navigations originating in
window.open
orlocation
only, and only used as part of checking allowed-to-navigate and re-throwing the exception in the above two cases.Note that
location
also throws an exception when its various attributes are accessed is a non same-origin scenario(which seems stricter, or at least equal to, the check performed inallowed-to-navigate
).In the test suite, I could only find tests for insecure access to
open
attribute access of a window at https://github.com/servo/servo/blob/master/tests/wpt/web-platform-tests/html/browsers/the-window-object/security-window/window-security.https.htmlSo I'm wondering, is there a case where an access to either
window.open
or an attribute ofwindow.location
would be "secure", yetallowed-to-navigate
would be false and an exception would have to be thrown in the navigation? In other words, is the exception not in fact always thrown when the attribute is accessed, versus during actual navigation?Would it not make more sense to have
open
throw a security error when accessed across origins?Firefox and Chrome both throw security errors when accessing
open
, without the need to actual call the method and attempt a navigation.Therefore, I'm wondering if the
exceptions-enabled
flag is not perhaps obsolete, since:window.open
, not during navigation.Perhaps a script could indeed get past the checks on attribute access, if that script were running in a same origin iframe, and then you'd get a negative "is allowed to navigate" answer in the navigation, due to the iframe not being ancestor of it's parent, and neither being a top-level?
The text was updated successfully, but these errors were encountered: