[webkit-dev] Blob changes to SecurityOrigin.cpp

[Jian Li]

On Fri, Sep 3, 2010 at 4:08 PM, Adam Barth <abarth at webkit.org> wrote:

> On Fri, Sep 3, 2010 at 4:02 PM, Jian Li <jianli at chromium.org> wrote:
> > On Fri, Sep 3, 2010 at 3:43 PM, Adam Barth <abarth at webkit.org> wrote:
> >> On Fri, Sep 3, 2010 at 3:19 PM, Jian Li <jianli at google.com> wrote:
> >> > The reason that we skip the unique origin check here is to allow a
> local
> >> > running worker script to be able to access a blob URL. Do we want to
> >> > disallow this case?
> >>
> >> The access rights of locally running content are controlled by a
> >> WebCore::Setting.  Currently, Chrome sets that setting to the most
> >> restrictive value to mitigate the harm a downloaded HTML file can
> >> cause.  It doesn't seem like a good idea to circumvent that security
> >> setting.
> >
> > Ok, this sounds right. It means that we should not allow accessing a blob
> > URL from a local worker script per the settings, right?  If so, I can get
> > rid of this particular step.
>
> Yes, great.
>
> >> I don't quite understand what this code is trying to do:
> >>
> >> bool SecurityOrigin::canLoad(const KURL& url, const String& referrer,
> >> Document* document)
> >> {
> >> #if ENABLE(BLOB)
> >>    if (url.protocolIs("blob") && document) {
> >>        SecurityOrigin* documentOrigin = document->securityOrigin();
> >>        RefPtr<SecurityOrigin> targetOrigin =
> SecurityOrigin::create(url);
> >>        return documentOrigin->isSameSchemeHostPort(targetOrigin.get());
> >>    }
> >> #endif
> >>
> >> Why should canLoad care about isSameSchemeHostPort?  In the past,
> >> canLoad's job was to stop web sites from loading content from your
> >> local file system (e.g., in frames or as images).
> >
> > Per the File API spec, the blob URL should not be accessed from the page
> in
> > other security domain. Checking isSameSchemeHostPort will help us enforce
> > this policy when other page in different domain that tries to load this
> URL
> > from the cache. Probably I need to put better comment here or maybe find
> a
> > better place to do such check.
>
> Sorry canLoad is poorly named.  I'm working on a patch now to rename
> it to something more sensible (canDisplay, perhaps?).  We use canLoad
> to control things like <frame src="..."> and <img src="...">.  When
> you say "not accessible," do you mean that they shouldn't be able to
> be displayed with the image element?
>
> Yes. Let me use an example to explain this.

Suppose page1 (http://foo/page1) creates a blob URL "blob://id1" from an
image file. In page1, blob://id1 is loaded and put into cache when we
replace any img element. In page2 (http://bar/page2), it grabs this blob URL
in some way and uses it towards its img element. We should not allow this
happen per the File API spec. Without this check in canLoad(), page2 has no
problem to use it directly from the cache.



> Adam
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20100903/a7137d55/attachment.html>