Happy Eggnog Riot day!

This is a major release: 95 changed files with 1,775 additions and 14,484 deletions. This provides ample room for new bugs, so please report any issues.

Changes since 1.8.3:

• Update to RubyParser 3
• Ignore route information by default
• Add optional “interprocedural” analysis for controllers
• Properly pass instance variables between before_filters
• Support strong_parameters (#88)
• Support newer validates :format call (#198)
• Add scan time to reports (#158)
• Add Brakeman version to reports
• Don’t mangle whitespace in JSON code formatting
• Fix CheckExecute to warn on all string interpolation (#213)
• Fix false positive on to_sql calls
• Add AppTree as facade for filesystem (Bryan Helmkamp)
• Add link for translate vulnerability warning (Michael Grosser)
• Add Rakefile to run tests (Michael Grosser)
• Better default config file locations (Michael Grosser)
• Remove “find by regex” feature from CallIndex
• Reduce Sexp creation
• Handle empty model files

Update to RubyParser 3

With the update to use RubyParser 3.x, Brakeman no longer includes a vendored version of RubyParser (which was only used with running with Ruby 1.9), which reduced code size by about 14,000 lines.

RubyParser 3 supports Ruby 1.9 much more fully, so there should be very few parse errors. Additionally, Brakeman no longer chooses parsers based on the current Ruby version.

(changes)

Route Information Ignored by Default

Route information is only used in Brakeman to determine whether a controller method should perform an implicit render. Since determining Rails routes statically is quite difficult to get right, it is better to assume a method is a routable action. Previous versions provided the -a option for this, which is now on by default. To turn off this behavior (and revert to the old), use --no-assume-routes.

This does not affect default route warnings.

(changes)

Optional Interprocedural Analysis for Controllers

Currently, Brakeman essentially looks at each method in isolation. Values are propagated from controller actions (including before_filters) through rendered views and templates. But if a controller action calls another method which has an effect on the eventual output of the action, Brakeman does not processed the invoked method.

This release includes optional, experimental support for analyzing controller methods called from within controller actions.

For a simple example, instance variables set in helper methods will now be added to a rendered view. Also, values returned from called methods will be tracked:

def create
  get_user 
  #@user is now User.find(params[:id])

  @account = find_account(@user)  
  #@account is now Account.where(:user => User.find(params[:id]).id
end

private

def get_user
  @user = User.find(params[:id])
end

def find_account
  Account.where(:user => @user.id)
end

This is limited to methods available in the controller (via a parent class or mixins). It is also limited to a “depth of one”, meaning it will not try to analyze methods called by helper methods (get_user and find_account above).

Since this feature is still experimental and will definitely increase scan times, it is turned off by default. Use --interprocedural to enable it. (Better name pending suggestions…)

(changes)

Pass Instance Variables between Filters

While instance variables set in before_filters were set properly, before_filter which used instance variables from an earlier filter could not see those variables. This has been fixed, which will likely lead to new or more accurate warnings.

(changes)

Support for strong_parameters

In Rails 4, the responsibility for mass assignment protection will move from models to controllers where mass assignment is actually used. A preview of the new functionality is available in the strong_parameters gem. Brakeman should no longer warn on mass assignment for models protected with strong_parameters.

(changes)

Support validates :format

In Rails 3, format validation changed from validates_format_of to the more generic validates method. Brakeman will now check validates calls for proper anchors on regular expressions for :format.

(changes)

Report Changes

Reports will now contain Brakeman version and scan duration. JSON reports contain start_time and end_time timestamps. For now, JSON reports will still have a timestamp key, but it will be identical to end_time. It will be removed in Brakeman 2.0.

(changes)

Additionally, code formatting in JSON reports has changed slightly. Previously, code was formatted with the HTML output in mind, so line breaks were removed. Now JSON reports include the code formatted from Ruby2Ruby without any mangling.

(changes)

Fix Command Injection Check

The command injection check will now (again) warn on any form on string interpolation used for process execution, whether or not user input is involved.

(changes)

Fix to_sql False Positives

SQL code generated from Arel’s to_sql method will be considered safe.

(changes)

File System Facade

Bryan Helmkamp cleaned up Brakeman’s file access into a single object. This should simplify future changes and add some consistency to how Brakeman handles files.

(changes)

Run Tests via Rake

Thanks to Michael Grosser, running rake will now run Brakeman’s tests.

(changes)

Improved Config File Locations

Also thanks to Michael Grosser, Brakeman will check more sane locations for Brakeman configuration files. This version adds ./config/brakeman.yml, ~/.brakeman/config.yml, and /etc/brakeman/config.yml as default locations for configuration files. The old locations are deprecated now, and will be removed in Brakeman 2.0.

(changes

More Internal Changes

Call indexing performance has been given another slight boost with the removal of the ability to search for call targets via regular expressions (which was not being used anywhere).

(changes)

The number of s-expressions generated by Brakeman has been reduced, although this did not lead to any major performance improvement.

(changes)

Data-flow/alias processing was performing two passes. This has been reduced to just one.

(changes)

Empty model files will no longer cause errors.

Report Issues

Please report any issues with this release! Take a look at this guide to reporting Brakeman problems.

Also consider joining the mailing list or following @brakeman on Twitter.