Le Wed, 15 Mar 2006 07:52:28 +0200, Alexey Feldgendler
[EMAIL PROTECTED] 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 sandboxes 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
