1455174 - SameSite cookie sent via Drag & Drop

Status: NEW

(Core :: DOM: Security, defect, P3)

Description

[Jun (Request needinfo for comment, I ignore other updates)]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.117 Safari/537.36

Steps to reproduce:

1. Go to https://shhnjk.azurewebsites.net/SameSite.php (Sets SameSite cookie)
2. Go to https://test.shhnjk.com/open_drop.html
3. Click the button.
4. Drag the "Drag" link and Drop to previous tab's body


Actual results:

SameSite Strict cookie sent


Expected results:

Maybe it shouldn't send SameSite strict cookie. This have nothing to do with about:blank (it's just there to confuse user). Note that dropping to URL bar won't send cookie. It only happens when link is dropped to the body. 

PS:
Dan implicitly said I need to find edgier edge case... (https://bugzilla.mozilla.org/show_bug.cgi?id=1454027#c13)

I'm even not sure what spec says in this case. This is edgier edge case (in other words, fix of bug 1454027 was really good).

Comment 1

[Jun (Request needinfo for comment, I ignore other updates)]

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 2

[Christoph Kerschbaumer [:ckerschb}]

(In reply to Jun from comment #0)
> PS:
> Dan implicitly said I need to find edgier edge case...
> (https://bugzilla.mozilla.org/show_bug.cgi?id=1454027#c13)

Thanks for looking so closely and setting up those proof of concept test pages!
 
> I'm even not sure what spec says in this case. This is edgier edge case

This is really an edge case and besides the fact that I am also not sure what the spec says, this one is really hard to fix in Firefox. Let's look at the arguments to determine whether we treat something as foreign:

  channelURI: https://shhnjk.azurewebsites.net/SameSite.php
  hostURI: 
  contentType: 6
  isInThirdPartyContext: no
  triggeringPrincipal: SystemPrincipal

The problem is that we treat drag&drop as a 'user initiated' action and hence we use the SystemPrincipal as the triggeringPrincipal. In other words, we can't reliably distinguish if something is typed into the address bar or dragged. To me that feels somehow very similar and probably we could mark this bug as INVALID.

Jonathan is working on providing the correct principal for top-level loads over in Bug 1333030, but I am not even sure if we are going to update that case. Obviously we could use the contentPrincipal of the other page as the triggeringPrincipal, but that's a discussion for a different day.

Comment 3

[Daniel Veditz [:dveditz]]

(In reply to Jun from comment #0)
> PS: Dan implicitly said I need to find edgier edge case...

It was meant as a compliment about your ability to find things we missed entirely. Was not meant as an obligation!

Comment 4

[Jun (Request needinfo for comment, I ignore other updates)]

(In reply to Daniel Veditz [:dveditz] from comment #3)
> (In reply to Jun from comment #0)
> > PS: Dan implicitly said I need to find edgier edge case...
> 
> It was meant as a compliment about your ability to find things we missed
> entirely. Was not meant as an obligation!

Hahaha, I was just joking :) Thanks for your word!

Comment 5

[Daniel Veditz [:dveditz]]

(In reply to Christoph Kerschbaumer [:ckerschb] from comment #2)
> The problem is that we treat drag&drop as a 'user initiated' action and hence
> we use the SystemPrincipal as the triggeringPrincipal. In other words, we can't
> reliably distinguish if something is typed into the address bar or dragged.

And yet somehow we do distinguish because when dropped on the address bar we don't set the cookie. I find this kind of odd because if the user had copied the link and then pasted into the URL bar we would have sent the cookie.

If the two drops were consistent I could argue either way:
 * Send the cookie: it's a user initiated action
 * Don't send the cookie: it could be a trap (but in this
   case the determinant should be the site that started the
   drag, not the drop target. In Jun's testcase they're the
   same, but they might not be).

The two targets behaving differently is harder to justify, but would make more sense if things were reversed!

I'm leaning toward the "user-initiated action" POV and that the bug here is that dropping into the URL bar does NOT send the cookie. Chrome also treats it that way and sends the cookie in both cases.

Our inconsistency is a bug, but whichever way we decide is more about spec ambiguity than a security issue.

Mike: any thoughts here? Is Chrome's drag and drop behavior carefully considered and intentional, or just the way it happened to work out?

Comment 6

[Daniel Veditz [:dveditz]]

I created bug 1455342 to cover the issue in comment 1. No drag-and-drop fix could possibly change that behavior and it's likely to get lost here.

Comment 7

[:Gijs (he/him)]

FWIW, we use the principal associated with the drag/drop for the load that that drop triggers to avoid situations where a webpage can include links to which it is not allowed to link, and where dropping those links in the urlbar would navigate to those links... I don't really see a super-reasonable way to fix this and not "unfix" that (ie the navigation restriction) without using 1 principal for 1 security check and 1 principal for another, which seems super awful. :-\

Comment 8

[BugBot [:suhaib / :marco/ :calixte]]

Clear a needinfo that is pending on an inactive user.

Inactive users most likely will not respond; if the missing information is essential and cannot be collected another way, the bug maybe should be closed as INCOMPLETE.

For more information, please visit auto_nag documentation.