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

Wed Mar 15 05:26:03 PST 2006

Le Wed, 15 Mar 2006 07:52:28 +0200, Alexey Feldgendler  
<alexey at feldgendler.ru> a écrit:

<...>
> Sandboxes are quite special things, so we'll need a DOMSandbox anyway.  
> But instead of adding things like getElementById() to the DOMSandbox  
> interface, I tend to make the "fake document" which is visible from  
> inside the sandbox a member of the sandbox itself. The call will look  
> like sandbox.document.getElementById().

As Ric said, having <sandbox>es treated "too similar" to a document is  
overkill.

<...>
>> Again, good point, but this is not entirely related to "duplicate ID as  
>> a security issue". Meaning, you are advocating for the <sandbox>  
>> element. That's something I also do, depending the way it's going to be  
>> defined (of course).
>
> Yes, really. I've actually gave the wrong subject to the thread. It  
> should have been titled "Sandboxing can make contained HTML harmless in  
> more ways than just isolating scripts".

True.

>> The <sandbox> element would make securing a web application from common  
>> security holes and other pitfalls much easier and elegant. Of course,  
>> it would also solve the duplicate IDs issue.
>
> Actually, now it seems the only solution to me because, as you say  
> below, the behavior on duplicate IDs cannot be changed to a safe way  
> without breaking backwaard compatibility.

That's what I was also thinking, after I wrote the email. You can't really  
do much about duplicate IDs.

>>> Returning to the duplicate IDs, I think we should define some standard  
>>> behavior for getElementById() when there is more than one element with  
>>> the given ID. To lower the possible extent of duplicate ID attacks, I  
>>> propose that getElementById() should throw an exception in that case.  
>>> It's better to crash the script than to make it do what the attacker  
>>> wants.
>
>> Bad idea. [...]
>>
>> Point is, web applications currently do rely on duplicate IDs support.  
>> Throwing errors (thus breaking scripts) also badly breaks backwards  
>> compatibility. That web application is not the only one having such  
>> badly coded backend, it's one of many (look at most corporate web sites  
>> done in "a snap" by "gurus").
>
> Well, if browsers did throw exceptions on duplicate IDs, there wouldn't  
> be any duplicate IDs in existing applications. The problem is that there  
> are already such applications.
>
> (A wild thought: maybe enforce ID uniqueness only for <!DOCTYPE html>?)

I always advocate for maximum possible strictness in "standards compliance  
mode" rendering. UAs should break all "standards compliant" pages with  
very big and fat warnings "error!!!". But ... sadly, as I see it, the line  
between quirks mode and standards mode is blurring. I would love if major  
UAs (mainly Opera and Firefox) would provide a way to be *extremely*  
strict.

I think enforcing ID uniqueness in standards mode would be good, but that  
would still probably break (very?) few pages. Those web authors should  
have to "live with it", because they want standards-compliant sites.

Side note and wild guess: We are probably forgeting that the beauty of the  
web is actually allowing everyone to contribute, be it bad code or better  
code. Wanting something *that* strict is like disproving one of the  
essential concepts contributing to the success of the web.

<...>
> Someone could post a JavaScript game in his blog, a horoscope calculator  
> etc.
>
> And, by the way, blog entries aren't the only place where sandboxing can  
> be appliied in blogs. For example, LiveJournal allows user-defined  
> journal styles which are written by the users in a self-invented  
> programming language which outputs HTML. That HTML goes through the HTML  
> cleaner afterwards, of course. Manny people would love to add dynamic  
> menus, AJAX comments folding etc to their styles. This could be partly  
> solved with a set of predefined "toys", but actually the entire  
> LiveJournal styling system is about user-initiated development. Those  
> with programming skills write new styles, and other users may take and  
> use them.

I did not see LiveJournal, so I don't know what kind of features they  
offer.

<sandbox> would probably do "the trick" (would help a lot with security in  
this case also).

I have some doubts about how <sandbox> would turn out when used by masses.

Take HTML, for example, it's a markup language greatly appreciated by many  
and despised by others. Even you said in one reply to this thread "today's  
HTML sucks" - advocating for the need of allowing user-scripts in pages,  
for having table sorting, popup menus, etc. A few minutes later in another  
reply you say "we already have a great markup language, which is HTML" -  
advocating for allowing users to write HTML, instead of custom markup.

So, <sandbox> may be designed to help tighting-up security on the web, but  
we should also try to think of how's it actually in usage, side-effects,  
etc. It definitely solves problems, but will it cause other problems? How  
important are they?

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