GitHub is home to over 20 million developers working together to host and review code, manage projects, and build software together.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
Already on GitHub? Sign in to your account
A warning that this "could" happen really isn't sufficient, particularly when using this in conjunction with other Rack middleware like Rack::Session::Cookie will result in leakage of the session cookie secret.
For reference, here's how Django handles its debug page: https://github.com/django/django/blob/master/django/views/debug.py
Note the HIDDEN_SETTINGS variable and the use of cleanse_setting() to prevent configuration of Django built-ins from leaking.
To reproduce: enable ShowExceptions and Session::Cookie, then do anything to a Rack-powered application that causes it to crash and show the ShowExceptions page. Witness the dumping of all of env, including rack.session.options and its :secret/:oldsecret values.
Hosting things in development mode in production is generally a really bad idea regardless. I'll consider this either way, as users cannot be trusted with themselves, but this makes me uneasy. It's always an incomplete approach, and just as flawed as $SAFE - that is, whilst I can block things that live in rack, when someone adds non-core middleware, I can't protect them from themselves anymore. Only you can protect yourself.
How does the secret get into the env, anyway?
@raggi Agreed wholeheartedly, but "sane defaults" is also a good principle.
@chneukirchen I'm not that familiar with the Rack code but it looks like the middleware merges its options into the server options when it initializes. That might be how it gets there?
I wonder why it does that... it only verifies against the secrets stored in the instance variables...
@skimbrel the sane default exists here: https://github.com/rack/rack/blob/master/lib/rack/server.rb#L212-223
I'm closing this out for now. I'd accept a lightweight patch for this, but will not take the time to implement it at present. ShowExceptions is not recommended for production use.
Hey @raggi and @skimbrel,
How do you remove Rack::ShowExceptions from a Rails 4.0.4 app? I ran across this exact issue and want to not output sensitive info like the all the cookie details.
A config.middleware.delete 'Rack::ShowExceptions' didn't work at all...
@dleve123 use production mode. if it's in production, that's a rails bug.
What does rake middleware RAILS_ENV=production say?
rake middleware RAILS_ENV=production
@raggi Thanks for helping out!
$ rake middleware RAILS_ENV=production
However, simulation an ArgumentError (liking POSTing with an unescaped %), spits out HTML generated by Rack::ShowExceptions.
$ tail -n 20 argument_rack_error.html
<td class="code"><div>2014-11-23 17:30:07 -0500</div></td>
You're seeing this error because you use <code>Rack::ShowExceptions</code>.
Seems really odd to me! I have tried removing ActionDispatch::ShowExceptions, but still got the same page from Rack::ShowExceptions.
So either one of those middleware has it implicitly in their internal stack, or you have it in config.ru, or you're booting a server in a different way.
@dleve123 In my case, I found the answer, http://manpages.ubuntu.com/manpages/quantal/man1/unicorn.1.html Search "RACK_ENV" and "Rack::ShowExceptions"