Trevor Jim wrote: > > 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.
As Brendan points out, you can't rely on web server applications to correctly parse HTML at this point. Libraries like html5lib might make this more practical in the future. > 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. Fortunately, it seems pretty easy for library authors to do it right. A hash function run over the current time, some random salt, and the dangerous content itself should make it very difficult for an attacker to prematurely close that jail element. But that's just one idea--servers can make the security vs. cost trade-off for themselves. Brendan Eich wrote: > This is like giving whiskey and car keys to teenagers. Yes. Additionally, the fixed-whitelist jail element doesn't preclude adding other approaches later. Trevor Jim wrote: > I think the current situation with script injection is very > dangerous, and our scheme would be a big win for this. Scripts are just one example of dangerous content. > > It seems to me that our scheme, even with the chance of an error in a > policy script, has a vastly greater upside than downside. If implemented perfectly, by all browsers. It's much more complicated than than the jail element, and therefore much less likely to interoperate. Standards are tough like that. > Programmability reduces the chances that further changes will be needed. There's a small chance it would increase variety in web applications, but I doubt it would reduce the likelihood of further changes in the browser, which is probably close to 100%. I do agree that <jail> is an inflexible sledgehammer. However, it's not clear to me that an immediate jump to programmable sanitization on the client would have any near term impact. - Rob _______________________________________________ dev-security mailing list [EMAIL PROTECTED] https://lists.mozilla.org/listinfo/dev-security
