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

Maciej Stachowiak mjs at apple.com
Fri Aug 13 00:42:55 PDT 2010


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

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


More information about the webkit-dev mailing list