[whatwg] Script origin tracking

[Alexey Feldgendler]

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>