[whatwg] a rel=attachment

[Adam Barth]

On Sun, Jul 17, 2011 at 8:40 PM, Jonas Sicking <jonas at sicking.cc> wrote:
> 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.

Chrome treats every local HTML document as having a unique origin
(i.e., as defined by HTML5 for the sandbox attribute).  That means
local HTML files can't read other files in the user's file system,
including other downloads.  This policy makes some users sad, but we
feel the security benefits outweigh that amount of sadness.

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

There's no exception for the Downloads folder?  In that case, Firefox
is vulnerable to downloaded HTML documents (e.g., email attachments)
spying on all the user's other downloads (e.g., tax returns).  That
sounds like a vulnerability that should be fixed regardless of whether
we add this feature.

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

If the user is willing to "very often hit whatever button they suspect
will make the dialog go away," then the attacker can run arbitrary
code on their computer by triggering a download of an EXE and getting
the user to click through however many warnings stand between them an
running the EXE.  It's not an interesting model from a security point
of view.

Many browsers have similar warnings for running local HTML files
downloaded from the web as they do for running loaded EXEs.  For
example, compare the dialogs used for these purposes in Mac OS X.
They're identical for all intents and purposes.

My point is, either the attack you've outlined is already a problem
today or it's not a problem today, depending on which browser we
talking about on which operating system.  In either case, adding this
feature isn't really changing the security equation in any appreciable
way.

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

There's also complexity for authors, who need to set the appropriate
headers and to worry about authenticated versus unauthenticated
requests.  Worse, in some deployment scenarios, requiring CORS to use
this feature actually exposes the sites to greater risk because they
might set ACLs on these resources that are broader than needed.
Here's an example:

1) A webmail service wants to offer attachments for download.
2) The webmail service is security conscious, so it renders email
messages in a sandboxed iframe in case it's email rendering contains
an XSS hole (which is quite possible, especially with rich-text, HTML
email).
3) The webmail service wants to include links to download email
attachments using this feature.

In order for the links to work (assuming the links appear in context
in the email, as they do in Outlook, for example), the webmail
provider needs to set CORS headers that grants the sandboxed iframe
access to the attachments.  Because the sandboxed iframe runs in a
unique origin (for maximum security), the only CORS ACL that works is
"Access-Control-Allow-Origin: *".  However, that ACL allows any other
web site to read the contents of the user's attachments!  Now, maybe
you could work around that issue using unguessable URLs for the
attachments, but you'd still be exposing the contents of the
attachments if there's an XSS in the mail rendering code, a
vulnerability that would not be present if the downloads feature
wasn't coupled to CORS.

In summary, using CORS for this purpose is costly (both to
implementors and to authors), and I don't think it solves a real
security problem.

Adam