> We have discovered and fixed several flaws in the implementation described in
> the paper above. But the example above is not a flaw in the method
> per se, but an example of a bad policy. In general we cannot prevent the user
> from writing bad security policies, but we can make it easier, and
> this is one of the things we will present in he paper at OWASP AppSec'10.
No one can write a good policy based upon blacklisting
*, no one ever will because
no-one knows all attack angles. It can only reduce, not stop. But the flipside
of reducing something, might increase or enable another attack that relies on the
same attack one stops. That's why it's a black-box, you never know how systems
will interact.
*Simplified policy example, but based upon blacklisting because of setting a watch on a limited set of properties.
document.watch('location', locationPolicy);
window.watch('location', locationPolicy);
> The developer should be able to write any policy.
Assuming the developer knows it all, which he won't, he even might enable policy
rule number x, and number z, and thereby influencing policy number y. which might
lead to a whole other compromise. You just don't know how an attack will emerge.
I think that a developer who even takes notice of this library, should spend his
time fixing/preventing holes instead of layering unknown attacks and attack mitigation layers.
A recent example;
MSIE XSS filter bypass is a good example of how trust in your own policy rules
WILL be broken, and even turned against itself. Google was vulnerable for setting
a header flag enabling the MSIE XSS Filter, and got pwned through it, despite
M$'s extensive testing, they've made a mistake in only a handful of Regexp-rules.
EDIT indentation fix, stupid board. j/k
.
Edited 7 time(s). Last edit at 04/29/2010 06:24PM by Skyphire.