W3C home > Mailing lists > Public > public-webappsec@w3.org > August 2013

Re: [webappsec] CSP: are blob uri's really just origin='self'?

From: Brad Hill <hillbrad@gmail.com>
Date: Fri, 30 Aug 2013 14:38:28 -0700
Message-ID: <CAEeYn8gSYZBGyC6gQ96GR=kHK+mEj392O0HBxU8SaCebo=cxJA@mail.gmail.com>
To: Ian Melven <ian.melven@gmail.com>
Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>
"The origin <http://www.w3.org/TR/FileAPI/#origin> of a Blob
URI<http://www.w3.org/TR/FileAPI/#url> must
be the origin <http://www.w3.org/TR/FileAPI/#origin> of the script that
called URL.createObjectURL<http://www.w3.org/TR/FileAPI/#dfn-createObjectURL>
. Blob URIs <http://www.w3.org/TR/FileAPI/#url> must only be valid within
this origin <http://www.w3.org/TR/FileAPI/#origin>."  <- once you've done
<script src=xxx>, the origin if that script is now 'self'.  So that seems
to be right...sort of. But it still lets you do eval-equivalent stuff.

To correct myself, Firefox and Chrome do behave a bit differently.  Chrome
allows blobs as script src on 'self'.  Firefox allows blob as a script src
with * in the policy, but not 'self' or the origin creating the blob.  Need
to dig into this more.






On Fri, Aug 30, 2013 at 2:26 PM, Ian Melven <ian.melven@gmail.com> wrote:

> Hi,
>
> interesting !
>
> according to http://www.w3.org/TR/FileAPI/#originOfBlob :
>
> The origin <http://www.w3.org/TR/FileAPI/#origin> of a Blob URI<http://www.w3.org/TR/FileAPI/#url> must
> be the origin <http://www.w3.org/TR/FileAPI/#origin> of the script that
> called URL.createObjectURL<http://www.w3.org/TR/FileAPI/#dfn-createObjectURL>
> . Blob URIs <http://www.w3.org/TR/FileAPI/#url> must only be valid within
> this origin <http://www.w3.org/TR/FileAPI/#origin>.
>
> Things get more interesting when blobs are passed cross origin via
> postMessage, for example. Gecko can't quite do this
> (see https://bugzilla.mozilla.org/show_bug.cgi?id=722126) but from that
> bug it sounds like other browsers do support this.
>
> In the cross origin/postMessage case especially, 'self' seems like the
> wrong thing to be doing.
>
> On first thought at least, linking blobs to 'unsafe-eval' seems like a
> reasonable thing to do - as you say
> the code is coming from unsafe strings...
>
> thanks,
> ian
>
>
>
> On Fri, Aug 30, 2013 at 2:05 PM, Brad Hill <hillbrad@gmail.com> wrote:
>
>> I started writing CSP tests for workers, and realized that the blob:
>> scheme can be used to circumvent inline-script and eval protections. You
>> can grab text out of the DOM or any string, use createObjectURL() and run
>> it as script, so long as 'self' is in the policy.
>>
>> Example here:
>>
>> http://webappsec-test.info/web-platform-tests/CSP/script-src/CSP_1_11.php
>>
>>
>> Mozilla and Chrome both treat blob: as equivalent to 'self'.  They block
>> it if it the policy disallows 'self':
>>
>>
>> http://webappsec-test.info/web-platform-tests/CSP/script-src/CSP_1_11_1.php
>>
>>
>> In another test, the script does the equivalent of an eval using the same
>> blob construction:
>>
>>
>> http://webappsec-test.info/web-platform-tests/CSP/script-src/CSP_1_11_2.php
>>
>> I wonder if this is the right treatment.  It seems that blob: data could
>> come from anywhere, and that using it as the source of a script or worker
>> is creating code from unsafe strings.  I wonder if we shouldn't link it to
>> unsafe-inline, unsafe-eval, or both rather than to 'self'?  Otherwise it
>> seems like an obvious bypass.
>>
>> (source at: https://github.com/hillbrad/CSP/)
>>
>> :(
>>
>> -Brad
>>
>
>
Received on Friday, 30 August 2013 21:38:56 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:02 UTC