CSRF is very deadly attack vector for the sensitive application operations like password change, profile update, banking transactions etc. It allows an attacker to set a page with payload on cross domain and mass exploitation by forcing users to compromise their session by leveraging cookie replay.
We covered this topic extensively over years - http://blog.blueinfy.com/search/label/CSRF
Web browsers are now supporting an added attribute called “SameSite” to the cookie and this attribute controls the replaying of the cookie. Before this addition, browser used to replay cookies if origin/domain is the same.
Hence, while setting up the cookie if directive is used as shown below.
Set-Cookie: key=value; SameSite=strict
This flag has a set of values as below with respective impact.
a.) If value is set to strict like “SameSite=strict” then cookie will replay only in case of same domain. Hence, if page is hosted on different domain and code on the page initiate GET/POST requests then these requests will not replay the cookie. Hence, application is protected against CSRF.
b.)If value is set to lax like “SameSite=lax” then cookie will replay in a few cases like link, rel or form with GET method. Hence, only GET request will replay the cookie in case of cross domain origin. CSRF for all other critical forms and POST requests will be blocked since browser will not replay the cookie from the browser.
Conclusion
It is imperative for critical applications to block CSRF attacks and there are several mesuares for it. One can apply tokens for every critical POST call and validate before processing the request. One can also put in place CAPTCHA to stop automated processing as well. For all these controls one needs to apply server side programming and strong defenses. “SameSite” cookie is an interesting browser side flag to kill CSRF right at the source. If cookie is not going to replay then CSRF gets killed and attacker can not host cross domain payload to perform mass CSRF exploitation.
We covered this topic extensively over years - http://blog.blueinfy.com/search/label/CSRF
Web browsers are now supporting an added attribute called “SameSite” to the cookie and this attribute controls the replaying of the cookie. Before this addition, browser used to replay cookies if origin/domain is the same.
Hence, while setting up the cookie if directive is used as shown below.
Set-Cookie: key=value; SameSite=strict
This flag has a set of values as below with respective impact.
a.) If value is set to strict like “SameSite=strict” then cookie will replay only in case of same domain. Hence, if page is hosted on different domain and code on the page initiate GET/POST requests then these requests will not replay the cookie. Hence, application is protected against CSRF.
b.)If value is set to lax like “SameSite=lax” then cookie will replay in a few cases like link, rel or form with GET method. Hence, only GET request will replay the cookie in case of cross domain origin. CSRF for all other critical forms and POST requests will be blocked since browser will not replay the cookie from the browser.
Conclusion
It is imperative for critical applications to block CSRF attacks and there are several mesuares for it. One can apply tokens for every critical POST call and validate before processing the request. One can also put in place CAPTCHA to stop automated processing as well. For all these controls one needs to apply server side programming and strong defenses. “SameSite” cookie is an interesting browser side flag to kill CSRF right at the source. If cookie is not going to replay then CSRF gets killed and attacker can not host cross domain payload to perform mass CSRF exploitation.