Re: E4H and constructing DOMs

* Ian Hickson wrote:
>Autoescaping mechanisms are a disaster. Simple changes to the source code 
>that look like no-ops end up introducing security vulnerabilities or 
>breaking the logic because suddenly the autoescaper has different context. 
>Authors end up not thinking about exactly what it is they're doing, 
>leading to overconfidence and injection vulnerabilities where the 
>autoescaper has no idea what's going on. Backwards-compatibility means 
>that mistakes in the first release of the autoescaper can't be fixed 
>without opt-in, which leads to a series of "yes I really want this to be 
>secure" boilerplate after a few revisions. It's just way safer to be 
>explicit and have a simple model.

I think this is a slight mischaracterization. Auto-escaping mechanisms
can be very useful to catch errors, possibly at the expense of functio-
nality; they just aren't something to rely on, and they can easily get
in the way. For instance, an auto-escaping mechanism might decide to
treat <a href='... something that expands to "javascript:..." ...'> as
something unintended and neuter the 'javascript:' string in some way.
If you have an organizational policy not to use "javascript:" links,
along with discipline, that can reduce the attack surface considerably.

Not quite an auto-escaping mechanism, as I would understand the term,
but a web forum I used made it pretty much impossible for people to use
the words "script" and "style", always replacing part of those strings.
That is fairly crude and disabling, but also fairly effective compared
to only relying on developers to get their escape function calls right.
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

Received on Tuesday, 12 March 2013 02:51:22 UTC