Trevor Jim wrote: > On Apr 10, 2007, at 6:15 AM, Gervase Markham wrote: > >>> 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. > > Yes, but it seems to me that you've got the untrusted content in your > hands and you can deterministically ensure that the "hash" does not > occur in it.
It's not that easy, due to entities, JavaScript that you may want to let run (but in a sandbox) that can document.write a generated close tag, e.g. > There may be schemes where it is perfectly sensible to > rely on randomness, but that can be tricky and the people who have to > generate this random number are web app developers and not necessarily > security experts -- it's something that is easy to do wrong. My sketch was just that: a slideware sketch. The idea is to put the onus of whitelisting or sandboxing (or taint-tracking information flow, etc.) on the browser implementors, who are fewer and more used to this level of threat and standardization than the myspace wannabes. That means something other than a conventional open tag. It could mean writing custom script and hurting page load performance, as in your work. Or it might mean some unguessable id. It won't come for free. /be _______________________________________________ dev-security mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security
