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

It looks like (writing more tests) that Firefox allows it if you
specifically put "blob:" as a source-expression, (like "data:" or *) but
Chrome doesn't allow "blob:" as a source-expression, and uses exclusively
'self' to gateway blob uris.


On Fri, Aug 30, 2013 at 2:38 PM, Brad Hill <hillbrad@gmail.com> wrote:

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