Issue with Sinatra and header name about rack_csrf

[wader]

That's strange. Does it work if you disable rack protection with disable :protection in your sinatra app? if so maybe add some debug to rack-protection/lib/rack/protection / authenticity_token.rb to see whats going on.

[baldowl]

@etdsoft, it's quite strange.

I've just tried playing with the Sinatra example application using racksh. Here's the session:

>> $rack.get '/'
=> #<Rack::MockResponse:0x007fbd4d256680 @original_headers={"Content-Type"=>"text/html;charset=utf-8", "Content-Length"=>"321", "X-XSS-Protection"=>"1; mode=block", "X-Content-Type-Options"=>"nosniff", "X-Frame-Options"=>"SAMEORIGIN", "Set-Cookie"=>"rack.session=BAh7B0kiD3Nlc3Npb25faWQGOgZFVEkiRTA2NzIwYjc5ZDE1NzVmNDMwY2Uw%0AYzc2ZmQ2MjM2ZmE0NjY1ZDlhZGMzYzMzMGVhNTQ3ODBkOWJkZjMyZmQyY2UG%0AOwBGSSIPY3NyZi50b2tlbgY7AFRJIjF2MktoZDRhZXRjK0JOa1BpOGVuL0oz%0Abmt3Z3p3STJ3YkxVd2tGU3ZTekJnPQY7AEY%3D%0A; path=/; HttpOnly"}, @errors="127.0.0.1 - - [18/Mar/2014 18:08:26] \"GET / \" 200 321 0.0041\n", @body_string=nil, @status=200, @header={"Content-Type"=>"text/html;charset=utf-8", "Content-Length"=>"321", "X-XSS-Protection"=>"1; mode=block", "X-Content-Type-Options"=>"nosniff", "X-Frame-Options"=>"SAMEORIGIN", "Set-Cookie"=>"rack.session=BAh7B0kiD3Nlc3Npb25faWQGOgZFVEkiRTA2NzIwYjc5ZDE1NzVmNDMwY2Uw%0AYzc2ZmQ2MjM2ZmE0NjY1ZDlhZGMzYzMzMGVhNTQ3ODBkOWJkZjMyZmQyY2UG%0AOwBGSSIPY3NyZi50b2tlbgY7AFRJIjF2MktoZDRhZXRjK0JOa1BpOGVuL0oz%0Abmt3Z3p3STJ3YkxVd2tGU3ZTekJnPQY7AEY%3D%0A; path=/; HttpOnly"}, @chunked=false, @writer=#<Proc:0x007fbd4d255bb8@/Users/emanuele/.rbenv/versions/2.0.0-p451/lib/ruby/gems/2.0.0/gems/rack-1.5.2/lib/rack/response.rb:27 (lambda)>, @block=nil, @length=321, @body=["<form action=\"/response\" method=\"post\">\n  <h1>Spit your utterance!</h1>\n  <input type=\"text\" name=\"utterance\">\n  <input type=\"hidden\" name=\"_csrf\" value=\"v2Khd4aetc+BNkPi8en/J3nkwgzwI2wbLUwkFSvSzBg=\" />\n  <p><input type=\"submit\" value=\"Send!\"></p>\n</form>\n\n<p>Try also the <a href=\"/notworking\">not working</a> form!</p>\n"]>
>> token = $rack.last_request.env['rack.session'][Rack::Csrf.key]
=> "v2Khd4aetc+BNkPi8en/J3nkwgzwI2wbLUwkFSvSzBg="
>> $rack.post '/response', {'utterance' => 'Hello World!'}, {'HTTP_X_CSRF_TOKEN' => token}
=> #<Rack::MockResponse:0x007fbd4d08de48 @original_headers={"Content-Type"=>"text/html;charset=utf-8", "Content-Length"=>"162", "X-XSS-Protection"=>"1; mode=block", "X-Content-Type-Options"=>"nosniff", "X-Frame-Options"=>"SAMEORIGIN"}, @errors="127.0.0.1 - - [18/Mar/2014 18:09:42] \"POST /response \" 200 162 0.0012\n", @body_string=nil, @status=200, @header={"Content-Type"=>"text/html;charset=utf-8", "Content-Length"=>"162", "X-XSS-Protection"=>"1; mode=block", "X-Content-Type-Options"=>"nosniff", "X-Frame-Options"=>"SAMEORIGIN"}, @chunked=false, @writer=#<Proc:0x007fbd4d08d920@/Users/emanuele/.rbenv/versions/2.0.0-p451/lib/ruby/gems/2.0.0/gems/rack-1.5.2/lib/rack/response.rb:27 (lambda)>, @block=nil, @length=162, @body=["<p>It seems you've just said: <em>Hello World!</em></p>\n\n<p>Here's the anti-CSRF token stuffed in the session: <strong></strong></p>\n\n<p><a href='/'>Back</a></p>\n"]>
>> $rack.last_response.status
=> 200
>> quit

In plain English: I simulated a GET request to '/' to start the conversation, then extracted the token from the session and used it in a POST request in which the token has been sent in the HTTP_X_CSRF_TOKEN header; the application replied positively.

Can you replicate it with a minimal application?

[etdsoft]

@wader @baldowl thanks, this obviously requires more debugging work on my side.

@baldowl thanks for the pointer to racksh 👍 I've confirmed the same result you got.

And what is worse, I got the same 200 result in my app in development. It only fails in production.

Will leave this open until I find out what is going on and report back.

[etdsoft]

Posting that previous message made me realise it'd have to do with the stack in production, and sure enough:

http://stackoverflow.com/questions/5920426/lost-custom-http-header-when-using-nginxpassenger

Nginx was filtering the _ headers (see underscores_in_headers on; setting).

Changing my header to X-CSRF-TOKEN seems to have done the trick.