4 ms·

I must be missing something here... is the article suggesting by going to evil.com it somehow has access to the auth cookies of bank.com?? If that is the case t

• TheCoelacanth 5y ago
  evil.com can't see the auth cookies, but if evil.com (or anyone else) makes a request to bank.com, then that request will have the cookies for bank.com automatically included. That is precisely why the same-origin policy sharply limits what kinds of requests evil.com is allowed to send to bank.com.
  • yashap 5y ago
    Though even still, the same-origin policy isn’t strict enough to prevent CSRF. For example, your browser will still send POSTs with Content Type application/x-www-form-urlencoded cross-origin, with cookies, even if it doesn’t let you read the response. That’s why we have to add complexity with anti-forgery tokens :/ It’ll be great when you can simply count on browsers having implemented strict SameSite cookies, because that’s such a simple, elegant solution. Anti-forgery tokens are a bit of a hack.
    • danlugo92 5y ago
      Isn't it easy to just block all `application/x-www-form-urlencoded` requests?
      • yashap 5y ago
        Most sites won’t want to do this, because HTML forms are useful! Also, that’s just one example, there are plenty of exemptions to the same origin policy: https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy#cross-origin_network_access https://developer.mozilla.org/en-US/docs/Web/Security/Same-o... In practice, for now you either use anti-forgery tokens, you don’t put your auth tokens in cookies, or you use strict SameSite auth cookies AND block all traffic from browsers that don’t support them (mostly legacy browsers).