Re: E4H and constructing DOMs

2013/3/11 Bjoern Hoehrmann <derhoermi@gmx.net>:
> * 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.

I agree that this is a mischaracterization, but  we're not debating
auto-escaping on this list, because no-one is proposing standardizing
any auto-escaping mechanism.

We're debating E4H (which does not protect against XSS), E4H-esque
approaches (which may protect against non-persistent-DOM-based-XSS),
and string templates (which make it easier to deploy auto-escapers
which do protect against code-injection as well as heavy-handed
filters like the one you describe).

Received on Tuesday, 12 March 2013 14:53:55 UTC