Open
Bug 1455342
Opened 7 years ago
Updated 2 years ago
Should "SaveAs" on a link send samesite cookies if embedded in a cross-site document?
Categories
(Core :: DOM: Security, defect, P3)
Core
DOM: Security
Tracking
()
NEW
People
(Reporter: dveditz, Unassigned)
References
Details
(Whiteboard: [domsecurity-backlog1])
Spinning off Bug 1455174 comment 1 as it's own issue. From Jun:
Another edge case is right click on "normal" link and click save link as. Downloaded file shows "Received Secret!"
https://test.shhnjk.com/open.php?url=https://shhnjk.azurewebsites.net/SameSite.php
Comment 1•7 years ago
|
||
This seems like a samesite-cookie specific version of bug 332676. I think we should at some point come up with a way to fix bug 332676 and that would also fix this bug. I'm not convinced it's worth fixing this bug separately (nor do I think there's a reasonable way to do that).
Reporter | ||
Comment 2•7 years ago
|
||
I don't think this has anything to do with bug 332676 which is about our file:// same-origin policy, after we download the stuff. This potentially affects what we might download.
When you right-click "Save As..." I don't see the option to save as "complete" -- it just downloads the link raw (it's not necessarily an HTML file).
[Gijs' comment does raise the issue of what we do in the "Save as (complete)" case for a page. We're displaying a page with 3rd party sub-resources that we didn't send same-site cookies to. When we save the bundle do we re-fetch those sub-resources, and if so do we forget to honor same-site cookies? If so that would be a separate bug.]
For the original issue I tend to think of "right-click save-as" as a user-initiated action. The user could have copied the URL of the link and pasted it into the address bar, and we'd send the same-site cookies in that case.
Priority: -- → P3
Whiteboard: [domsecurity-backlog1]
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•