danforth-east
danforth-east copied to clipboard
Use different CSRF checking scheme
My first implementation of CSRF prevention code used the "Double Submit Cookies" pattern. That works fine for the management site, but not for the self-serve page.
The problem is that Safari prevents iframe
s from setting cookies except in directly response to user action. There's some info here (or google for something like "safari iframe post cookie"). In practice, I have seen CSRF validation errors from mobile and desktop Safari browsers.
For now I have disabled the CSRF check for the self-serve page (11216ecf48c2b718853ae880f21908a53a32a6d4). This is very distasteful, but... it's a publicly accessible, unauthenticated page, so any CSRF attack doesn't gain privilege escalation, so there's no reason to do one. But it's still distasteful.
Possible alternatives:
- It might be possible to use the form submit as a "user action" that goes to the server, gets a response with a cookie, and then uses that cookie in the AJAX POST. See the description here. It's ugly, though.
- Other mitigations are described in the OWASP cheat sheet. Maybe the "Encrypted Token Pattern" -- although I'm not sure what use in place of a "UserId". Maybe IP address (or other request metadata?).