>Needs Mike to decide what should happen on cross-origin downloads.
I meant *cross-site* downloads. Since I'm talking about SameSite cookie.

Thanks for the report.

This report does not contain enough detail for me to know whether this is a request for a new security feature (which would be type=bug, component=security) or an actual issue that affects user security.

Sounds like this is already something that has been discussed with mike so assigning to him to triage and, if appropriate, remove from security queue.

>This report does not contain enough detail for me to know whether this is a
>request for a new security feature (which would be type=bug, component=security)
>or an actual issue that affects user security.
:( Let me try again...
Cross-origin <a download> blocking (https://www.chromestatus.com/feature/4969697975992320) is a security feature in Chrome (per Blink component), which aims to block attacks which takes advantage of an ability to force download of cross-origin content which is not intented to be downloaded.

One of those attacks is Reflected File Download, which abuses user's trust on certain domain and ability for attacker to host or inject attacker controlled payload to trusted domain.

Real world example:
The domain http://dl.profile.line.naver.jp is owned by Line Corp and is trusted by user. But attacker has an ability to upload profile picture to this domain. Abusing profile picture and Cross-origin <a download> blocking bypass, attacker can craft an image which is also valid as HTML, and force download this picture as an HTML file so that victim opens it up (because it came from trusted domain, right?).

PoC:
https://test.shhnjk.com/force_rfd.html


SameSite cookie part:
SameSite cookie spec is unclear (at least for me) on whether download should be considered as a top-level navigation or not. If it shouldn't be considered as a top-level navigation, then this is a SameSite Lax cookie bypass. But since it's unclear to me, I need Mike's opinion on this (where are you Mike) :)

PS
I love precise report so I always try to make my report as small as possible.

+Jochen for the `<a download>` bit, as he's been pushing on that recently. I don't know what the expectations are for redirects in that chain.

For the `SameSite` bit, we did intentionally chose to send `SameSite=Lax` cookies along for the ride if the download is triggered from the top-level document (because downloads ~are navigations that end up not navigating, and it seemed likely that folks might have separate servers for downloads, potentially gated on auth cookies). That assumption may be out-of-date now that Jochen's been poking at the underlying mechanics of downloads.

mkwst@, can we convert this bug to SameSite cookie bug instead?

>For the `SameSite` bit, we did intentionally chose to send `SameSite=Lax`
>cookies along for the ride if the download is triggered from the 
>top-level document

SameSite Lax cookie is sent even if download is triggered from frames.

Repro steps:
1. Go to https://test.shhnjk.com/SameSite.php (this sets SameSite cookies)
2. Now go to https://shhnjk.azurewebsites.net/iframer.php?url=download_redirect.html

Observe that downloaded file contains "Received Lax!".

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot