Re: Updates to File API

On Mon, Jun 14, 2010 at 11:35 AM, Mark Seaborn <mseaborn@chromium.org> wrote:
> On Mon, Jun 14, 2010 at 12:40 AM, Jonas Sicking <jonas@sicking.cc> wrote:
>>
>> On Sun, Jun 13, 2010 at 10:46 PM, Mark Seaborn <mseaborn@chromium.org>
>> wrote:
>> > Why do the "filedata:" URLs need to apply a same-origin check?  It seems
>> > like this would unnecessarily reduce composability.  In practice, the
>> > URLs
>> > returned by the File API would be unguessable anyway.  Why not use
>> > unguessability of these tokens as the security mechanism?  So if a web
>> > app
>> > wants to share the file with other, co-operating entities (e.g. in an
>> > iframe
>> > or another tab), it can do so by sharing the URL; otherwise, it can
>> > withhold
>> > the URL.
>> >
>> > When would the currently-proposed same-origin checks apply?  Would I be
>> > right in thinking that they only apply to XMLHttpRequests from
>> > Javascript,
>> > and don't apply if the URL is linked from an <img> element?
>>
>> URLs weren't always designed to be security sensitive. One common way
>> they leak is through the "referer" (sic) header. So if the File whose
>> .url you were loading was an HTML file, and you loaded it using an
>> <iframe>, you could very easily leak the URL to untrusted parties.
>
> That's true for "http:" URLs, but AFAIK it's not true for "https:" URLs.
> The browser is not supposed to disclose HTTPS URLs via the Referer header,
> and I know of at least one app (Tahoe-LAFS) that relies on that.  Since the
> File API is creating the new "filedata:" URL scheme, it can specify that it
> has the same property.

I'd still be extremely worried that it's much too easy to leak the
URLs. Additionally, it's always risky to pass a filedata url to
another page as the lifetime of the filedata url is bound to the
document that made the call to File.url.

Instead it's better to pass the File object around, through for
example postMessage, and let every page that needs it request the url.

>> At the very least the same-origin check applies such that if a
>> cross-origin file uri is used on <img>, this would be considered a
>> cross-origin load if that <img> was later pasted into a <canvas>.
>> Similarly, if a cross-origin <video> is loaded, I think some events
>> are with-held, though I'm less sure about that.
>>
>> However, in firefox we've taken a more strict approach. We disallow
>> cross-origin <img> loads for filedata URIs. I.e. if site A receives a
>> File with a url. Then even if site B manages to get hold of that url,
>> it can't use <img> to load it.
>
> This is adding a new mechanism, isn't it, since <img> was previously
> considered to be normal linking and did not have a same-origin check.
>
> What would happen if a page has an <a href="filedata:..."> link?

That's a good question. I think the result of our implementation is
that the navigation is prevented, similar to how firefox prevents
navigating to a link like <a href="file://some/local/fs/path">. I.e.
we don't change the DOM, however if the user clicks the link nothing
happens.

/ Jonas

Received on Monday, 14 June 2010 20:54:09 UTC