W3C home > Mailing lists > Public > public-webappsec@w3.org > March 2016

Re: iFrame access

From: Craig Francis <craig.francis@gmail.com>
Date: Mon, 21 Mar 2016 07:05:46 +0000
Cc: WebAppSec WG <public-webappsec@w3.org>
Message-Id: <C41D2D2B-3CAB-4182-9E13-8F794F0EF322@gmail.com>
To: Devdatta Akhawe <dev.akhawe@gmail.com>
> On 20 Mar 2016, at 21:22, Devdatta Akhawe <dev.akhawe@gmail.com> wrote:

> I think there would be significant push back against introducing another synchronous cross origin primitive. But, I am not a browser engineer. Any reason postmesaage doesn't work?




That is a fair point, from the browsers point of view this is quite complex.

But at the same time, many websites rely on Adverts, and they are often "context sensitive".

So do you have an alternative?

Websites will need to copy/paste something, and a single iframe would be my preferred choice (it clearly shows the boundary).

I like the idea of using postMessage, but I want the browser to provide something by default for every website.

Anything that requires extra JavaScript (that websites needs to include/write) will complicate this too much.

For reference, websites currently copy/paste a line of code to include some poorly written JavaScript (often not async), that gets full control of the current page. And it typically pulls in extra JavaScript that has been written (and is unchecked) by a forth-party company, so they can create the advert, and make it interactive (which we can only hope has good intentions, but often does not).

Craig




> On 20 Mar 2016, at 21:22, Devdatta Akhawe <dev.akhawe@gmail.com> wrote:
> 
> I think there would be significant push back against introducing another synchronous cross origin primitive. But, I am not a browser engineer. Any reason postmesaage doesn't work? Maybe we can try a d fix those limitations? You can always fake a parentTextContent variable backed by postmesaage and updated async. This also gives the app finer control.
> 
>> On Mar 20, 2016 5:08 PM, "Craig Francis" <craig.francis@gmail.com> wrote:
>> Hi,
>> 
>> As part of my never ending quest to banish untrusted third party content into iframes...
>> 
>> Would it be possible to introduce a new token to the `sandbox` attribute, so that it allows the iframed document (cross domain) to read the Text Content of the parent document?
>> 
>> Something like:
>> 
>> 	<iframe sandbox="allow-parent-text-content-read ..."></iframe>
>> 
>> This would allow Ad networks to put their unsafe/untrusted/messy JavaScript into a sandboxed iframe, and for them to have the very limited permission of being able to read the `.textContent` of the parent DOM - which is something they insist on for "contextual adverts".
>> 
>> We can then block the third party from having full read/write access to the whole page.
>> 
>> This will stop them seeing anything that isn't the text on the page (e.g. CSRF tokens, or values in input fields):
>> 
>> 	<form action="/profile" id="profile">
>> 		<label for="name">Name</label>
>> 		<input type="text" id="name" value="Craig" />
>> 		<input type="hidden" name="csrf" value="kr3aN1oY" />
>> 	</form>
>> 
>> 	<script>
>> 		console.log(document.getElementById('profile').textContent); // Output "Name"
>> 	</script>
>> 
>> Craig
>> 
>> 
>> 
>> https://www.w3.org/TR/2011/WD-html5-20110525/the-iframe-element.html#attr-iframe-sandbox
>> 
>> https://github.com/craigfrancis/security/tree/master/third-party-content
Received on Monday, 21 March 2016 07:06:16 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:18 UTC