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

[David Levin]

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/76c59cb2/attachment.html>