14

The download attribute in an a element tells the browser to force the download of a file that otherwise would be interpreted by the browser. This is very convenient, since often users want to download a (e.g. jpg) file instead of having the browser visualise it.

<a href="link.jpg" download="myfile.jpg">Click here to download</a>

Some browsers block the download attribute when the file is not accessed by the same protocol, on the same host and over the same port. This to me sounds a bit pointless while it breaks a lot of good use cases to prevent something that can be circumvent in other ways.

What are the security implications that browsers try to protect? Any useful real example?

user1156544
  • 456
  • 3
  • 14
  • You can also use the `Content-Disposition` header for cross origin download. This is a better way of doing so, as you cannot set this header without owning the origin you're downloading from, while anyone on the internet could make a link with a `download` attribute. – Xenos Aug 29 '19 at 14:27
  • This is what the W3C suggests, however this is not always possible without nasty configuration - imagine a system where both options (standard and forced download) are desired – user1156544 Aug 29 '19 at 15:39

4 Answers4

3

This is actually described in the HTML living spec:

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.

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.

The scenario, described here is:

  • You are on my onlineexcel.attacker.com website that allows to make Excel files
  • You click a link in there, stating like "download your excel sheet". This is actually a link that downloads your facebook profile, say <a href="https://facebook/myprofile/" download="your-sheet-from-onlineexcel.xlsx">
  • Later on, you wish to restore your excel sheet/load it online, so you click the upload button of my onlineexcel.attacker.com, say <input type="file"/> and you select the file that you thought was from onlineexcel.attacker.com (because it was a link in there)
  • You actually have uploaded your FB profile to my website

So the hazard here is that user do not know whether link is downloaded from the same origin or not.

That's why spec advises:

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.

But I suppose that since this is a bit difficult to properly tell to Mom-like users, then browsers preferred to block such downloads.

Xenos
  • 1,331
  • 8
  • 16
  • Thank you for the example. I think it is a valid attack as a whole, although I actually find it a bit unrelated to the download attribute (remember it is a "force download" instead of a "browser rendering") and it assumes a lot of things. In my opinion it is NOT VALID, and I'll explain why. If your attack is considered valid for the download attribute, then we should consider this attack valid too: a user goes to the page, which says "we have all your FB data, send us $2k or we will publish them. If you need a proof, click here". (cont) – user1156544 Aug 23 '19 at 16:06
  • Then the user checks the link, which renders the personal data in the browser. The user sends the money to avoid trouble. This could happen now without the download attribute. Moreover, what if the file from FB is in a format that the browser cannot render? It WILL BE downloaded, even without the download attribute, so the attack will happen - would you find sensitive to forbid all Web links to different domains? (cont) – user1156544 Aug 23 '19 at 16:06
  • No, it makes more sense to actually inform the user that the document is being downloaded from another domain rather than breaking functionality. So you see your example is not a "security issue" of the down attrribute, it can happen equally without using the download attribute. This is the main reason why I don't consider this attack valid, because it is not specific for the download attribute... As all other attacks I have seen, it is specific for the Web design itself. No links to external Websites are forbidden, why to do so with the download attribute? – user1156544 Aug 23 '19 at 16:07
  • **TLDR;** Your actual example, using an Excel file, works EQUALLY both with the `download` attribute and without it. So it is NOT a valid specific security issue of the `download` attribute, but of the Web design. – user1156544 Aug 23 '19 at 16:17
  • @user1156544 No, your verbose counter-example is not valid as the user will see it's FB's origin in their URL bar when they click the non-downloading link. The example *is* a (the) security issue of download attrribute, no matter "your" thoughts. Mitigation by disallowance is valid and safe(st). If you disagree with this implementation, I invite you to open an issue to browsers and suggest them something safer (if there is). – Xenos Aug 24 '19 at 17:35
  • The main purpose of the download att is to tell the browser to download a file instead of rendering itself. Download is also the default behaviour (try it yourself) when the file type cannot be rendered. Disallowance is safest in every single case- if you disable all scripts and external links in Web you will get a valid and safer Web. But the issue is if breaking this functionality makes sense, and I have not found a situation where it does. Your example works equally in both cases. And the FB origin is seen in both cases, so you can't have a 'savvy' user in my case and not in yours – user1156544 Aug 29 '19 at 12:30
  • @user1156544 Be imaginative: target can be html. `` would be unsafe with download attribute, safe without it (as you would see the origin in your URL bar). – Xenos Aug 29 '19 at 14:26
  • Of course, but this is nothing to do with the download attribute.... The thing that marks if it is rendered or not by the browser is defined by `href`, not by `download`, so it depends on the server (FB in this case) – user1156544 Aug 29 '19 at 15:38
  • @user1156544 No, what marks the document as "render or download" is the `download` attribute. I suggest you to open up a tchat if you have trouble getting the point here, this comment wall went too long. – Xenos Aug 29 '19 at 16:10
  • 1
    Agree, what I said is that the browser takes the file type from `href`, not from the `download` value, so an attacker cannot forge the file type as he wishes, only the local name. So what you mention can happen with hundreds of file types that cannot be rendered by browsers. So it seems to me you are saying that this is a problem of lack of browser feedback to the user (which I agree), not a security issue of the download attr. – user1156544 Aug 29 '19 at 16:55
