Trevor Jim wrote: > A problem with our proposal is that it relies on scripting being > turned on, and if scripting is not turned on you don't see the untrusted > content at all --- even though with scripting turned off it should be > safe. You can have a separate <noscript>, but that means the content > has to be included twice. Also, I would worry then that the untrusted > content could close the <noscript> --- a danger for when scripting is > turned on.
You can use the scripting DOM to get data out of the <noscript> and put it in the sandbox - but it seems that doing innerHTML on a <noscript> gives you the data back HTML-escaped! So you'd need to unescape it. > To be foolproof, the <jail> proposal does need to scan the untrusted > content to ensure that the "hash" is not in the content, this is slightly > more involved than the HTML/JavaScript escaping our proposal requires. I don't think so - the idea is that the attacker can't know the "hash" parameter. > (BTW I think "hash" is a misleading word to use here, unless I am > misunderstanding the details of Brendan's suggestion.) You are right - but it's what he used in his slide. Gerv _______________________________________________ dev-security mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security
