4 ms·

I believe this also requires that OKCupid has not set the 'SameSite=lax' attribute on their cookies, which is good practice as well; the browser won't send the

I believe this also requires that OKCupid has not set the 'SameSite=lax' attribute on their cookies, which is good practice as well; the browser won't send the user's cookies on cross-origin POST, PUT, PATCH, or DELETE requests when this attribute is set. So this exploit is really the confluence of failing to follow 2 standard security practices, as well as another unfortunate configuration quirk: - Failing to set SameSite=lax on their session cookie attribute - Not using a CSRF token to authenticate on unsafe HTTP actions - Not checking the content-type of API requests (though I'm not sure to what extent this is considered bad practice)

simonw 5y ago
I thought most modern browsers behave as if SameSite=Lax automatically these days. Were OkCupid deliberately setting SameSite=None on their cookies?
- k__ 5y ago
  Wasn't lax just for static assets like images that are linked in external HTML?
  - simonw 5y ago
    Yes it was - "... are sent when a user is navigating to the origin site" https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie/SameSite#lax https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Se...
    - simonw 5y ago
      ... but in my experiments now I can't find a way to cause a SafeSite=Lax cookie to be sent from a POST request starting on another site: https://simonw.github.io/samesite-lax-demo/ https://simonw.github.io/samesite-lax-demo/
      - hmsimha 5y ago
        Defaulting to SameSite=lax is a (relatively) recent development, as per the doc you linked. Yes, I don't think cookies with SameSite=Lax will be sent to a cross-domain host when the request type is a POST, even when the navigation is top-level. Though they will for GET and HEAD. Defaulting to SameSite=Lax has only been in Chrome since Feb of last year, and in Edge since October of last year. It has yet to land in Firefox or Safari.