Is it ok to use Plug.CSRFProtection this way?

I’m implementing a mandatory secure measure for a custom OAuth driver, this one deals with CSRF protection in a custom way (state parameter, s. https://tools.ietf.org/html/draft-bradley-oauth-jwt-encoded-state-00 ).

Since I want to keep it simple and avoid generating and persisting state unless I have to, I’m currently doing the following:

  • Request stage uses Plug.CSRFProtection.get_csrf_token() to generate a token and sends it as a state parameter which also puts it into the process dictionary

  • Callback stage uses Plug.CSRFProtection.get_csrf_token() again which fetches existing token and compares it with the one returned as state (OAuth Server just passes it unchanged)

This works, but I wonder if I’m not abusing it. Is it safe to assume that get_csrf_token() will deliver a new token per session and then the same token for the rest of the session?

Say one user triggers request phase, then another user does the same, then the first user triggers callback - will this work and not fail cause get_csrf_token() delivers second user’s token?

Well I can answer that now: no it’s not OK :slight_smile: The generated token is only really the same per process and not per session (there is no magic tying it to session).

4 Likes