search

aspnet / AspNetKatana

Microsoft's OWIN implementation, the Katana project
Apache License 2.0
959 stars 331 forks source link

CHIPS: Need Partitioned flag for CookieOptions #531

Open explunit opened 2 months ago

explunit commented 2 months ago

Microsoft.Owin.CookieOptions lacks the Partitioned flag needed to support CHIPS: https://developers.google.com/privacy-sandbox/blog/cookie-countdown-2023oct

blowdart commented 2 months ago

This project is not in active development.

We make only critical security and compatibility fixes here.

All feature development has moved to ASP.NET Core which already has an issue for this - https://github.com/dotnet/aspnetcore/issues/53224

jeffshirley commented 2 months ago

I’d argue that this qualifies as a critical compatibility issue.

explunit commented 2 months ago

For anybody else who finds this issue later...

It's not as simple as a middleware that intercepts outgoing headers and adds ; Partitioned to certain Set-Cookie statements. That's only half the solution.

Regular cookie expiry from OWIN (e.g. owinContext.Response.Cookies.Delete( cookieName ) does not use Secure, SameSite, etc. even if the original cookie was created with it, for example:

Let's say the original cookie was created like this: Set-Cookie: MyCookieName=somevalue; path=/foo; HttpOnly; Secure; SameSite=None

The call to owinContext.Response.Cookies.Delete( cookieName ) will generate a response header like this: Set-Cookie: MyCookieName=; path=/foo; expires=Thu, 01-Jan-1970 00:00:00 GMT

This apparently works fine for clearing non-partitioned cookies, but not for partitioned ones. For those we have to do more like: Set-Cookie: MyCookieName=; path=/foo; expires=Thu, 01-Jan-1970 00:00:00 GMT; Secure; SameSite=None; Partitioned

But of course we have no way of knowing from the server side which variant the browser has in storage, so we have to send both kinds of Set-Cookie for the same cookie name. And since "session" cookies live forever these days, we have to assume the old ones are hanging around out there.

Also, I agree with @jeffshirley -- when a browser with the majority of the web traffic switches their standard, it's a critical compatibility issue.