Bug 24437 - Add support for registering noAccess URL schemes
Summary: Add support for registering noAccess URL schemes
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Frames (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Darin Fisher (:fishd, Google)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-03-06 15:53 PST by Darin Fisher (:fishd, Google)
Modified: 2009-03-10 09:26 PDT (History)
2 users (show)

See Also:


Attachments
v1 patch (6.39 KB, patch)
2009-03-06 16:50 PST, Darin Fisher (:fishd, Google)
sam: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Darin Fisher (:fishd, Google) 2009-03-06 15:53:12 PST
Add support for registering noAccess URL schemes

Part of Chrome is built using HTML, and those HTML panels have a special URL scheme called chrome-ui.  We currently have code in the V8 bindings that does denies canAccess for all chrome-ui URLs except that of the web inspector.  It then gives the web inspector univeral access.

This is a bit messy, and it is unfortunate that this knowledge of chrome-ui URLs has to live in the V8 bindings or in WebCore at all.

Instead, I propose the following changes:

1-  Add FrameLoader::registerURLSchemeAsNoAccess, and have SecurityOrigin check that list upon construction (just as it does for isLocal).

2-  Make InspectorController call grantUniversalAccess on its Document's SecurityOrigin at the time when windowScriptObjectAvailable is called.

As a result, noAccess schemes will always return false from SecurityOrigin::canAccess unless grantUniversalAccess has been called.

Thanks to Adam Barth for these suggestions.
Comment 1 Darin Fisher (:fishd, Google) 2009-03-06 16:50:44 PST
Created attachment 28377 [details]
v1 patch

I also added a bit of cleanup to this patch as well:
- moved localSchemes to the top of the file
- renamed LocalSchemesMap to URLSchemesMap
- renamed shouldTreatSchemeAsLocal to shouldTreatURLSchemeAsLocal for consistency
Comment 2 Adam Barth 2009-03-06 18:33:37 PST
Comment on attachment 28377 [details]
v1 patch

>+    // Grant the inspector the ability to script the inspected page.
>+    m_page->mainFrame()->document()->securityOrigin()->grantUniversalAccess();

The mainFrame() in this chain is kind of scary.  If I can get the inspector to load in an iframe, I can get universal access.  I wouldn't block this patch on this issue because we're already screwed in that case because of:

>     // FIXME: This should be cleaned up. API Mix-up.
>     JSGlobalObject* globalObject = m_page->mainFrame()->script()->globalObject();

I should probably file a bug and investigate.

>+bool FrameLoader::shouldTreatURLSchemeAsNoAccess(const String& scheme)
>+{
>+    return noAccessSchemes().contains(scheme);
>+}

I wonder if we need to fast case HTTP here like we do in FrameLoader::shouldTreatURLSchemeAsLocal.  I suspect it doesn't matter since this is only called once per document creation.

It's kind of weird that this state is kept in FrameLoader.  It might make more sense to put these in SecurityOrigin and have FrameLoader ask SecurityOrigin about the security policies for URL schemes.
Comment 3 Darin Fisher (:fishd, Google) 2009-03-06 22:57:57 PST
> The mainFrame() in this chain is kind of scary.  If I can get the inspector to
> load in an iframe, I can get universal access.  I wouldn't block this patch on

Good observation.  I wonder if there is a way for the InspectorController to get the Frame that it is loaded in.


> >+bool FrameLoader::shouldTreatURLSchemeAsNoAccess(const String& scheme)
> >+{
> >+    return noAccessSchemes().contains(scheme);
> >+}
> 
> I wonder if we need to fast case HTTP here like we do in
> FrameLoader::shouldTreatURLSchemeAsLocal.  I suspect it doesn't matter since
> this is only called once per document creation.

I thought about adding a fast path for HTTP, but I came to the same conclusion you did.  Once per document is not enough to worry about.


> It's kind of weird that this state is kept in FrameLoader.  It might make more
> sense to put these in SecurityOrigin and have FrameLoader ask SecurityOrigin
> about the security policies for URL schemes.

Good point.  I just put it on FrameLoader for consistency.  I could certainly move both lists.
Comment 4 Darin Fisher (:fishd, Google) 2009-03-09 13:48:10 PDT
Hey Sam, it looks like you have reviewed changes to SecurityOrigin in the past.  Could you please comment on this patch?  Thanks!
Comment 5 Sam Weinig 2009-03-09 14:23:06 PDT
Comment on attachment 28377 [details]
v1 patch

r=me.  But I agree that we should move this logic into SecurityOrigin code at some point.
Comment 6 Darin Fisher (:fishd, Google) 2009-03-09 17:08:27 PDT
Thanks.  I'm happy to make that change.
Comment 7 Darin Fisher (:fishd, Google) 2009-03-10 09:26:00 PDT
Landed as http://trac.webkit.org/changeset/41555

I decided to do the cleanup to a followup patch, mainly because I have some question about the merits of the shouldTreatURLAsLocal function and the "optimizations" to return early if the scheme is "http" or "file".  I suspect those are premature optimizations since these functions are called ~ once per resource on a page, which is typically not frequently enough to warrant such optimizations.