[whatwg] The problem of duplicate ID as a security issue

[Mihai Sucan]

Le Fri, 10 Mar 2006 08:45:29 +0200, Alexey Feldgendler  
<alexey at feldgendler.ru> a écrit:

<...>
> Another solution may be to define functions like getElementById(),  
> getElementsByTagName() etc so that they don't cross sandbox boundaries  
> during their recursive search, at least by default. (If the sandbox  
> proposal makes it to the spec, of course.)
>
> Ideas are welcome.

This is something I'd opt for. But ... this would be really bad, since the  
spec would have to change the way getElementBy* functions work. It's bad  
because you shouldn't make a spec that breaks other specs you rely upon  
(this has probably already been done in this very spec).

Therefore, I'd say this security issue should be left to be taken care of  
by web application authors themselves. It's impossible for specs to force  
authors to make secured apps.

Why do so? Authors already have to take care of not allowing some tags and  
other tricks in the book (for example <meta refresh>). If the author  
allows users to supply *any* tag (even the innocent <strong>), then they  
already expose their app to potential security holes. Malicious users can  
insert IDs not only for abusing a specific security hole, but only for the  
fun of breaking the page. They can also use class= and style= attributes  
for the sole purpose of (badly) breaking the layout of the targeted page.

The spec can't do much in these situations. Shall the spec provide a way  
for CSS files to *not* be applied in <sandbox>ed content?

Generally authors just don't allows users to input HTML code at all (I  
myself do that). It's the safest way and the easiest way.

If allowing some tags is a requirement for some app, then the author  
already has to take care which tags s/he allows and which attributes.  
Nothing special. If s/he doesn't think of removing some attributes or  
checking for allowed values, then ... it's not the spec to be blamed for  
the security issue.

As Mikko said "allowing random user input with possibility to use user  
supplied scripting is next to impossible to make secure".


-- 
http://www.robodesign.ro
ROBO Design - We bring you the future