Bug 16824 – Script authorization should follow lexical (not dynamic) scope

• Component: WebCore JavaScript
• Status: RESOLVED FIXED

[Adam Barth]

There are two methods for determining the security context associated with a given script:

1) Lexical scope: Pick the principal associated with the document that contains the script.

2) Dynamic scope: Walk up the run-time stack and pick the principal associated with the top-most stack frame.

Firefox and Internet Explorer use the lexical scope for authorization.  Safari and Opera use the dynamic scope for authorization.  HTML 5 specifies that user agents use the lexical scope: "The origin of the script is the origin of the Document to which the script element belongs."

<http://www.whatwg.org/specs/web-apps/current-work/#origin>

WebKit should match Firefox, Internet Explorer, and the HTML 5 spec by using the lexical scope for authorization.

[Adam Barth]

Created attachment 18375 [details]
Preliminary patch

Attached is a preliminary patch.  It breaks 4 security LayoutTests.  This seems to be because DOMWindow retains its m_frame pointer after the frame has navigated to a new URL.

[Adam Barth]

> It breaks 4 security LayoutTests.

Oops.  Typo.  6 security LayoutTests.

[Collin Jackson]

Created attachment 18379 [details]
Example of dangers of dynamic scope (needs to be run from a file URL)

Dynamic scope makes it extremely difficult to write correct code when code from different origins interacts (for example, when a file:// page access an http:// page in bug 16011).

Here is a test case that is designed to be run from a file:// URL. It creates an iframe to an http://crypto.stanford.edu/ page and implicitly calls the toString() method of that frame: 

  "My child is " + frames[0]

Because dynamic scope is used, the crypto.stanford.edu page can hijack the privileges of its parent file:// page and steal your cookies from any site. If lexical scope were employed, the attacker could still overwrite the toString() method but wouldn't gain any additional privileges.

This is hard for web attackers to exploit because Safari prevents web sites from directing the browsers from file:// URLs. As shown by the LayoutTest included in the patch, however, http sites can also run into this problem using document.domain.

[Collin Jackson]

> This is hard for web attackers to exploit because Safari prevents web sites
> from directing the browsers from file:// URLs. 

Oops. Typo. Safari prevents web sites from directing the browser *to* file:// URLs.

[David Kilzer (:ddkilzer)]

<rdar://problem/5683032>

[Adam Barth]

I don't have access to <rdar://problem/5698200> (a compatibility issue with eBay), but it appears to be a duplicate of this bug.  The patch committed for that issue (r30009) seems to be wrong.  That patch first checks access using dynamic authorization, and, if that fails because document.domain was set, retries the access check with static authorization.

The correct fix would appear to be to adopt static authorization (matching IE and Firefox) as recommended in this bug.

[Sam Weinig]

Fixed in r32791.