Gervase Markham wrote:
>
> Note to readers: Brendan proposed
> <jail hash="34af56...">
> -- untrusted content here --
> </jail hash="34af56...">
Just to be complete, here's what we proposed:
<div class='noexecute' id='foo'></div>
<script>
document.getElementById('foo').innerHTML = "quoted untrusted content";
</script>
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.
On the other hand, our proposal works with current browsers and was
sufficient to demonstrate the issue.
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.
For example, our kind of escaping can be done per-character, you don't
need to see the whole string to escape.
(BTW I think "hash" is a misleading word to use here, unless I am
misunderstanding the details of Brendan's suggestion.)
I would also like to see a full description of <jail>, I think there are
plenty of ways it could go wrong.
At any rate, the idea of a jail/sandbox is the important thing and these
details are not important to our proposal, as long as a jail/sandbox is
available. This is just one of many policies we are interested in
supporting.
> But making it impossible to set it twice adds defence in depth with very
> little downside.
I'm not against it; however it was easier for us not to do it, and I still
don't think it adds much.
> But do you actually have any way to
> make this happen in IE at all? If not, then they'll have to implement it
> themselves, and can do whatever syntax we pick.
I'm totally open to other syntax; but why not make it easy for them to do
something compatible, and save web app developers some trouble? At any
rate, I don't want to get into standards wars.
-Trevor
_______________________________________________
dev-security mailing list
dev-security@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security
