CSRF prevention by “SameSite” flag

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.  

CSRF with upload – XHR-L2, HTML5 and Cookie replay

XHR level 2 calls embedded in HTML5 browser can open a cross domain socket and deliver HTTP request. Cross Domain call needs to abide by CORS. Browser will generate preflight requests to check policy and based on that will allow cookie replay. Interestingly, multi-part/form-data request will go through without preflight check and “withCredentials” allows cookie replay. This can be exploited to upload business logic files via CSRF if server is not validating token/captcha. Business applications are allowing to upload files like orders, invoices, imports, contacts etc. These critical functionalities can be exploited in the case of poor programming.

If we have a business functionalities for actual upload form then this type of HTTP request will get generated at the time of upload. Note, cookie is being replayed and request is multi-part form.

Now, if CSRF payload has following XHR call.

Above call will generate following HTTP request and causes CSRF and upload the file. Hence, without user’s conscent or knowledge cross domain file being uploaded on the target application with the logged in credential.

Future probes – one needs to check other impact like AMF stream uploading, XML file transfer and few other library protocols which is now a day’s dealing in multi-part to support binary calls.

If you are interested in this analysis should visit @kkotowicz work - http://blog.kotowicz.net/2011/04/how-to-upload-arbitrary-file-contents.html.