The sole purpose of (secret) CRSF token is to help the application identify authenticated or unauthenticated requests. Any request that doesn’t contain csrf tokens are treated as unauthenticated one thus rejected by the application as the csrf tokens are only available to the authenticated users.
But contrary to that, in one application, the csrf tokens are generated before login and worse, it’s not regenerated after successful authentication of the user. This defeats the purpose of anti-csrf approach.
Anti-CSRF best practices:
Don’t issue csrf tokens before authentication
Always regenerate the tokens after successful authentication, if issued before authentication
Use POST methods for critical transactions embedding csrf tokens
Don’t send the csrf tokens in GET requests as they may reveal it in browser logs etc
In few Ruby based apps, where the token was being generated before authentication and same was being used.
Mitigation: (taken from 'Symbolic Security Analysis of Ruby-on-Rails Web Applications' white paper):
While talking about csrf protection, they say, Finally, we must account for “insider attacks,” i.e., attacks by users of the application (against other users of the application). To understand this issue, we need to look again at the implementation of token generation on line 30 above. The complication here is that session[:_csrf_token] is not reset automatically by Rails between logins, hence different users that log in from the same IP address could inadvertently be given the same CSRF token. To properly protect against CSRF, the application should always change session[:_csrf_token] to nil before logging in a user, so that the token is regenerated whenever a different user logs in. Rails provides a method, reset_session, which has just this effect:
class Controller::Base # continued
def reset_session() session = {} end
end
But contrary to that, in one application, the csrf tokens are generated before login and worse, it’s not regenerated after successful authentication of the user. This defeats the purpose of anti-csrf approach.
Anti-CSRF best practices:
Don’t issue csrf tokens before authentication
Always regenerate the tokens after successful authentication, if issued before authentication
Use POST methods for critical transactions embedding csrf tokens
Don’t send the csrf tokens in GET requests as they may reveal it in browser logs etc
In few Ruby based apps, where the token was being generated before authentication and same was being used.
Mitigation: (taken from 'Symbolic Security Analysis of Ruby-on-Rails Web Applications' white paper):
While talking about csrf protection, they say, Finally, we must account for “insider attacks,” i.e., attacks by users of the application (against other users of the application). To understand this issue, we need to look again at the implementation of token generation on line 30 above. The complication here is that session[:_csrf_token] is not reset automatically by Rails between logins, hence different users that log in from the same IP address could inadvertently be given the same CSRF token. To properly protect against CSRF, the application should always change session[:_csrf_token] to nil before logging in a user, so that the token is regenerated whenever a different user logs in. Rails provides a method, reset_session, which has just this effect:
class Controller::Base # continued
def reset_session() session = {} end
end
Comments