[jefftk]

They might be tracking whether I'm logged in, but since I didn't log into the site I didn't consent for them to store that state on my client. The e-Privacy directive is quite particular, and unless these cookies are "strictly necessary" to operate the sandbox they're not allowed.

[mark_story]

I believe that knowing whether or not you are logged would be part of the strictly necessary.

[shaky-carrousel]

You don't need to set a cookie to know that I'm not logged in. The lack of cookies means I'm not logged in.

[jefftk]

The way most sites do this is that absence of a cookie indicates not logged in; any reason this wouldn't work here?

[mark_story]

That's fair, not having a cookie could work for session, how would you handle CSRF protection on a login form without cookies?

[jefftk]

A CSRF vulnerability on a login form is a bit of a weird one: doesn't this require that the user has submitted their username and password to a site that isn't yours, in which case the attacker has successfully phished the user and can impersonate them or keep them on a proxy of your site?

(Spitballing: a standard way to implement CSRF protection with no cookies at all is when you generate the form you include a nonce. Then when the form is submitted you check whether it's a nonce you generated, which you do either by having stored it or generated it by hashing information you've stored. Implemented naively on a login form this would allow the attacker to fetch your page, extract the nonce, and include it in a cross-site request. But you could require it to be from the same IP. Alternatively I think you could fix this by having your login form set a custom header, which then browsers won't allow a cross-site POST for without a CORS preflight which you'd reject. But at this point I'm brainstorming and please don't take any of this very seriously!)

[shkkmo]

Why would you ever use a cookies to store a CSRF token? A CSRF token is a per request value and that's not what cookies are designed for. Generally the CSRF token is a hidden value on the login form.

[mark_story]

Cookies are used for double-submit CSRF protection pattern. One copy of the CSRF token is put into a hidden form field, and the other is in a cookie.

https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Re...

[jefftk]

In that case the cookie can at least be scoped to the login form with a Path attribute and limited to the current session, which these aren't. The cookies on https://sentry.io/auth/login/ set without user intervention are valid beyond the current browser session and two of them have durations of a year. One even has Same-Site=Lax!

(It's also not clear to me that cookies are required, if there are other technically sound options that do this without setting cookies.)

[jefftk]

If you authenticate users only via Same-Site=Strict cookies you're protected against CSRF in modern browsers: a cross-site request won't have the auth cookie.

[lloeki]

Session cookies are often encrypted by frameworks using a server side secret.

This allows storing data such as the CRSF token value to check against the one in the hidden form element or X-CSRF-Token without inserting in a DB every time someone loads up a form.

That's how e.g Rails does it by default:

https://guides.rubyonrails.org/security.html#cross-site-requ...

https://api.rubyonrails.org/classes/ActionController/Request...

Note that to prevent session fixation, the session ought to be reset on a successful login (and logout), so it would require additional code to perform tracking across a successful login.

https://guides.rubyonrails.org/security.html#session-fixatio...

Session cookies are also used for Rails flash messages, commonly used to display errors in forms (including login forms), which often do HTTP redirects to GET routes in their non-GET controller actions.

https://api.rubyonrails.org/classes/ActionDispatch/Flash.htm...

https://api.rubyonrails.org/classes/ActionDispatch/Flash/Req...

https://stackoverflow.com/questions/24877244/rails-is-the-fl...

The underlying subtext is that these session cookies can be a necessity of securing the provided service, and thus can fall under valid "strictly necessary" usage, as long as they are not abused for tracking (by default nothing in the session cookie is stored nor logged anywhere)

[giancarlostoro]

It might also just be done by whatever underlying web framework they use without them realizing. Like maybe a call to a method that checks if you are authenticated creates those cookies deep in some library they have less control / ownership of. Just taking a guess.

[jefftk]

Possibly! But then they need to choose: take full control of their stack to where they can ensure it doesn't set unnecessary cookies, or use cookie banners.

[giancarlostoro]

I am certain if I am in any way right they could overprice the behavior, but im making a wild guess. Or maybe they missed a page.