- From: Brad Hill <hillbrad@gmail.com>
- Date: Fri, 30 Aug 2013 14:38:28 -0700
- To: Ian Melven <ian.melven@gmail.com>
- Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>
- Message-ID: <CAEeYn8gSYZBGyC6gQ96GR=kHK+mEj392O0HBxU8SaCebo=cxJA@mail.gmail.com>
"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