[HN Gopher] Exploring the SameSite cookie attribute for preventi...
___________________________________________________________________
Exploring the SameSite cookie attribute for preventing CSRF
Author : simonw
Score : 33 points
Date : 2021-08-03 21:11 UTC (3 days ago)
(HTM) web link (simonwillison.net)
(TXT) w3m dump (simonwillison.net)
| krinchan wrote:
| The Safari "bug" is a new setting that's turned on by default:
| "Prevent cross-site tracking". It treats all cookies as
| SameSite=Lax, even cookies with SameSite=None.
|
| Source: Currently dealing with fallout from "Single Log Out"
| being "broken" on Safari because it depends on SameSite=None
| cookies being sent along with GET request for <img> tags. (Note:
| I warned them years ago this would happen eventually and that
| this was a bad way to manage session revocation across domains.)
| bojan wrote:
| What would be the good way to do it?
| krinchan wrote:
| Honestly there's only one proper way to do it cross domain:
| Your Single Sign-On mechanism needs to pass a session
| identifier. Whether that's via a claim on an OAuth2 token (or
| an OIDC ID token) or an attribute in a SAML assertion, it
| needs to represent a particular session your IdP holds with
| the user agent.
|
| Applications leveraging the SSO solution must check that the
| session identifier is still valid via some sort of API call.
|
| When a client logs out and hits your SLO process, the session
| ID is marked as revoked. Queries to the API for that session
| ID will reveal it is revoked and all other interested parties
| will now know that the session is no longer valid and can
| take action.
|
| Practically, this usually means checking the API on every
| page render or in the case of an SPA, every time a request is
| made. If you are willing to accept a delay in the log out
| propagating to other domains, you can cut back to every X
| requests or a particular interval of time, say 5 minutes.
| colinclerk wrote:
| > Since it's common for subdomains to host other applications
| that may have their own security concerns, ditching CSRF tokens
| for Lax cookies may not be a wise step!
|
| This is a really fantastic point, and it applies to CORS as well.
|
| It's common to ditch CSRF tokens when CORS is configured, which
| is perfectly legitimate. But reflecting the Origin in Access-
| Control-Allow-Origin is dangerous if you have subdomains hosted
| by a third party AND are using `credentials: "include"`.
| simonw wrote:
| I was inspired to look into this by the OkCupid article from the
| other day: https://news.ycombinator.com/item?id=28039631
| colinclerk wrote:
| > The trick is to only allow logins from users that are carrying
| at least one cookie which you have set in that way--since you
| know that those cookies could not have been sent if the user
| originated in a form on another site.
|
| It's crazy to me that HTTP servers need to rely on tricks like
| this to understand the context of a request.
|
| At a minimum, it would be nice if `Origin` was sent with all
| requests from browsers, not just cross-origin XHR requests.
| edoceo wrote:
| It's not crazy and it's not a trick.
|
| The Context: that's an app-layer concern, not a protocol layer
| concern.
| simonw wrote:
| As far as I can tell Origin: is also sent by regular HTTP POST
| requests these days.
|
| I added a note about Origin to the post.
| ozim wrote:
| This is s problem with stateless approach for HTTP protocol.
| When it was conceived it was not a problem at all.
|
| Maybe we need a statefull protocol for web-apps -- where
| stateless is still good for web-pages.
|
| Now we have statefull web-apps based on stateless protocol -
| what could go wrong?
|
| Developers making mistakes, just like managed vs unmanaged
| memory.
___________________________________________________________________
(page generated 2021-08-06 23:01 UTC)