Re: Data uris, was: Re: Enable compression of a blob to .zip file

On 12/3/11 5:51 PM, Jonas Sicking wrote:
> On Fri, Dec 2, 2011 at 6:06 PM, Charles Pritchard<chuck@jumis.com>  wrote:
>> On 12/2/11 5:41 PM, Jonas Sicking wrote:
>>> On Fri, Dec 2, 2011 at 5:05 PM, Charles Pritchard<chuck@jumis.com>    wrote:
>>>> There have been no steps to expand or otherwise support base64 encoding,
>>>> nor
>>>> data uris, from a higher level.
>>> What do you mean by this? base64 encoding has been supported in
>>> datauris as long as data uris have been supported, and base64 encoding
>>> in general has been supported far longer than that.
>> There are no binary base64 encoding methods available to the scripting
>> environment, there are no new types [btoa and atob already existing methods]
>> relating to base64 strings. There are no optimizations nor new helper
>> methods.
> Why doesn't btoa and atob count just because they exist? If we exclude
> all functions that exist then of course there is no support. For
> anything!

They don't count because they hurt my feelings every time I use them 
with binary data. And they're not new.
> Are you perhaps specifically pointing out that there are not built-in
> methods that converts between ArrayBuffers and base64 encoded strings?

The methods convert DOMString. They fall apart across implementations 
when binary data is used from String.

I was wrong in claiming there were "no new types" relating  to base64 
strings.
FileReader.readAsDataURL does offer improved data: uri support for 
encoding binary data.



>>>>>> recently, Chrome started limiting paste into
>>>>>> address bar length, Firefox limited paste into address bar altogether.
>>>>> This is due to a recent rise of social engineering attacks which
>>>>> tricked users into pasting unknown contents into the URL bar. It might
>>>>> apply to to blob uris as much as data uris. Though given that blob
>>>>> uris still require script to be created, it isn't currently a problem.
>>>>> But this might change in the future.
>>>>
>>>> Yes, that's exactly what Firefox reports, now. I wouldn't call this a
>>>> bug.
>>>> It's also an intentional limitation.
>>>>
>>>> What motivations are there for Firefox to block user-copying of blob
>>>> urls?
>>> If/when we get to a point when blob-uris can be used to launch social
>>> engineering attacks I don't see why we wouldn't block it. This could
>>> for example happen if websites start running untrusted code in the
>>> context of their origin, for example using technologies like Caja.
>>
>> Are there means in Mozilla for running untrusted code outside of the context
>> of their origin?
> I don't understand the question.

Sorry I asked it without more information, and more study.
<iframe sandbox> was specifically created to run outside of the current 
origin and it has broad support.
So, my question is dated, moot. Mozilla already supports the it.

Background:

The following nastiness is currently tolerated by Webkit and Mozilla, it 
appears:
iframe.src = "data:text/html,<meta http-equiv='refresh' 
content=\"0;URL='data:text/html,<object 
 ></object><script>alert(31337);</script>'\">";

That breaks out of the current origin and goes into what amounts to a 
null origin.
localStorage will throw an error in Webkit, but is tolerated in Mozilla 
(though I doubt it does much).


iframe sandbox allows authors to run untrusted code outside of the 
current origin, in a safe manner.
<iframe sandbox="allow-scripts">

Microsoft does not allow data uris to be used as the source of an iframe.
Microsoft is supporting <iframe sandbox>
http://msdn.microsoft.com/en-us/library/hh673561.aspx

I suspect vendors may retire data uris for <iframe>, in time.

Vendors may suspect that users will retire IE, in time. But that's a 
different topic.


As an aside, there's a good example here of using Blob urls for web 
workers, instead of data uris:
http://www.html5rocks.com/en/tutorials/workers/basics/

Afaik, Microsoft has not yet chimed in about Blob urls and iframe.


>> Thanks for providing the example, I understand that something in Caja might
>> create a blob url which would contain a same origin script untrusted by the
>> publisher, and that script would effectively "break" through the Caja
>> sandbox. I believe Caja is supposed to prohibit scripts from accessing APIs,
>> such as createObjectUrl. Regardless, I appreciate you coming up with an
>> example, and I'll continue to consider what social engineering attacks may
>> be present.
>>
>> I'd like to allow users to easily click and drag and copy and paste URIs. I
>> hope we can still have that with blob:, but I understand that may not be
>> sustainable.
> I don't believe Caja completely blocks access to any API. Instead it
> offers a policy framework such that you can choose what APIs that you
> want to expose.
>
> The risk appears if a site like facebook were to allow javascript to
> execute on their site while also wanting to allow such script to
> access the File API. In such a scenario the page could do something
> like:

Wouldn't they simply limit access to the URL object, so that 
URL.createObjectURL can not be run?
Or would they keep access on, so authors can use it?

As I've noted, in Webkit, it seems that blob: urls can not be created in 
anonymous scopes.

I've not double checked this: I believe that sandboxed script running 
createObjectURL simply returns undefined.


> var str = createObjectURL(new Blob("<script>function sendToServer(s)
> {...} sendToServer(document.cookie)</script"));
> displayOnScreen("copy the following text to your url bar for free
> smiley icons " + str);
>
> Of course, no websites do this today. But if it happens in the future
> we might need to re-evaluate our policy for typing/pasting blob: urls
> in the url-bar. Just like we did with data: and javascript:

That's an interesting example.

Is this something that can be avoided early on by Caja by running 
revokeObjectURL immediately after the createObjectURL call?
I realize it's counter-intuitive, but I've seen this pattern [somewhere] 
on the web before:
url = URL.createObjectURL(blob);
img.src = url;
URL.revokeObjectURL(url);


I don't think it'll be necessary, as I think it's likely that, unless a 
sandbox iframe has same origin, it won't be able to create object urls.

-Charles

Received on Sunday, 4 December 2011 02:58:57 UTC