Sandbox data can be stolen by third-party frames about jailed

[spielzeugland]

@adob I tried your sample and it works. Can you explain why it is working? I am wondering why it is possible at all that a "bad" parent frame can manipulate the content of child frame coming from a different origin. Is that because of the Access-Control-Allow-Origin: * header on the iFrame's content?

[Venryx]

I'm not sure, but I think @spielzeugland's guess above is correct, that the only reason this exploit works is that the access-control-allow-origin header is set to * on both the jailed demo page main html document, as well as the frame within that demo page.

Access header for demo page itself: (seen in dev-tools, after directly opening: https://asvd.github.io/jailed/demos/web/console)

Access header for the frame within that demo page:

Thus, I believe this exploit is not usable in the wild, since normal websites do not have the access-control-allow-origin header set to *.

(Though correct me if wrong, of course.)

[asvd]

Thanks for the point!

The sandbox itself seems to remain secure, i.e. the "untrusted code" (in this case, entered by a user into the console) still cannot affect the main application and reach its data. Right?

Securing the messaging between application and plugin has never been the point of Jailed, though you are right that this concern is a good thing to improve.

[adob]

From the developer's perspective, the issue is that it is not safe to pass user data to the sandbox because it may be intercepted by a third party. Suppose the application evaluates some JS and that data contains information about the currently logged in user. This vulnerability would allow an attacker to capture that information, hence creating a info leak vulnerability in that application. It's not as serious as full sandbox bypass, but still serious.

…

On Jun 26, 2017 5:04 PM, "asvd" ***@***.***> wrote: Thanks for the point! The sandbox itself seems to remain secure, i.e. the "untrusted code" (in this case, entered by a user into the console) still cannot affect the main application and reach its data. Right? Securing the messaging between application and plugin has never been the point of Jailed, though you are right that this concern is a good thing to improve. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#43 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAlEfn22FgDI1UowImZcKqnoJ4ILoib1ks5sIEcmgaJpZM4OF9y1> .

[asvd]

Sure, you are right. Therefore the issue remains open until fixed.

[justinwiley]

@adob @asvd Can you elaborate on the exact vulnerability here?

Is this attack only possible if the jailed page is run from within another malicious iframe? Would a X-Frame-Options: SAMEORIGIN header prevent this?

[adob]

The vulnerability would be information disclosure. If you use this sandbox on your site and send non-public data to it, you would have a information disclosure vulnerability on your site because the data could be captured by a third party. The X-Frame-Options setting is not sufficient. The attacker can use window.open() to open the page in new window, thereby bypassing the framing restriction. The attacker might need the user to click something on their page to bypass the pop-up blocker, so that is an added roadblock but not a big one.

…

On Aug 10, 2017 8:34 AM, "Justin Tyler Wiley" ***@***.***> wrote: @adob <https://github.com/adob> @asvd <https://github.com/asvd> Can you elaborate on the exact vulnerability here? Is this attack only possible if the jailed page is run from within another malicious iframe? Would a X-Frame-Options: SAMEORIGIN header prevent this? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#43 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAlEftGf7uKEW_HAK-OqeWvzgI0T7Gsvks5sWyLtgaJpZM4OF9y1> .

[subversivo58]

Would not the correct use of CSP solve the presented problem?