[whatwg] a rel=attachment

On Sun, Jul 17, 2011 at 1:05 PM, Adam Barth <w3c at adambarth.com> wrote:
> 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.

Sure, I'm just not sure that we'll ever be able to get very high
percentage of people actually understanding and making sure they make
a informed decision based on this.

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

That wasn't the security model IE used last I checked. At least at
that time it would refuse to run any scripts while displaying a
warning to the user telling them that they needed to opt-in to scripts
on the page. Opting in was a simple matter of pressing a "yes button"
though and so is something that a decent number of people likely will
do. However it's possible that IE has changed since then.

I just tried and this doesn't appear to be what chrome does. I'd love
to hear the details about chrome's strategy.

> (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.)

Firefox *basically* lets the page read the contents of the folder that
the html file is in, as well as any sub folders. There are some tricky
situations where more than that is allowed, but that's generally not
relevant to this discussion.

However since Firefox allows the page to read the contents of the same
folder, this means that the script would be allowed to read files
downloaded from other sites.

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

I'm not quite sure what you mean here?

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

The fact that it's a bit more work for the browser implementation
seems like a good tradeoff if it means less data stolen from users. So
this isn't an argument that carries much weight for me.

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

Sure, we can schedule a security review of this feature if this is a
route that we really want to go. I'll contact you off this list.

/ Jonas

Received on Sunday, 17 July 2011 20:40:56 UTC