Security Monitor Upgrade
On Friday, we rolled out an upgrade to the engine that powers Security Monitor. The new engine is more accurate (fewer false positives) and more thorough (detects more potential vulnerabilities). The major changes are outlined below:
New checks
Unsafe symbol creation DoS vulnerability - One Denial of Service (DoS) technique specific to Ruby takes advantage of the way symbols are stored. Specifically, because symbols are not garbage collected, if an attacker can find a way to create an unbounded set of new symbols, they can create unbounded memory growth, which generally leads to… bad things.
Security Monitor now includes a check to make sure unsafe input (e.g. params) is not dynamically translated into symbols. References like
params[:foo].to_sym
or:"my_#{params[:foo]}"
will generate a warning.Symbol DoS vulnerability in Active Record (CVE-2013-1854) - Similarly, a warning was added for applications using vulnerable versions of ActiveRecord. Queries of the form
User.where(:name => params[:name])
were vulnerable to symbol DoS attacks whenparams[:name]
was a hash. More Information.Cross Site Scripting (XSS) vulnerability in
#sanitize_css
(CVE-2013-1855) - Applications impacted by an ActionPack vulnerability will see a new warning. The method#sanitize_css(user_input)
had a XSS vulnerability when called with specially crafted user input. More information.XSS vulnerability in
#sanitize
(CVE-2013-1857) - Certain versions of Action Pack have a vulnerability in the#sanitize
helper method which allows an attacker to inject URLs with JavaScript. Security Monitor will issue warnings for each use of#sanitize
if the Rails version is vulnerable. More information.Unsafe reflection - Security Monitor will now warn when
#constantize
is called on user input as in, for example,params[:class].constantize
. More information, including some example exploits for this vulnerability, are detailed on this blog post by Gabriel Quadros.
Improvements
Do not warn on mass assignment restricted with
#slice
/#only
A false positive for mass assignment vulnerabilities was resolved. Usingslice
oronly
on parameters is now considered safe, such as in the following code:User.new(params.slice(:name, :email)) User.new(params.only(:name, email))
Detect another way to activate strong_parameters - Security Monitor was issuing warnings about mass assignment even though they had configured their Rails 3 application to use Strong Parameters. This occurred when Strong Parameters was activated with the following code:
ActiveRecord::Base.send(:include, ActiveModel::ForbiddenAttributesProtection)
(Instead of say, using
class_eval
.) Security Monitor now detects this syntax, which removes false positive warnings about mass assignment on impacted applications.Add support for Slim templates - Support for detecting vulnerabilities in Slim templates (like Haml) was added.
Overall, security analysis should now be more more accurate and thorough. However, if you’re seeing some new unexpected results, do not hesitate to let us know.