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

[Mihai Parparita]

Just to clarify, I'm only looking to add exception throwing to
cross-origin property accesses of the location object, not for the
whole window object.

As for real-world uses of location.href throwing an exception, a new
comment just got added to:
http://code.google.com/p/chromium/issues/detail?id=17325#c16

Comment 16 by rob at electronicinsight.com, Today (4 minutes ago)
There is definitely real-world use case for this for WebKit. At Sprout
(http://sproutinc.com) we have a generic platform to design mobile
HTML5 ads. We allow designers to link elements in top window and new
window. If they choose "top window", in Android 2.2 the "top window"
link will just refresh the current page when doing
"window.top.location.href = url". We need a way to test for the
security exception and then do window.open(url) instead when that
security error is trapped.

Mihai

On Tue, Aug 17, 2010 at 3:28 PM, Adam Barth <abarth at webkit.org> wrote:
> 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
>