Timeline for Security implications of download attribute
Current License: CC BY-SA 4.0
12 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jul 21, 2021 at 16:51 | history | edited | Xenos | CC BY-SA 4.0 |
fix typo in format
|
| Aug 29, 2019 at 16:55 | comment | added | user1156544 |
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.
|
|
| Aug 29, 2019 at 16:10 | comment | added | Xenos |
@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.
|
|
| Aug 29, 2019 at 15:38 | comment | added | user1156544 |
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)
|
|
| Aug 29, 2019 at 14:26 | comment | added | Xenos |
@user1156544 Be imaginative: target can be html. <a href="https://facebook/myprofile.html" download="please-reupload-me.bin"> would be unsafe with download attribute, safe without it (as you would see the origin in your URL bar).
|
|
| Aug 29, 2019 at 12:30 | comment | added | user1156544 | 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 | |
| Aug 24, 2019 at 17:35 | comment | added | Xenos | @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). | |
| Aug 23, 2019 at 16:17 | comment | added | user1156544 |
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.
|
|
| Aug 23, 2019 at 16:07 | comment | added | user1156544 | 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? | |
| Aug 23, 2019 at 16:06 | comment | added | user1156544 | 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) | |
| Aug 23, 2019 at 16:06 | comment | added | user1156544 | 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) | |
| Aug 19, 2019 at 8:03 | history | answered | Xenos | CC BY-SA 4.0 |