3 ms·
For the specific vulnerability that came out this week, you can just add the following to an initializer or application.rb: ActionDispatch::ParamsParser::DEFAU
by gommm 14y ago
For the specific vulnerability that came out this week, you can just add the following to an initializer or application.rb:
ActionDispatch::ParamsParser::DEFAULT_PARSERS.delete(Mime::XML)
This disable the XML parsing of params which introduced the bug and most people do not use. Like this you can at least be protected for now and give yourself time to test and review the upgrade to a newer version of Rails...
It's still better to use the latest version and keep up to date, but right now the priority is to make sure that your application isn't vulnerable to an attack.
To test if an application is vulnerable, you can use the following:
curl -i -H "Content-Type: application/xml" -X POST -d '<id type="yaml">--- !ruby/object:ActionController::Base foo: 6</id>' http://example.com http://example.com
If the logs show something like this then the application is vulnerable
Parameters: {"id"=>#<ActionController::Base:0x007f8534fdd840 @foo=6>}
- chao- 14y agoThanks. I added the workaround on Day 1, and have tested it using the following: http://blog.codeclimate.com/blog/2013/01/10/rails-remote-code-execution-vulnerability-explained/ http://blog.codeclimate.com/blog/2013/01/10/rails-remote-cod... I've just had this itching question about whether or not using a cloud host (ala Heroku) is limiting my ability to use a patchfile the way I otherwise would on a dedicated host. I'm imagining a nightmare scenario of another vulnerability without such an easy workaround, requiring use of the patchfile. I've been searching/reading constantly since my initial post and have learned about "rails:freeze:gems" and "rake gems:unpack" which I guess would serve as patchable, as long as Heroku uses them when told to.