Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.
Sign upShould "familiar with" use same origin or same origin-domain? #3747
Comments
This comment has been minimized.
This comment has been minimized.
Or don't do a security check at all. Or do something completely unrelated to the spec. All I can tell from my investigation to the extent I did it is that they don't do the thing the spec says, whatever they do. |
This comment has been minimized.
This comment has been minimized.
|
For example, the testcase in https://bugzilla.mozilla.org/show_bug.cgi?id=1459671 would "pass" if you can target a frame if you're same origin-domain with its parent; that's the check in the fourth bullet of "familiar with". So it could also be that the non-Firefox browsers do "same origin" in the first bullet and "same origin-domain" in the fourth bullet. More tests needed to tell what they actually do. |
This comment has been minimized.
This comment has been minimized.
|
I'm the original reporter of the issue. Indeed, as per current spec, it seems that Firefox is the only browser strictly following the algorithm. However, I am still trying to find a "bad" scenario when "same origin-domain" check would lead to a security flaw. It seems to me, that the fourth bullet in "familiar with" intended to restrict access from a browsing context A to a browsing context B, which is located under a different top-level context. For example, if you open https://x.zok.pw/ff_frame_target/two-roots/victim-root.html and https://y.zok.pw/ff_frame_target/two-roots/evil-root.html in separate browser tabs, the form in evil-root will not be able to navigate the frame inside victim-root. In the case of https://x.zok.pw/ff_frame_target/index.html however, I see no additional security benefit in "same origin" over "same origin-domain". Both siblings and root contexts set their One thing that is tricky with "same origin", it that one frame cannot simply set form target to the sibling frame. But having full access to the sibling's DOM, it's possible to craft that request by other means. However, the current spec explicitly states "same origin", so I assume there's some edge case I'm missing here. Looking forward to hearing the reasoning from @whatwg/security. |
This comment has been minimized.
This comment has been minimized.
|
The basic premise in the spec is that document.domain is deprecated and aiming to be removed, and that therefore as much as possible should ignore it... |
This comment has been minimized.
This comment has been minimized.
|
I'm all for removing |
This comment has been minimized.
This comment has been minimized.
|
This is basically a subset of the algorithm/problem outlined in #313 (comment). |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
@zetafunction pointed me to https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/page/frame_tree.cc?rcl=db540489f9a4864385c80e3968c175cd6e335266&l=228 . It looks like the relevant bits are in
i.e. it seems to be concerned with same-origin-domain, not same-origin. |
This comment has been minimized.
This comment has been minimized.
|
Thanks @domenic! |
https://bugzilla.mozilla.org/show_bug.cgi?id=1459671 was filed against Firefox because it uses a same origin check. Per investigation from @bzbarsky it appears that other browsers use same origin-domain. This means that you can target a cross-origin
<iframe>'s name if you are same origin-domain with it.It seems better if this concept does not depend on
document.domain.@whatwg/security interested in fixing this in your respective implementations?
Either way, we should probably also add a test for this as I don't think it's covered.