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

[Maciej Stachowiak]

On Aug 13, 2010, at 2:12 AM, Jeremy Orlow wrote:

> On Fri, Aug 13, 2010 at 8:42 AM, Maciej Stachowiak <mjs at apple.com> wrote:
> 
> On Aug 12, 2010, at 8:08 PM, Mihai Parparita wrote:
> 
>> I was wondering if it would be a reasonable change to make accessing location.href (and other location properties) throw SECURITY_ERR when accessed across origins (https://webkit.org/b/43504). This initially was reported on the Chrome side (giv), but it looks like neither the JSC nor V8 bindings do this, so fixing it across the board seemed reasonable.
>> 
>> From my investigations, it looks like IE and Gecko both throw an exception in this case, and the HTML5 spec mentions it too (http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#security-location).
>> 
>> I realize that we're cautious around the access checks for security reasons (based on changes like https://trac.webkit.org/changeset/48619), but this seems safe since 1) we were returning control to the script at that point anyway 2) we already throw exceptions in some cases in that code: https://trac.webkit.org/browser/trunk/WebCore/bindings/js/JSLocationCustom.cpp#L219
> 
> I think what we do is better than what HTML5 specifies for this:
> 
> 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.
> 
> 2) If access is denied for security reasons, it seems like it gives the attacker less information and less potential attack surface to just give them an undefined value instead of raising a security exception. Security errors make it easier to probe.
> 
> So in general I'm not in a rush to change this. However, if the original bug involved a compatibility problem on a real site (it doesn't really say), then maybe that would be a stronger reason to change.
> 
> Regards,
> Maciej
> 
> If we're willfully going against the spec because we think our solution is better, should this be brought up on WhatWG or in the HTML WG?  (Or has it already?)

It might be, but before taking that step, I'm really curious if the bug that sparked this discussion was based on a real compat issue that the author ran into.

Regards,
Maciej


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20100813/1fd8133b/attachment.html>