[gear] Make csrf cookie samesite=strict

[daniel-goldstein]

Currently, the _csrf cookie is made available to all subdomains of .hail.is. This means that if I first visit batch.hail.is I get a _csrf cookie set for .hail.is. That cookie is then reused if I visit ci.hail.is. Even more awkward, the same value of the cookie will get reused if I then visit batch.azure.hail.is. This isn't that big of a deal, these can all be considered part of the same application that the hail team delivers and secures, but it is very little work to set stricter bounds on where this cookie is sent. By removing the domain attribute and using samesite='strict', the cookie's domain will be set by the browser to the domain of the request whose response included the Set-Cookie header, e.g. batch.hail.is or internal.hail.is. Strict mode then ensures that the cookie will only be sent to that exact domain, meaning that each application is guaranteed to receive the _csrf token that it itself delivered, and a _csrf token from CI cannot be used to take actions against Batch.

This should not have an adverse impact on existing users' browser sessions. In render_template we preserve the value of an existing _csrf cookie so this change should do the following:

• Logged in user visits a page with an existing widely scoped (.hail.is) _csrf cookie
• The server returns a Set-Cookie header with a new _csrf cookie for strictly the batch.hail.is domain but with the same token value as the original _csrf cookie
• The user now has two cookies and the browser could send either one on a given request, but it does not matter because they have the same value
• If the user logs out and back in, their old widely scoped cookie will be cleared and they only get the strict cookie from now on.

[danking]

Hmm. I feel like I'm now a bit confused about our previous conversation.

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie#strict

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie#domaindomain-value

It sounds like Strict is necessary for CSRF to work: otherwise I could put this on an evil website (excuse my totally invented HTML, I didn't bother to look up the right syntax and attribute names) and trick people into cancelling their batches, right?

<form method="POST" url="https://batch.hail.is/batches/123/cancel">
<button>
</form>

In particular, do we have any CSRF protection at all right now?

---

I agree we should remove the domain attribute:

Only the current domain can be set as the value, or a domain of a higher order, unless it is a public suffix. Setting the domain will make the cookie available to it, as well as to all its subdomains.

If omitted, this attribute defaults to the host of the current document URL, not including subdomains.

[daniel-goldstein]

The server compares the cookie value to a value in the request (hidden value in the form), which means that in order to create a malicious form the evil site would need to know the value of the cookie which it can't because it is not the same origin (assuming they have not achieved the ability to set a cookie on our domain in which case signing our cookies would help)

[danking]

Sounds good.