W3C home > Mailing lists > Public > whatwg@whatwg.org > May 2006

[whatwg] Side effects free scripts

From: Alexey Feldgendler <alexey@feldgendler.ru>
Date: Sat, 27 May 2006 23:58:28 +0700
Message-ID: <op.s97yrqgq1h6og4@pancake.feldgendler.ru>

Some more thoughts on security of scripted documents.

Though sandboxing, as discussed earlier on this mailing list [1], would be  
a powerful tool to ensure security of scripted documents, it's overkill in  
many situations. Analyzing typical vulnerabilities found in web  
applications, I have found that many of them are caused by the possibility  
to trick the user agent into execution of a malicious script. This is  
often achieved by including scripts in unusual places in user-supplied  
code, such as the following text in a blog comment:

<span style="color:expression(...steal cookies...)">LOL!</span>

If the HTML cleaner fails to strip this, too bad. Sometimes, it's more  
complex than that, but the idea is the same: put a script in some  
unexpected place. (Another example:  
style="background:url(javascript:...)".)

Sandboxes would, of course, deal with this, but there is a much simpler  
measure targeted specifically at such exploits.

I propose to define the notion of "side effect free script". All browsers  
which allow scripts in declarations like CSS should only allow side effect  
free scripts in such places.

A script thread should be started in side effect free mode if the script  
is invoked from:

1. Anywhere within CSS, including inline style attributes.

2. Any javascript: URI of external stylesheets, scripts, objects and such.

3. Other ideas?

When a script thread is in side effect free mode:

1. It stays in this mode until the thread completes.

2. It can call any non-native function, but the same restrictions apply.

3. It cannot assign any variables except locals.

4. It cannot call any native function except those specifically marked by  
the spec as side effects free. For example, sin() is side effects free,  
and window.open() is not.

5. It can read any property that can be normally read.

6. It cannot assign any property for which a native setter function is  
used.

7. It cannot create new object instances except those specifically marked  
by the spec as side effects free. For example, RegExp is side effects  
free, and Image is not.

8. Any attempt to break these restrictions should generate an exception.

9. Optionally, execution time limit may be imposed on the thread, so that  
it doesn't make the document unrenderable by running an endless loop  
inside CSS expression().

The above is very raw thoughts. I'd like to hear some feedback on the idea  
itself.

References:

1.  
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2005-December/005301.html


-- 
Alexey Feldgendler <alexey at feldgendler.ru>
[ICQ: 115226275] http://feldgendler.livejournal.com
Received on Saturday, 27 May 2006 09:58:28 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:27 UTC