Timeline for Double Submit Cookie: Can the attacker set the cookie as a separate header?
Current License: CC BY-SA 4.0
13 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Oct 14, 2019 at 17:25 | comment | added | Conor Mancone | Let us continue this discussion in chat. | |
| Oct 14, 2019 at 17:03 | comment | added | zerohedge | but it DOES open me to XSS, no? | |
| Oct 14, 2019 at 17:00 | comment | added | Conor Mancone | @zerohedge so is this your authorization cookie? It sounds like it is. To be clear, what you describe will certainly protect you from CSRF attacks. However, using your auth cookie for both authorization and CSRF protection is something that is likely to cause trouble in the long term. Usually, giving one thing two purposes just doesn't work out in practice. | |
| Oct 14, 2019 at 16:47 | comment | added | zerohedge | So, upon login, I set the HttpOnly cookie in the Django response, but I also return it in the payload - and then save it in state (vuex store). Then (only given the token is available in state), the Axios plugin attaches it as an Authorization header. This happens client-side (in a Nuxt.js plugin using an axios interceptor nuxtjs.org/guide/plugins ). | |
| Oct 14, 2019 at 16:16 | comment | added | Conor Mancone | In that case though I have one further question: how are you getting the token into the client request? In Django it is also writing out the cookie value into an element in the form. The cookie probably still has the HTTPOnly flag set, since it isn't being used in javascript, but since it isn't an auth cookie it doesn't matter either way. Then Django compares the value in the form against the value in the cookie. It sounds like you're doing something that is a mix between DSC and cookie-to-header: en.wikipedia.org/wiki/… | |
| Oct 14, 2019 at 16:13 | comment | added | Conor Mancone | @zerohedge A difference (unless I've misunderstood your question), is that the cookie that django uses in the double-submit-cookie CSRF auth is NOT the authorization cookie. I mean, you could use the auth as your double-submit-cookie, but doing so requires making your authorization cookie more susceptible to attack (by storing it in an accessible method on the client side). | |
| Oct 14, 2019 at 15:43 | comment | added | zerohedge | I’m now confused on whether what I’m doing is actually wrong after reading this: stackoverflow.com/questions/49298250/… | |
| Oct 14, 2019 at 15:21 | comment | added | zerohedge | Yeah. That’s what my backend (Django REST) does by default - it creates a CSRF valid for one year. I’ll see what I can do to use it since it’s disabled by default once you use REST (because of the horrible advice to use LocalStorage) | |
| Oct 14, 2019 at 15:21 | comment | added | Conor Mancone | @zerohedge security.stackexchange.com/questions/22903/… | |
| Oct 14, 2019 at 15:19 | comment | added | Conor Mancone | @zerohedge The recommendation on cookies varies wildly depending on your use case and needs. For CSRF tokens though there is a more clear answer. You can technically get away with creating one on login and never refreshing it until the next login. Personally though I prefer refreshing them after each use. However, they don't need to have an expiration time. | |
| Oct 14, 2019 at 15:15 | comment | added | zerohedge | You are right, of course. This probably means I should be tracking two values in the backend. Are there any resources regarding the recommended expiration time for both credentials (CSRF token & cookies)? | |
| Oct 14, 2019 at 15:13 | vote | accept | zerohedge | ||
| Oct 14, 2019 at 14:35 | history | answered | Conor Mancone | CC BY-SA 4.0 |