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

[Aaron Boodman]

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.

>> * 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 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.
>
>> 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?

I'm sure I'm just misunderstanding here, I'm just curious what you had
in mind more than anything.

- a