4 ms·
What's their plan for dealing with CSRF? For this type of app, the usual solution is to embed a token in the first response, shared between the page and the s
by pygy_ 13y ago
What's their plan for dealing with CSRF?
For this type of app, the usual solution is to embed a token in the first response, shared between the page and the server, and use it for authenticated communication through the data channel (be it AJAX or a WebSocket).
Consequently, the first page can't be static.
- camus2 13y agocant the first page just request a token through ajax?
- reverius42 13y agoyes.
- Joeri 13y agoThe token is returned by the auth service when the user logs in. The initial page bootstraps in unauthenticated mode and always has to query the auth service first to figure out if the user is logged in. That's how I've done it in the past.
- pygy_ 13y agoHow do you tell apart the app loaded in several tabs and and an attacker?
- mbleigh 13y agoCSRF is more or less impossible in a static site architecture. Since everything is just static HTML there are generally no form submission endpoints to attack. XSS can be very dangerous, as can session hijacking, but CSRF is pretty much moot on static apps.
- pygy_ 13y agoEverything is _not_ static: there's a data channel. If you need to support browsers that do not support localStorage, indexedDB or another kind of local, private storage, you must either restrict authentication to a single tab or provide a token on page load, and not later (one token per page load). This is less of a concern now, but it used to be the case.
- mbleigh 13y agoYou can use CORS and withCredentials to use simple cookie-based browser sessions for authentication. It's still hard against CSRF because as long as you properly origin-check the request you don't have to worry about form forgery. Wrote about this some at http://www.divshot.com/blog/static-apps/cookies-and-cors http://www.divshot.com/blog/static-apps/cookies-and-cors