iframe sandbox attribute allows evasion of extension

[semenko]

Minimalist PoC: https://cgs.wustl.edu/~semenko/phishing.html

Master frame: <iframe src="phishing-input.html" sandbox="allow-forms">

Input frame: <input type="password">

Note the console during input:

2015-05-12 17:21:07.698 phishing-input.html:1 Blocked script execution in 'https://cgs.wustl.edu/~semenko/phishing-input.html' because the document's frame is sandboxed and the 'allow-scripts' permission is not set.
2015-05-12 17:21:07.794 phishing-input.html:1 Blocked script execution in 'https://cgs.wustl.edu/~semenko/phishing-input.html' because the document's frame is sandboxed and the 'allow-scripts' permission is not set.
2015-05-12 17:21:07.874 phishing-input.html:1 Blocked script execution in 'https://cgs.wustl.edu/~semenko/phishing-input.html' because the document's frame is sandboxed and the 'allow-scripts' permission is not set.

• credit, via these threads: https://twitter.com/Paul_Reviews/with_replies

[taravancil]

Interesting! I hadn't thought of this. Unless the attacker explicitly sets sandbox="allow-scripts" (why would she?), then I think this one holds up.

Is it possible to listen for events within a sandboxed iframe if the attacker hasn't allowed scripts?

[adhintz]

How about using https://developer.chrome.com/extensions/webRequest to look for the password in the post data? Password Alert would be able to see each HTTP request, and if it sees the password in the form data, it could alert.

The phishing page in sandbox="allow-forms" cannot run JavaScript. Without JavaScript I can't think of a way that the phishing page could obfuscate form data being submitted, such as the password phishing page.

[semenko]

I don't see an easier way OTOH, but that feels hackish (and maybe fragile with weird form encodings, UTF-7 prefilled characters, or some similar edge).

I think it also might trigger false positives (e.g. data) unless there's a smart way to listen to a subset of posts.

Is this actually intended by the sandbox attribute? (I wasn't aware the DOM could block client scripts.) Can that also happen with CSP (maybe allowing only a malicious source) or SRI tricks?

[taravancil]

Nice. I wasn't aware of chrome.webRequest, but it seems like that should work if there really is no way for the phishing page to obfuscate the password.

[semenko]

FWIW, CSP doesn't disable content_scripts: https://cgs.wustl.edu/~semenko/csp.php

[semenko]

Ooof, I played around with allow-top-navigation and target="_parent" and other tricks before realizing that ... with same-origin iframes, this isn't solvable -- you can just call document.getElementById('your-iframe-name').contentDocument. (You might need to set sandbox="allow-same-origin", but the raw iframe contents are accessible)

Example: https://cgs.wustl.edu/~semenko/same-origin.html

Solutions: an input API (like chrome.input.ime that's not restricted to Chrome OS) or an override for content_scripts to inject into script-disabled iframes.

[semenko]

Looking a bit further, this does look like a chrome bug, with isolated world content-scripts intended to run inside a sandbox:

See @mikewest's comment https://code.google.com/p/chromium/issues/detail?id=472101#c6

Source: https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/bindings/core/v8/ScriptController.cpp&l=453

[mikewest]

I do think it's a Chrome bug, but it hasn't been on anyone's priority list.

Using WebRequest is an option, I suppose, but it's a pretty big hammer. And, as @semenko notes, allow-same-origin sandboxed frames don't actually need to submit anything via a form.