mardi 31 mai 2016

Why do browsers allow CSRF?

I am pretty new to web security, and as I read more about the different attack vectors, my mind boggles that they are allowed in the first place. It's like the web was designed with a broken security model and to be vulnerable.

I am also amazed at the amount of vague and imprecise information. For example, at first the Single Origin Policy sounds pretty good, then I read that it only applies to XHR, and oh and by the way, doesn't actually prevent XHR cross-origin POST, which is the classic CSRF attack. Glad I kept reading.

There is also an Origin header that the server can use to make sure the request is coming from the right place -- but oops, it is set inconsistently across browsers, and if it is NOT set, you can't be quite sure if it was because of a same-origin request, or a request type that just didn't get it for certain browsers (maybe an IMG tag?). Keep reading.

So the right way seems to be set a CSRF token in the session cookie, and also add that token to forms/links, and then compare them server side on a submission. In theory (and lets exclude all XSS attacks for the purpose of this question), a CSRF attempt from another tab may make a POST request to a form that includes the cookie, but without a form input element set to the matching token (because it can't read the token from the cookie), so the server will reject the request. Works but kludgy, and make sure you never ever forget to check!

Holding that thought in mind for a second, here is my question -- why does the browser send the session cookie in a request that originates from a page that is not the origin of the cookie?

I mean, browsers will refuse to send cookies to different domains for good reason, but are quite happy to send them from different origins? Would stuff break if they didn't? Would it be a robust defence against CSRF, only requiring servers to do what they are doing anyway -- checking for a valid session cookie?




Aucun commentaire:

Enregistrer un commentaire