[webkit-dev] Allowing webkit clients to extend XHR security policy
ap at webkit.org
Wed Apr 8 23:53:33 PDT 2009
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
// the privilege can obtain the privilege by injecting script into
// 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
> 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
More information about the webkit-dev