4 ms·

I think token based authentication for API calls is great, but for browser based usage cookies are extensively studied and well understood mechanism that is IMO

I think token based authentication for API calls is great, but for browser based usage cookies are extensively studied and well understood mechanism that is IMO a much safer option. You wrote that XSS is much less risky that CSRF, but 'based on our experience' argument is not really strong. For example OWASP study lists CSRF as easier to prevent than XSS: http://owasptop10.googlecode.com/files/OWASP%20Top%2010%20-%202013.pdf http://owasptop10.googlecode.com/files/OWASP%20Top%2010%20-%... To me this makes sense, XSS vulnerability can be introduced anywhere in your application code, CSRF can be dealt with in a single middleware, which greatly simplifies prevention. How about https only cookies? Can you enforce that tokens won't ever be send over http? Can your enforcement work in a presence of XSS (as is the case with a combination of 'secure' and 'httponly' cookie flags). With tokens it is easier to do authenticated cross origin requests. But a new mechanism may be vulnerable to a new class of vulnerability, where a web app will be tricked to make such requests to evil domains (it may sound unrealistic, but remember that CSRF was discovered many years after cookies were introduced). Cookies can also require no server side state. You can put signed, encrypted content in them and many frameworks support this, which shrinks a list of token benefits a bit. I do think that token based approach is more elegant from the architecture point of view, because you don't need to deal with two different authentication schemes to support browser traffic and API calls, but I'll still stay with cookies for browser auth.

jfroma 13y ago
The [OWASP] recommended approach to solve CSRF is with a Synchronizer Token [1]. Basically render a token with a hidden input with your form associated with the user session and as you mention use a middleware to validate the token on every request. So, let's talk about Syncronizer Token and "Single Page Applications" which was the topic on our first blog post. The recommended way for this is to get a token the first time and use the token in a header in every AJAX request. [2] So, you now have cookies that are vulnerables to CSRF and a token in your javascript scope, in the same way you have the JWT. If you think XSS is that common, the http only cookie+synchronizer token is more work and equally vulnerable to CSRF. While with JWT you can stole my token if the site is XSS-vulnerable, but you can't trick me with the browser to do things I didn't meant. I still consider XSS is easy to prevent than CSRF, you just need to escape user inputs always which is what every major template engine does by default. Usually you get the common syntax which does ESCAPE the user input. Why OWASP states the contrary? I have one word: php. I blame php, wordpress and wordpress plugins. Consider that half of the internet runs on wordpress. [1]: https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet#General_Recommendation:_Synchronizer_Token_Pattern https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(... [2]: https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet#Encrypted_Token_Pattern https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(...

jfroma 13y ago

The [OWASP] recommended approach to solve CSRF is with a Synchronizer Token [1]. Basically render a token with a hidden input with your form associated with the user session and as you mention use a middleware to validate the token on every request. So, let's talk about Syncronizer Token and "Single Page Applications" which was the topic on our first blog post. The recommended way for this is to get a token the first time and use the token in a header in every AJAX request. [2] So, you now have cookies that are vulnerables to CSRF and a token in your javascript scope, in the same way you have the JWT. If you think XSS is that common, the http only cookie+synchronizer token is more work and equally vulnerable to CSRF. While with JWT you can stole my token if the site is XSS-vulnerable, but you can't trick me with the browser to do things I didn't meant. I still consider XSS is easy to prevent than CSRF, you just need to escape user inputs always which is what every major template engine does by default. Usually you get the common syntax which does ESCAPE the user input. Why OWASP states the contrary? I have one word: php. I blame php, wordpress and wordpress plugins. Consider that half of the internet runs on wordpress. [1]: https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet#General_Recommendation:_Synchronizer_Token_Pattern https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(... [2]: https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet#Encrypted_Token_Pattern https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(...