Bug 16824

Summary: Script authorization should follow lexical (not dynamic) scope
Product: WebKit Reporter: Adam Barth <abarth>
Component: WebCore JavaScriptAssignee: Nobody <webkit-unassigned>
Status: RESOLVED FIXED    
Severity: Normal CC: arv, brendan, collinj, ggaren, koivisto, mal, mjs, sam
Priority: P2 Keywords: InRadar
Version: 528+ (Nightly build)   
Hardware: All   
OS: All   
URL: http://crypto.stanford.edu/~abarth/research/webkit/static/
Bug Depends on:    
Bug Blocks: 16011    
Attachments:
Description Flags
Preliminary patch
none
Example of dangers of dynamic scope (needs to be run from a file URL) none

Description Adam Barth 2008-01-10 13:44:01 PST
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.
Comment 1 Adam Barth 2008-01-10 13:48:07 PST
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.
Comment 2 Adam Barth 2008-01-10 13:53:22 PST
> It breaks 4 security LayoutTests.

Oops.  Typo.  6 security LayoutTests.
Comment 3 Collin Jackson 2008-01-10 15:05:32 PST
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.
Comment 4 Collin Jackson 2008-01-10 15:11:32 PST
> 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.
Comment 5 David Kilzer (:ddkilzer) 2008-01-10 21:32:46 PST
<rdar://problem/5683032>
Comment 6 Adam Barth 2008-02-07 23:10:08 PST
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.
Comment 7 Sam Weinig 2008-05-01 19:13:03 PDT
Fixed in r32791.