Currently XSRF protection resets session and lets the request through when XSRF token verification fails, which by itself is an XSRF vulnerability since it allows anyone to logout users by directing their browser to a page that requires XSRF protection.
One approach proposed by @NZKoz was to have protect_from_forgery accept :with option, e.g.:
protect_from_forgery :with => :exception
protect_from_forgery :with => :null_session
with :exception hopefully being the default.
CC: @NZKoz @igrigorik @ratnikov
It's possible to override #handle_unverified_request method in controller, e.g.:
class ApplicationController < ActionController::Base
# raise an exception or do anything else
yes, it is, but I am talking about the defaults here.
@lest yeah, the intention here is to ensure that we can raise exceptions by default but have a simple comment in the generated app telling people that "if you have an API, change this to :null_session" so we're safer / simpler by default, but still work for APIS.
@NZKoz I'm going to prepare PR
This has been merged now, I'll look to put the proper 'null session' change in prior to 4.0 shipping
Awesome! Thanks Michael! Thanks Sergey!
Additionally, please consider one of the features that @ratnikov has implemented in his strict-forgery-protection gem:
which serves as a great safety net for app devs that forget to enable XSRF protection on controllers. His code basically checks if as a result of the request DB entries have been modified and warns user if that's the case(obviously behaviour could be customized and exception could be thrown in dev mode, etc). I think that this approach will help in 2 cases: