[whatwg] a rel=attachment

2011/7/15 Jonas Sicking <jonas at sicking.cc>:
> We've discussed a different solution to the same problem at mozilla.
> The solution we discussed was allowing FileSaver to in addition to
> taking a blob argument, allow it to take a url argument.
>
> One concern which was brought up was the ability to cause the user to
> download a file from a third party site. I.e. this would allow
> evil.com to trick the user into downloading an email from the users
> webmail, or download a page from their bank which contains all their
> banking information. It might be easier to then trick the user into
> re-uploading the saved file to evil.com since from a user's
> perspective, it looked like the file came from evil.com

It seems like the solution to that problem is to be clear about where
the download is coming from.  Being clear about where downloads come
from is important in many scenarios, beyond just this setting.

> Another possible attack goes something like:
> 1. evil.com tricks the user into downloading sensitive data from bank.com
> 2. evil.com then asks the user to download a html from evil.com and
> open the newly downloaded file

Most browsers treat downloaded HTML files as "dangerous downloads,"
which means they get similar UI treatment to executable downloads.
For example, on Mac OS X, HTML downloads get the same "you're about to
open a dangerous file" warning from the operating system as executable
downloads.  If the attacker can convince the the user to click past
these dialogs, the attacker can convince the user to run arbitrary
code anyway, so there's nothing we can do to provide security in this
setting.

> 3. the html file contains script which reads the contents from the
> file downloaded from bank.com and sends it back to evil.com

This sounds like a security vulnerability in the browser.  A better
security posture is to not allow downloaded content from one web site
read downloaded content from another web site, regardless of how the
content was downloaded.  For example, that's the current behavior of
Chrome and Internet Explorer.  Safari takes a different approach and
allows downloaded HTML content to access any file and any web site,
which means the attacker doesn't need to go through the elaborate
process you've outlined.  Merely performing step (3) is sufficient to
steal all the user's banking details today, which tells me that either
Safari is already vulnerable to this attack without this new feature
or that this threat isn't actually much of a risk.

(I know that Firefox has a policy that's somewhere in between the
strong local-file security policy used by Chrome and the weak policy
used by Safari, but Firefox's policy is too complex for me to
understand.  I know that protection of downloaded files was one of the
considerations that fed into the design of Firefox's policy, but I'll
leave it to others to common on whether it provided effective
protection in this scenario.)

> Step 1 and 2 require the user to answer "yes" to a dialog displayed by
> the browser. However it's well known that users very often hit
> whichever button they suspect will make the dialog go away, rather
> than actually read the contents of the dialog.

In that model, the attacker can just run arbitrary code.  It's not
possible to provide security in that model, regardless of this
feature.

> Step 3 again requires the user to answer "yes" to a dialog displayed
> by the browser in at least some browsers. Same caveat applies though.

In this case, the caveats are important.  As described above, Chrome
is not vulnerable to this attack and Safari is vulnerable to this
attack even without this feature.

> One very simple remedy to this would be to require CORS opt-in for
> cross-site downloads. For same-site downloads no special opt-in would
> be required of course.

I'm not convinced there's a problem to solve here.  Wiring CORS into
the download system, by contrast, add a significant amount of
complexity to the implementation, which is costly.

> It's also possible that it would be ok to do this without any opt-ins
> since there are a good number of actions that the user has to take in
> all these scenarios. Definitely something that I'd be ok with
> discussing with our security team.

I'm happy to talk it over with your security folks if they disagree
with the contents of this email.

> Tentatively I would feel safer with the CORS option though. And again,
> for same-site downloads this isn't a problem at all, but I suspect
> that in many cases the file to be downloaded is hosted on a separate
> server.

It's important to think these scenarios through carefully, but in this
case I think we're fine without CORS.

Adam

Received on Sunday, 17 July 2011 13:05:17 UTC