-1

It is important not only in the a attribute but to others also. The reason to this is because it is looking to see if it comes from the origin which means the same host and the same port that is your website.

if in anyway you are vulnerable to an attack that uses your site it will block it. This may be useful if an attacker uses e.g. XSS to redirect and make a user download a malicious file. Thngs such as :

  • Malicious PDF file

  • Malware

    As an example :

www.super123site.com/hello.php?mesg=hello+world

Comes from same port as your site...

Attack Scenario :

www.super123site.com/hello.php?mesg=<script> window.location.replace(www.malware.com:8099/maliciousPdf.pdf)</script>

Diferent host, diferent ports, Blocked...

  • 1
    What does this have to do with the fact that you want to force a download? The problem you describe is a potential problem in the Web design, not over the fact you want to "force" a download instead of letting the browser interpret it. You are describing an XSS vulnerability, which is a different thing and, as you said, has nothing to do with the `download` attribute – user1156544 Sep 20 '18 at 10:32
  • If you have an XSS, you probably already have better ways of exploiting it (but indeed, maybe it's why browsers block that? I would have expect sources to consider this answer as "good") – Xenos Aug 19 '19 at 07:51
-1

I can think of one potential security issue.

If I create an HTML file and you open it on the web page, it operates under the same origin restrictions as everything else.

If I can force you to download the HTML file, double clicking that file, or opening it from your browser, now has an origin of your local machine! Suddenly the potential for malice is much greater.

Corner cases

Corner cases The behavior of same-origin checks and related mechanisms is not well-defined in a number of corner cases such as for pseudo-protocols that do not have a clearly defined host name or port associated with their URLs (file:, data:, etc.). This historically caused a fair number of security problems, such as the generally undesirable ability of any locally stored HTML file to access all other files on the disk, or communicate with any site on the Internet.

Exploiting a Microsoft Edge Vulnerability to Steal Files

Is This a Realistic Threat? Or Is It a Theoretical Scenario?

Do you think an attacker could somehow convince a potential victim to download a HTML file and execute it?

Due to the existence of another attack vector, it turns out that this is not merely a theoretical scenario.

user10216038
  • 7,552
  • 2
  • 16
  • 19
-1

Some browsers block the download attribute when the file is not accessed by the same protocol, on the same host and over the same port.

This is called SOP (Same Origin Policy).

This to me sounds a bit pointless while it breaks a lot of good use cases to prevent something that can be circumvented in other ways.

Same Origin Policy is not pointless. Please refer Why is the same origin policy so important?

What are the security implications that browsers try to protect?

How about a zero-day vulnerability which allows an attacker to embed a link with download attribute in your web site which downloads malicious files from attackers domain?

One important point: Although HTTP(s) URLs need to be in the same-origin, blob: URLs and data: URLs are allowed so that content generated by JavaScript, such as pictures created in an image-editor Web app, can be downloaded.

schroeder
  • 123,438
  • 55
  • 284
  • 319
Arpit Rohela
  • 573
  • 2
  • 12
  • 1
    Ofc `Same Origin` is important, but this has nothing to do with the `download` attribute. The 0-day attack you describe works equally without the `download` attribute. Or is your browser attempting to render a `PE` .exe file? Or an `ELF` file? No, the browser will download it in the same way with or without the `download` attribute. Moreover, if the malicious file was a PDF, you could even change the `MIME` type or use other configuration tricks to force the browser to download it. – user1156544 Sep 25 '20 at 16:47