Flawed CSRF token implementation

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

Comments

Popular posts from this blog

SQL Injection in search field

Nipper Download