[webkit-dev] Throwing SECURITY_ERR on cross-origin window.location property accesses

[Adam Barth]

On Mon, Aug 16, 2010 at 7:49 PM, Maciej Stachowiak <mjs at apple.com> wrote:
> On Aug 13, 2010, at 9:59 AM, Mihai Parparita wrote:
>> On Fri, Aug 13, 2010 at 12:42 AM, Maciej Stachowiak <mjs at apple.com> wrote:
>>> 1) It means the access control goes in fewer places - we don't have to have
>>> access control on every document property, only window properties.
>>
>> I'm not quite sure I understand this. At least for the location
>> object, I see an explicit check in JSLocationCustom.cpp:
>> http://trac.webkit.org/browser/trunk/WebCore/bindings/js/JSLocationCustom.cpp#L71.
>> Throwing the exception would happen there too (it won't require custom
>> getters for each property).
>
> Yes, a small handful of objects that hang off of Window are accessible cross-origin and have their own security checks. However, one property of Window is handled very differently between WebKit-based browsers and what the spec calls for. someCrossOriginWindow.document returns undefined in WebKit-based browsers, but it returns a document object per the spec which then does its own security check on every property access. This is unfortunate because the attack surface is increased and performance suffers. And it's not Web-compatible to just throw on access to the document property - Web apps expect they can always ask for the document, and it's the *next* property access that throws, which is fulfilled by returning undefined since accessing a property of the undefined value throws in JS. For cases like the location object, it doesn't matter much either way.

I believe the spec no longer exposes someCrossOriginWindow.document.
(As to whether it throws a security exception or returns null, I'd
have to look more carefully.)

Adam