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

[Adam Barth]

That's a risk, but you could also worry that the name would leak in the
iframe's document.referrer property.

Adam
 On Mar 23, 2012 12:02 PM, "David Levin" <levin at chromium.org> wrote:

>
>
> On Thu, Mar 22, 2012 at 9:21 PM, Adam Barth <abarth at webkit.org> wrote:
>
>> I wonder if we could expose the parent document's origin, so you could
>> write the check as follows:
>>
>> if (parent.location.origin != location.origin)
>>    return;
>>
>> It's slightly subtle because we wouldn't want to expose the origin of
>> child frames (then you could probe the redirect structure of private
>> networks), but exposing ancestor origins seems tenable.
>>
>
> Let's suppose I have some unannounced product like unannounced.google.comand say it embeds an iframe.
>
> Isn't it a information disclosure issue that anyone can now detect the
> usage of unannounced.google.com when they are framed (especially if
> "unannounced" were more descriptive)?
>
> dave
>
>>
>> Adam
>>
>>
>> On Thu, Mar 22, 2012 at 9:16 PM, David Levin <levin at chromium.org> wrote:
>> > Suppose I am using a framework does window.frameElement for various
>> > reasons. When that framework is used in an iframe, it causes errors to
>> > appear in the console.
>> >
>> > For example, suppose the framework does this:
>> >
>> > var a;
>> > try {
>> >     a = window.frameElement; // WebKit outputs a console error here.
>> >     if (!a)
>> >         return;
>> > } catch (e) {
>> >     return;
>> > }
>> > ...
>> >
>> >
>> > Now if I had this new method, I would change the framework to do this:
>> >
>> > var a;
>> > try {
>> >     // WebKit doesn't throw an exception for x-origin parent access,
>> but it
>> > will puts errors in the console.
>> >     // Do an explicit access check to avoid having the error appear in
>> the
>> > console.
>> >     var canAccessParent = window.parent.webkitCanAccess;
>> >     if (canAccessParent != undefined && !canAccessParent)
>> >         return;
>> >     a = window.frameElement;
>> >     if (!a)
>> >         return;
>> > } catch (e) {
>> >     return;
>> > }
>> > ...
>> >
>> >
>> > Does that help? (The use case is about avoiding spurious console error
>> > messages, so console error messages are real errors.)
>> >
>> > dave
>> >
>> >
>> > On Thu, Mar 22, 2012 at 8:44 PM, Sam Weinig <weinig at apple.com> wrote:
>> >>
>> >> Hey Dave,
>> >>
>> >> Can you describe the use case for this new property?  When would an
>> author
>> >> use it?
>> >>
>> >> -Sam
>> >>
>> >> On Mar 22, 2012, at 4:16 PM, David Levin <levin at chromium.org> wrote:
>> >>
>> >> Resurrecting a really old thread so continue the conversation now that
>> I'm
>> >> hitting this issue :).
>> >>
>> >> On Mon, Aug 16, 2010 at 2:16 PM, Sam Weinig <sam.weinig at gmail.com>
>> wrote:
>> >>>
>> >>> I am not sure I agree.  Does our behavior actually cause any real
>> bugs in
>> >>> the places you have tracked down?  The log spam really doesn't seem
>> like an
>> >>> issue, we can remove it if we want to, but have found it useful in the
>> >>> past.
>> >>
>> >>
>> >> Speaking as someone who working on a web app, the log spam is
>> >> a significant issue because:
>> >>
>> >> It clutters up the console output making it harder to find the real
>> error.
>> >> (It is hard to explain how much worse this makes the experience until
>> you
>> >> have to deal with a sophisticated web page. Image looking at the logs
>> from
>> >> your app and seeing lots of error messages -- many of which are this
>> one and
>> >> then a real one hidden among them -- from personal experience.)
>> >> When more sophisticated end users see it, they think there is a
>> problem in
>> >> the app and report it (and it could be that they include this in their
>> error
>> >> report and ignore other more important things).
>> >>
>> >> I understand that that the console/log spam is useful to detect real
>> >> issues as well (given that WebKit doesn't throw an exception in this
>> case).
>> >>
>> >> Would people find it acceptable to have window.webkitCanAccess so that
>> a
>> >> web page can use that property first to detect the cross origin issue
>> and
>> >> avoid doing an access which would trigger the console spam? (I would
>> also be
>> >> fine with an exception instead of log spam.)
>> >>
>> >> Thanks,
>> >> dave
>> >>
>> >>
>> >>
>> >> _______________________________________________
>> >> webkit-dev mailing list
>> >> webkit-dev at lists.webkit.org
>> >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>> >>
>> >>
>> >
>> >
>> > _______________________________________________
>> > webkit-dev mailing list
>> > webkit-dev at lists.webkit.org
>> > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>> >
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20120323/4c52543c/attachment.html>