← Back to changelog

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 when params[: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.


  • Do not warn on mass assignment restricted with #slice/#only A false positive for mass assignment vulnerabilities was resolved. Using slice or only 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.

Actionable metrics for engineering leaders. Try Velocity Free