[whatwg] Script origin tracking
Alexey Feldgendler
alexey at feldgendler.ru
Thu Feb 9 09:07:04 PST 2006
On Thu, 09 Feb 2006 18:16:22 +0600, Hallvord Reiar Michaelsen Steen
<hallvord at hallvord.com> wrote:
>>> there is some discussion surrounding cookies and security - see this
>>> bug: http://bugzilla.opendarwin.org/show_bug.cgi?id=6797
>> Just blocking access to cookies of another frame isn't enough. Consider
>> the following example:
>>
>> otherframe.document.body.addEventListener('unload', function() {
>> thisframe.variable = otherframe.document.cookie;
>> }, false);
> You are perfectly right, of course. That probably means this problem
> can't be solved. Seems there is no way to retro-fit security here
> without breaking existing content.
What you say can be implemented, though, and it has the same underlying
requirement as the sandboxing approach that I wrote about before:
origin-tracking of every piece of script code. Here are the rules.
1. Every piece of compiled script code has a so-called origin descriptor
attached to it. An origin descriptor points to the window/frame where the
script comes from, and contains information like the security domain,
sandbox restrictions etc. A piece of code gets a descriptor when it's
parsed and compiled.
2. What some piece of code can do and what it cannot do is determined by
its origin descriptor, not by the origin descriptor of the caller, no
matter how the code got called (a regular function call, an event handler,
javascript: link activated etc).
3. All code contained in an embedded or external script introduced by a
<script> element, contained in the onXXX attrubytes, or found in
javascript: URIs in href, src, and similar attributes AT PARSE TIME gets
the origin decriptor appropriate to its location. Code found in
stylesheets at parse time (like javascript: URIs as background-image
values), if compilation of such code cannot be completely avoided, also
gets the origin descriptor appropriate to its location.
4. Anonymous functions (lambda functions) inherit the origin descriptor of
the code that creates them. The same applies to code passed to eval().
5. Code added as <script> elements, assigned to onXXX, href, src (as
javscript: URIs) attributes, or introduced into the document by calling
document.write() by a script inherits that script's origin descriptor.
6. Code typed as javascript: URI into the address bar or activated as a
bookmark gets the "user input" origin descriptor. What capabilities does
it actually mean is a topic for another discussion.
This is a substantial change to how the user agent represents the data
internally. Not only does it require the UA to associate an origin
descriptor with each piece of compiled code, but also to bind a security
descriptor to every unparsed attribute like onXXX, href, and src, stored
in DOM. The latter is important. I don't exactly know how each browser
stores these attributes inside, but I'm afraid that many of them don't try
to parse the code in, say, onclick attribute, at the time it's stored in
DOM, but rather do it later when the event is fired.
However, this approach doesn't require attributed strings: only compiled
scripts and some DOM attribute nodes bear origin descriptors. For example,
this code doesn't copy the origin descriptor from onclick of element B to
onclick of element A:
A.onclick = B.onclick;
Instead, A.onclick gets the origin descriptor of the code which contains
this statement.
This way, both sandboxing and cookie protection could be implemented.
Because Gecko is the only popular open-source UA engine, I've had a look
at its code. Actually, Gecko's JS interpreter is already capable of
keeping security information associated with compiled code, and all what's
needed is to change the structure and propagation policy of that
information. The DOM code is also almost ready for origin tracking: event
handlers are stored in the event listener manager even when unparsed, so
an origin descriptor can be stored along with them. The javascript: URIs
require some more work, but it's definitely possible.
So, my conclusion is that it's possible to implement the described origin
tracking in Mozilla. It's interesting to hear the opinion of Opera
developers about the possibility of origin tracking in Opera's scripting
engine.
--
Opera M2 8.5 on Debian Linux 2.6.12-1-k7
* Origin: X-Man's Station [ICQ: 115226275] <alexey at feldgendler.ru>
More information about the whatwg
mailing list