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

[Alexey Proskuryakov]

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?

With an answer to this question, we can discuss the technical  
approaches, but here are some preliminary comments.

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

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

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

- WBR, Alexey Proskuryakov