[webkit-dev] Allowing webkit clients to extend XHR security policy

Thu Apr 9 01:00:10 PDT 2009

I have some relevant context that I'll add.
On Thu, Apr 9, 2009 at 12:38 AM, Aaron Boodman <aa at chromium.org> wrote:

> On Wed, Apr 8, 2009 at 11:53 PM, Alexey Proskuryakov <ap at webkit.org>
> wrote:
> >
> > On 09.04.2009, at 1:23, Aaron Boodman wrote:
> >
> >> Rafael Weinstein, who is working with me, consulted with Adam Barth
> >> and submitted a patch based on his ideas
> >> <https://bugs.webkit.org/show_bug.cgi?id=24853> for this a few weeks
> >> back. It has met with resistance though, and we're not really sure
> >> where to go next.
> >
> >
> > I discussed this with Rafael over IRC a few days ago, and it seems that
> the
> > biggest issue is entirely Chrome-specific. As all extensions share the
> same
> > URL scheme, it is not safe to give them different privileges. As a
> comment
> > in SecurityOrigin says,
> >
> >   // <...>  Granting privileges to some, but not all, documents
> >   // in a SecurityOrigin is a security hazard because the documents
> without
> >   // the privilege can obtain the privilege by injecting script into the
> >   // documents that have been granted the privilege.
> >
> > Is there a solution for this issue already, or is it something the Chrome
> > team is willing to ignore as a low risk threat?
>
> Chromium extensions run in the same scheme (chrome-extension://), but
> they do not run in the same origin. They all have unique origins of
> the form chrome-extension://<extension-id>/. Security origin is scheme
> + host + port.
>
> >> * Some people don't like the idea that the callback gets invoked on
> >> multiple threads.
> >
> > I don't like this idea, but as I said on IRC, it is acceptable to have
> this
> > as a temporary solution. However, I wonder how this will work in Chromium
> > for XMLHttpRequest calls made from workers, with the loader being in a
> > different process, not a different thread.
>
> I see. It seems like a static call like in the current patch would be
> easy to make work. Things that rely on more of the loader
> infrastructure seem less likely. But I need to research this more,
> I'll reply tomorrow.

I think we can make this work fine with Chromium.  It may require another
callback in a different place, but that is the nature of the issue in
chromium (if v8 supported threads in the renderer my life would be much
easier).  I'm sorry that I'm not further along with the chromium worker
loader which would help in this conversation (if there were something more
concrete there).

> >> * some people think it's ugly to have SecurityOrigin making calls out
> >> to static methods and think it should have a normal instance client.
> >
> > I mostly agree with that  - I think that this should be done via
> > FrameLoaderClient. I also think that the solution should obsolete and
> remove
> > FrameLoader::registerURLSchemeAsLocal().
>
> I don't mind doing it on FrameLoaderClient. Forgive the noob question,
> but I'm newish to webkit... How should this be plumbed? I don't see
> any direct access to FrameLoader or FrameLoaderClient from XHR, which
> makes sense since XHR is happening on multiple threads.
>

I spent quite a long time removing this.  Don't try to access FrameLoader
directly from XHR (or I will return your wet noodle threat you once made :)
).

Right now, XHR only relies on ThreadableLoader which is either a
WorkerThreadableLoader or a DocumentThreadableLoader.
WorkerThreadableLoader uses DocumentThreadableLoader in a cross thread
dance.
DocumentThreadableLoader uses SubresourceLoader (which derives from
ResourceLoader and ResourceLoader uses FrameLoader for a few callbacks).

Not sure if that clears things up for you or not.

> >> I was hoping
> >> that I could add a method to FrameLoaderClient and call it from XHR,
> >> but I don't see a nice way to get to FrameLoaderClient from XHR.
> >
> > Same question - with FrameLoaderCleint being in a different process for
> XHR
> > in workers, I don't see how this could possibly work. Am I perhaps
> > misunderstanding the Chromium loader architecture?
>
> Yeah good point. I'll look into this.

I'm in the process of this in between other things (but I got way too
obsessed/distracted with changes to run-webkit-tests lately and I'm in the
middle of finishing uploading some string changes as well).

Because workers in chromium will run in a different process from the render
for a page, the FrameLoader isn't a good fit (no Frame).  I've been working
on a loader similar to ResourceLoader that doesn't rely on Document/Frame.
 (I wanted to get this working and then discuss the proper factoring with
webkit folks.)  But if it is a separate loader, it would have its own
callbacks to the host.

> >
> >> 4) Refactor all access checking (current same-origin checks, "local
> >> scheme" stuff, preflight stuff for AC) into DocumentThreadableLoader.
> >> Then add a new callback for what we want on FrameLoaderClient. One
> >> meta-question I have about this approach is whether it's really the
> >> right thing to do XHR-specific access checks in
> >> DocumentThreadableLoader and friends. In general, I'd rather not
> >> embark on a big refactor to get this done, but I'm still open to it if
> >> that's the only option.
> >
> >
> > At least the preflight stuff for AC logically belongs to
> > DocumentThreadableLoader - we need to move it there to reasonably
> implement
> > redirects for cross-origin requests. The rest (which I think is just
> > canLoadLocalResources checks for Dashboard) isn't relevant to this
> > discussion, because these checks do not access static data.
>
> But how will DocumentThreadableLoader know what policy to apply?  Some
> things are allowed to be loaded across origins (iframes) without AC,
> and some things aren't (XHR). Maybe I am misunderstanding and
> DocumentThreadableLoader is only used for XHR? Or maybe there is some
> context that will be available?
>

Yes, DocumentThreadableLoader is only used by XHR and worker.importScripts,
but (in theory at least) it seems simple enough to be able to have some flag
to turn on/off this check.

> I'm sure I'm just misunderstanding here, I'm just curious what you had
> in mind more than anything.
>
> - a
> _______________________________________________
> 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/20090409/2072296b/attachment.html>