The results for the cross-origin case of Frames

[lwyeluo]

Hi,

I am very interested in your work in "Same-Origin Policy: Evaluation in Modern Browsers". The results in this paper are helpful for me to understand the current SOP in browsers.

When looking for the <iframe> without sandbox attribute in the cross-origin case, I found that the permission result from HD to ED is <no, no, yes>, but in the other direction is <partial, partial, n.a>. I am confused with this difference:

• I saw your test script in your-sop.com, the partial means that we can access the window.top.frames.length. But according to my understanding, the HD can also access ED by <ED's window object>.frames.length. Does it mean that permission result from HD to ED should be <partial, partial, yes>?
• In my mind, the DOM tree always refers to the window.document object. I test it in chrome, it seems that this object cannot be accessed in both direction. So is frames.length a part of the SOP-DOM?

Looking forward to your reply. Thank you.

[CheariX]

Hi,

I totally agree to you first point. We simply missed the partial test case for the case ED->HD in this direction and must add it. So, ED->HD (partial,partial,..) should be right. Thank you!

Regarding you second point: it is difficult to answer. From our point of view, the DOM is whatever is accessible from the windowobject. Because window == document.defaultView, you can easily walk from documentto windowand thus accesss window.frames.length

[CheariX]

With 18ab13d, the partial read should be fixed.
However, partial write is more complex.
For ED->HD, the framework uses a location-hash write test on HD + onhashchange event.
A similar approach should be applicable for HD->ED except for the case, where the sandbox prevents script execution in ED.

This means: although partial write (HD->ED) is possible on the location, we cannot report it back to the main window.

Maybe someone has a better idea how to deal with this?