ShowExceptions should filter known sensitive keys from env #420

skimbrel opened this Issue Aug 23, 2012 · 11 comments


None yet
5 participants

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:
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.


raggi commented Aug 26, 2012

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.

@ghost ghost assigned raggi Aug 26, 2012


chneukirchen commented Aug 26, 2012

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?


chneukirchen commented Aug 27, 2012

I wonder why it does that... it only verifies against the secrets stored in the instance variables...


raggi commented Nov 3, 2012

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.

@raggi raggi closed this Nov 3, 2012

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...


raggi commented Nov 23, 2014

@dleve123 use production mode. if it's in production, that's a rails bug.

What does rake middleware RAILS_ENV=production say?

@raggi Thanks for helping out!

$ rake middleware RAILS_ENV=production
use Raven::Rack
use HttpMethodNotAllowed
use ActionDispatch::SSL
use Rack::Sendfile
use ActionDispatch::Static
use #<ActiveSupport::Cache::Strategy::LocalCache::Middleware:0x007feaf6822e98>
use Rack::Runtime
use Rack::MethodOverride
use ActionDispatch::RequestId
use RequestStore::Middleware
use Rails::Rack::Logger
use ActionDispatch::ShowExceptions
use ActionDispatch::DebugExceptions
use ActionDispatch::RemoteIp
use ActionDispatch::Callbacks
use ActiveRecord::ConnectionAdapters::ConnectionManagement
use ActiveRecord::QueryCache
use ActionDispatch::Cookies
use ActionDispatch::Session::CookieStore
use ActionDispatch::Flash
use ActionDispatch::ParamsParser
use Rack::Head
use Rack::ConditionalGet
use Rack::ETag
use Warden::Manager
run Healthify::Application.routes

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>



<div id="explanation">
    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.


raggi commented Nov 26, 2014

So either one of those middleware has it implicitly in their internal stack, or you have it in, or you're booting a server in a different way.

frankel commented Jan 8, 2015

@dleve123 In my case, I found the answer, Search "RACK_ENV" and "Rack::ShowExceptions"

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment