search

asvd / jailed

execute untrusted code with custom permissions
MIT License
1.01k stars 69 forks source link

Sandbox data can be stolen by third-party frames #43

Open adob opened 7 years ago

adob commented 7 years ago

The sandbox iframe can be navigated to an attacker-controlled URL by another, malicious frame. If the sandbox is sent any user data, it can be captured this way.

PoC: https://jsfiddle.net/urv6tx44/2/

asvd commented 7 years ago

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 commented 7 years ago

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" notifications@github.com 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 https://github.com/asvd/jailed/issues/43#issuecomment-311215168, or mute the thread https://github.com/notifications/unsubscribe-auth/AAlEfn22FgDI1UowImZcKqnoJ4ILoib1ks5sIEcmgaJpZM4OF9y1 .

asvd commented 7 years ago

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

justinwiley commented 7 years ago

@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 commented 7 years ago

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" notifications@github.com 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 https://github.com/asvd/jailed/issues/43#issuecomment-321587888, or mute the thread https://github.com/notifications/unsubscribe-auth/AAlEftGf7uKEW_HAK-OqeWvzgI0T7Gsvks5sWyLtgaJpZM4OF9y1 .

subversivo58 commented 6 years ago

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

spielzeugland commented 6 years ago

@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 commented 4 years ago

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.)