On Aug 13, 2010, at 2:12 AM, Jeremy Orlow wrote: > On Fri, Aug 13, 2010 at 8:42 AM, Maciej Stachowiak <m...@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
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
