[whatwg] The problem of duplicate ID as a security issue
mihai.sucan at gmail.com
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
>> 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".
>> 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
>> 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*
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.
> 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
<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?
ROBO Design - We bring you the future
More information about the whatwg