Re: [whatwg] Priority between <a download> and content-disposition

On Wed, May 8, 2013 at 9:43 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> On 5/8/13 6:53 AM, Gordon P. Hemsley wrote:
>>
>> It's not clear to me which of the two factors you take issue with.
>
>
> The question of which filename takes priority.
>
>
>> The second sentence very clearly suggests
>> that "A.txt" would be the filename presented to the user by default in
>> the save dialog.
>
>
> No, it suggests that A.txt is what the page author recommends.
>
> If, at the same time, B.txt is what the server author recommends, what
> should happen?

I still think @download takes priority.

The Content-Disposition header says, "Nevermind what filename the URL
shows; this is really file B.txt."

The @download attribute says, "Nevermind what filename this link would
normally be; let's just consider it A.txt."

>>> There is if you allow cross-origin @download.
>>>
>>> There is if you allow untrusted markup on your server and don't sanitize
>>> away @download (should it be sanitized away?  Unclear).
>>
>>
>> I'm still not seeing what the problem is. All this does is make the
>> browser treat the link as if the user followed it and then went File >
>> Save Page As....
>
>
> No, because in that case the browser will definitely use the
> Content-Disposition filename, not the one from @download.

OK, technically, the way I phrased it, yes. But what I meant was that
it rolls a bunch of steps into one, telling the browser that the link
should be downloaded and named per suggestion.

>> What are the security concerns, cross-origin or otherwise?
>
>
> One concern is being able to do this:
>
>   <a download="known-location.pdf"
>      href="http://some-bank/statement.pdf">
>
> cross-site and combining it with something that lets you read
> known-location.pdf (e.g. a file://-specific privacy hole that only applies
> to some filenames, or an <input type=file> that the user has already filled
> in).

That seems like quite a sophisticated attack that relies on a lot of
things falling into place all at once. I'm not sure that should block
the use of the attribute in and of itself.

> Another concern is if you upload a file to an image-sharing site, but it
> happens to be a Windows executable.  Then you link to it with:
>
>   <a download="something.exe" href="http://image-sharing-site/whatever">
>
> and wait for the user to download and double-click.  This relies on the user
> thinking the file came from image-sharing-site so must be an image.  UAs may
> do mitigations here by changing the suggested filename, of course.

Then I think it is the responsibility of the UA to sniff the file and
protect the user from such attempts to mislead.

At the very least, the download UI could specify the actual type of
the file that is being downloaded. (More on how to protect users who
don't read that below.)

> Generally, allowing this sort of thing opens up several new phishing nd
> social engineering attack vectors, and it's not clear that we want that.

There is a price to freedom, as they say. We shouldn't let a few
rotten apples spoil the whole bunch.

>> Well, what I should have said is, there is no content sniffing beyond
>> what is already done for regular page saves. (The UI can show the MIME
>> type or format of the file in the download box, as it would for any
>> file it doesn't handle natively.)
>
>
> It can, and users routinely ignore that.
>
>
>> Ah, I admit, I'm a bit biased towards Mac in that regard. It's been a
>> while since I used Windows. But I'd be surprised to find out that the
>> browser (Firefox, in the case I have in mind) changes the extension in
>> the suggested filename (e.g. "example.php" for an HTML file) on
>> Windows but not on Mac
>
>
> It sure used to in some cases, partially in concert with the Windows
> filepicker.  See the (scant) documention for lpstrDefExt at
> http://msdn.microsoft.com/en-us/library/windows/desktop/ms646839%28v=vs.85%29.aspx
> and I suggest actually doing some experimentation across the different save
> variants (save image, save link as, save page as, click on something with
> content-disposition:attacment) on several OSes to see the behavior.  There
> is certainly a good bit of code in the various file-saving codepaths in
> Firefox that attempts to ensure extensions match MIME types, to forbid
> saving things with certain extensions, etc.
>
> Also note that Chrome will change extensions on at least @download filenames
> to match the MIME type; I haven't experimented in detail with its behavior
> for other cases.  And I haven't experimented much with other browsers in
> this area, though I expect all have some interesting behavior.
>
> -Boris

I'm not sure I have the resources to do extensive real-world testing
of this (and that documentation suggests it has been superseded in
more modern OSes), but I don't think it would be unreasonable for the
UA to override or augment the filename suggested by the @download
attribute it if determines that it would not be in the best interest
of the user to use the suggested filename unchanged. Note that the
spec also says: "There are no restrictions on allowed values, but
authors are cautioned that most file systems have limitations with
regard to what punctuation is supported in file names, and user agents
are likely to adjust file names accordingly." By extension of that
notion, we can probably assume that UAs are also at liberty to adjust
filenames to protect users from malicious authors.

I know that WebKit has a list of file extensions associated with some
MIME types it keeps track of (and Gecko probably does, too). I'd be
happy to update mimesniff to include suggested file extensions
alongside the existing MIME types, if you feel that would be
beneficial.

--
Gordon P. Hemsley
me@gphemsley.org
http://gphemsley.org/ • http://gphemsley.org/blog/

Received on Wednesday, 8 May 2013 14:46:05 UTC