SES meeting notes

Waldemar Horwat waldemar at
Wed Jan 28 10:55:24 PST 2009

Here are my notes from yesterday's SES meeting.  I tried to cover the highlights but these are not all-inclusive of all of the discussions that took place.


SES meeting Jan 27 2009

ES3.1 opens up the possibility of exposing protected objects to unprotected code and have the protected objects stay safe.  Maybe not:  toSource, watch (to set watchpoints on properties), Mozilla's two-argument eval, debugging interfaces, ES3.1 code deliberately causing a stack overflow in a specific place in secure code, ...?

If foo is a function stored into myProtectedObject, can leak myProtectedObject to foo.  Fixes:
1.  (true &&
2.  Wrap foo when storing it into a property of myProtectedObject

Lots of practical security trouble caused by called methods re-entering the calling object, doing recursive calls.

ES3.1 Object.getOwnProperties can enumerate all properties, including non-enumerable ones.  This may allow blacklisting runtimes to delete properties they don't know about, as long as they're deletable.

Allen: Things will stay confusing unless we define the behavior of multiple global objects and how objects interact between them.

The trouble with proxies:  We can write a proxy for some of the things that JavaScript does, but proxying the proxy itself is problematic.  The analogue to microprocessor instruction set virtualization breaks down because for microprocessors there is a clear boundary between instructions and software: emulating all supervisor instructions is sufficient, with libraries running virtualized.  With JavaScript the DOM would not be running virtualized, and it's problematic to locate all places where property lookups could show through.

Proxying a property with a getter/setter pair -> need to resolve the problem of someone setting an expando in a derived object (behavior differs for setters) -> need to resolve the problem of someone calling getOwnProperty, hasProperty, for-in, etc. -> ...

W3C:   Need to work with W3C to make the DOM secure.
All DOM nodes are connected via parents to document root, which then allows access to the network.
Style sheets are in a single global namespace -- problem for ads, mashups.  Can use iframes, but want some inheritance for backgrounds and such.

- A frame-like thing within a document that comes from the source
- Modifications in the way events bubble
- Looking up elements by id in a subtree (but may also need to exclude virtualized subtrees to avoid inadvertent or deliberate id collisions)
- Impact of the DOM model on Caja-like isolation
- Feeling of the DOM being too complicated (of course, discussing such generic feeling won't go anywhere)

Adoption Agency algorithm:
<b><i>foo</b>bar</i> -> <b><i>foo</i></b><i>bar</i>
Problem is that it can clone unique id's:
<b><i id=100>foo</b>bar</i> -> <b><i id=100>foo</i></b><i id=100>bar</i>

Clever history attack that works even on DOMs that masquerade programmatic queries to visited links as though they were non-visited:
Set the height of visited links to 100; then query the position of some element after the link to see how high on the page the browser layout put it.

HTML names and id's are reflected as properties of the global object (but won't shadow existing globals).

Microsoft Web Sandbox:  ~300K of JavaScript source for the sandbox, ~28K compressed minimized, almost all of which is policy rules and emulators on DOM calls and such.  Apache open source.

More information about the Es-discuss mailing list