2

Pardon me if I am wrong, however, I am looking for an answer for my understanding that isn't the concerns regarding CSRF solved by both Samesite cookie and Same-Origin-Policy effectively? Then why is the need for 2 different things?

The basic difference which I can recollect:

Same-Origin-Policy (SOP): Is a policy set by the browser to protect a user from not letting it read the contents of another site unless the origin is same or CORS is implemented effectively

Samesite Cookie: On the other hand a job done by a server to mark a cookie to be strict or laxed as per their requirement

Is it just this? is there really a good reason behind having two different ways to prevent CSRF attacks?

Improve this question

1 Answer 1

Reset to default
9

The Same-Origin-Policy does not prevent CSRF attacks. It does not prevent the request from being send and it does not prevent site specific credentials (i.e. session cookie) to be attached to the request. It only prevents cross-origin reading, not cross-origin writing. Thus it is possible to send a fully authenticated request (i.e. with session cookie implicitly attached) cross-site which allows an attacker to do an authorized action on the server side even though the attacker cannot directly get the result of the action (i.e. read the response).

Same-Site cookies mitigate this problem with an additional restriction when a cookie will be implicitly attached to a request. Without same-site property it will be attached to all requests which includes cross-site requests. With same-site property it will no longer be attached to cross-site requests. Thus it is still possible to write cross-site, but not with cookie based authentication information implicitly attached.

Improve this answer
9
  • Great, that helps me to clear my thought process. So effectively it is the read action which is blocked by SOP, not the POST or write actions wherein if an attacker gets a hold of a cookie assuming by XXS then they could make a POST request from cross site. Is my understanding correct ? (Thus same site cookie helps)
    – Jiger Jain
    Feb 18, 2020 at 2:22
  • 1
    @JigerJain: yes, SOP just prevents the read and same-site cookie prevents attaching the cookie to the write.
    – Steffen Ullrich
    Feb 18, 2020 at 5:40
  • @JigerJain "wherein if an attacker gets a hold of a cookie assuming by XXS" The attacker doesn't necessarily need to get hold of a cookie in order to send a POST request containing that cookie. The browser attaches cookies to requests automatically, so the attacker can just send a POST request to the target site and the browser will attach the cookie to that request automatically unless the cookie is marked as SameSite. This is known as a Cross-Site Request Forgery attack, if you want to look up more information on that.
    – Ajedi32
    Oct 21, 2020 at 16:22
  • 1
    @zgulser: A common CSRF attack is assuming that the user is logged into the target site already, i.e. that there is an existing session cookie. With CSRF the request to the target site is triggered visiting the attacker site, i.e. causing some action on the same target with existing authentication but controlled by the attacker.
    – Steffen Ullrich
    Nov 22 at 20:09
  • 1
    @zgulser: "... injected malicious link in the victim's html page" - It is unclear what you mean with "victims html page". If you mean a malicious link to the target injected at a html page serviced by the target - this would not a a cross-site request at all and thus it would not be a CSRF attack.
    – Steffen Ullrich
    Nov 22 at 20:39

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .