W3C home > Mailing lists > Public > public-script-coord@w3.org > January to March 2013

Re: E4H and constructing DOMs

From: Mike Samuel <mikesamuel@gmail.com>
Date: Tue, 12 Mar 2013 10:53:27 -0400
Message-ID: <CACod6GvueS+mpukV0BVMrHHpZodDGOX4x8vVqWa5EFusu-D5tQ@mail.gmail.com>
To: Bjoern Hoehrmann <derhoermi@gmx.net>
Cc: Ian Hickson <ian@hixie.ch>, "public-script-coord@w3.org" <public-script-coord@w3.org>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:08 UTC