1454279 - Anchor element's "download" attribute should trigger downloading for not-same-origin links

Status: UNCONFIRMED

(Core :: DOM: Core & HTML, defect, P5)

Description

[Vincent MONIER]

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:59.0) Gecko/20100101 Firefox/59.0
Build ID: 20180323154952

Steps to reproduce:

Put a "download" attribute to an anchor element "a" that links to statis.domain.com from a page in dynamic.domain.com 


Actual results:

Link is followed like "download" wasn't there


Expected results:

Doc https://developer.mozilla.org/en-US/docs/Web/HTML/Element/a says "This attribute only works for same-origin URLs."

Why applying such restriction? I saw nothing about that in WHATWG specs ( https://html.spec.whatwg.org/multipage/links.html#attr-hyperlink-download ) and a lot of websites actually have one domain for usual pages ("dynamic" domain) and one for static resources (like images, zips, jars, etc... in short: all stuff that is intended to be downloaded).

So why the restriction?

Comment 1

[ovidiu boca[:Ovidiu]]

Can you please retest this issue with FF Nightly? You can download it from here: https://nightly.mozilla.org/

Comment 2

[Vincent MONIER]

Same issue with Firefox Nightly from yesterday.

I've attached a sample using 127.0.0.1 and localhost origins to show the issue

Comment 3

[Vincent MONIER]

Attachment: Showcase (127.0.0.1 and localhost origins)

Comment 4

[(no longer active)]

This behavior is per spec, see step 5 under https://html.spec.whatwg.org/multipage/links.html#as-a-download.  I tested Chrome which seems to have the same behavior on the test page you submitted.  WONTFIXing based on this.  If you'd like to get the spec changed, please file an issue against the HTML spec: https://github.com/whatwg/html/issues/new

Comment 5

[Vincent MONIER]

I'll follow the algorithm then:


5 If there is no interface origin, then let trusted operation be true. Otherwise, let trusted operation be true if resource origin is the same origin as interface origin, and false otherwise.

so "trusted operation = false" (that's all 5 implies)

6 is no applicable because "trusted operation == false"
7 is not applicable because anchor had a download attribute that is not empty
8 puts "content-of-download.attr" as the "proposed filename"
9 is not applicable because "trusted operation == false"
10 is not applicable since there is no "Content-Disposition: attachment" header to the to-download resource
11 is not applicable because there is a proposed file name

So we end up in step 12:
Act in a user-agent-defined manner to safeguard the user from a potentially hostile cross-origin download. If the download is not to be aborted, then let filename be set to the user's preferred file name or to a file name selected by the user agent, and jump to the step labeled sanitize below.

So the download must occur, but using a file name that is either Firefox-set or user-defined.


The afterward warning:
If the algorithm reaches this step, then a download was begun from a different origin than the resource being downloaded, and the origin did not mark the file as suitable for downloading, and the download was not initiated by the user. This could be because a download attribute was used to trigger the download, or because the resource in question is not of a type that the user agent supports. => It's totally the case here

This could be dangerous, because, for instance, a hostile server could be trying to get a user to unknowingly download private information and then re-upload it to the hostile server, by tricking the user into thinking the data is from the hostile server. => Why not, it makes sense

Thus, it is in the user's interests that the user be somehow notified that the resource in question comes from quite a different source, and to prevent confusion, any suggested file name from the potentially hostile interface origin should be ignored. => This somehow says that the download must occur, but the user should be warned that it's not a download from the original website



So IMO, there's nothing in the spec that says the download should not occur. Therefore, there's no ticket to open to WHATWG to change the spec (since it states that download occurs but it restricts the suggested file name and advise browser to warn user about the cross origin thing).

I'll reopen the ticket for that, but you might still re-close it no for the spec reason, but maybe for "we don't wanna do that since it looks like Chrome doesn't do that"

Comment 6

[(no longer active)]

(I'm only triaging this to determine the priority of this bug, for whatever it's worth.  Arguing over this with me is of no use, since I'm not making any final decisions here.)

The security concerns here are real, since the browser has no way to distinguish between a malicious website and an innocent website.  It seems that you're arguing for the non-malicious use case and dismissing the importance of handling the malicious case.

Anyway, I'm going to assign this the lowest priority for triage purposes and move on, even though I still think this is WONTFIX with the information currently presented on the bug.

Comment 7

[Vincent MONIER]

No problem, I totally get and agree that the safest is the current Firefox & Chrome algorithm, but if I'm sticking to the spec, the algorithm is wrong.

It's not a big issue actually, because there are safer and more legit ways of doing the download (Content Disposition HTTP header), so you're right about lowering the priority, it's not a main task to focus on.

Still, IMO, if this is considered as "WONTFIX", then Firefox should open up a ticket to the spec team, stating that the algorithm they defined might be a bit unsafe. Or this might be "WONTFIX because we won't follow the spec on that point".