As planned, Brakeman 1.9.5 is mostly internal bug fixes and improvements, with the one exception being a new check for symbol creation from user input. Barring any emergencies, the next release will be 2.0.

Changes since 1.9.4:

• Add check for unsafe symbol creation (Aaron Weiner)
• Do not warn on mass assignment with slice/only (#203)
• Do not warn on session secret if in .gitignore (#241)
• Fix session secret check for Rails 4
• Fix scoping for blocks and block arguments
• Fix error when modifying blocks in templates
• Fix crash on before_filter outside controller
• Fix Sexp hash cache invalidation
• Respect quiet option in configuration file (#300)
• Convert assignment to simple if expressions to or
• More fixes for assignments inside branches
• Refactoring of CheckLinkTo and Report (Bart ten Brinke)
• Pin ruby2ruby dependency to version 2.0.3 (see here)

Symbol Creation Check

Aaron Weiner added a check for symbol creation from user input, such as params[:x].to_i which can lead to Denial of Service.

(changes)

Mass Assignment with Select Keys

A common pattern to avoid mass assignment issues is to use slice or only when passing in values to mass assignment methods. Brakeman should no longer warn in these situations.

(changes)

Ignoring Session Secrets

Brakeman no longer warns if the config file containing the session secret key is included in .gitignore. This only applies if the default file names are used.

(changes)

Warn on Rails 4 Session Secrets

Support for Rails 4 session secrets has been added, since the configuration for that changed again.

(changes)

Block Scoping

Correct scope for blocks is tricky, and there are also some differences between Ruby 1.8 and 1.9 for block arguments. For the most part, Brakeman has ignored blocks, but this lead to some compounding issues with assignments in branches.

This release now treats all block arguments as local assignments inside the block and shadows any variables outside the block (this is Ruby 1.9 behavior). This should lead to some performance improvements where block arguments do shadow outer variables.

(changes and examples)

Sexp Hash Cache Invalidation

Since Brakeman does a ton of hash table lookups with s-expressions as keys, it caches Sexp#hash values. In some situations, these cached values were being invalidated when they did not need to be, and not being invalidated when they should have been.

(changes)

Quiet Option

Brakeman will now be quiet if the option is set in a configuration file.

(changes)

Assignments of If Expressions

Simple if expression assigments such as x = thing ? this : that will now be converted to x = this || that. This should simplify some code reported with warnings as well as avoid warning on values in if conditions.

(changes and examples)

Assignments in If Expressions

Assignments inside if branches cause Brakeman to “branch” the values for a variable, since it could be two or more different values. However, this branching should only occur after both branches have been processed. Brakeman 1.9.3 made it so values were not branched inside of a single branch, but there was still an issue where values branched in the then clause would be used in the else clause. This release fixes that issue and simplifies branching overall.

(changes and examples)

Refactoring Internals

Bart ten Brinke has begun some work refactoring some of the many ugly parts of Brakeman. Thanks!

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.

Roadmap

Next up should be Brakeman 2.0 unless there needs to be another emergency release. Most of the changes for 2.0 are relatively minor, but break backwards compatibility in areas that may affect external tools. This includes cleaning up warning messages, removing duplicate information from JSON output, combining some checks, changing some defaults, and so on.

If you have suggestions for other breaking changes, please file an issue ASAP to get it into the next release!

Another release forced out early due to Rails vulnerabilities reported today.

Changes since 1.9.3:

• Add check for CVE-2013-1854
• Add check for CVE-2013-1855
• Add check for CVE-2013-1856
• Add check for CVE-2013-1857
• Fix --compare to work with older versions
• Add “no-referrer” to HTML report links
• Don’t warn when invoking send on user input
• Slightly faster cloning of Sexps
• Detect another way to add strong_parameters (#288)

Latest Reported Vulnerabilities

All CVE checks were included in these changes.

CVE-2013-1854 - Symbol Denial of Service

CVE-2013-1854 is the creation of symbols when a hash is passed as the value to an ActiveRecord finder method.

Brakeman will warn on this CVE if there are any models using ActiveRecord and the Rails version is vulnerable.

CVE-2013-1855 - sanitize_css

CVE-2013-1855 is a vulnerability in the sanitize_css method.

Brakeman will warn on this CVE for each use of sanitize_css if the Rails version is vulnerable. Calls obviously sanitizing user input will be high confidence, other calls will be medium confidence.

CVE-2013-1856 - JRuby XML Parser

CVE-2013-1856 is a vulnerability in the default XML parser used when running Rails on JRuby.

Brakeman will warn on this CVE if run with JRuby and the Rails version is vulnerable. It will not warn if the provided workaround (not patch) is used in an initializers.

CVE-2013-1857 - sanitize

CVE-2013-1857 is a vulnerability in the sanitize method which allows URLs to include JavaScript.

Brakeman will warn on this CVE for each use of sanitize if the Rails version is vulnerable. Calls obviously sanitizing user input will be high confidence, other calls will be medium confidence.

Fix JSON Compare

The 1.9.3 release introduced several new keys for warnings in the JSON output, which then broke --compare when used with output from an older version. Despite declaring this would not be fixed, it has been fixed. --compare reverts to old behavior if a report is from an older version.

(changes)

Remove Referrer from HTML Report Links

All warning type links HTML reports now include the rel="no-referrer" option. This prevents referrer information from being passed along to the linked site (usually the Brakeman site), which means people won’t see that you are putting your Brakeman reports on the open internet…

(changes)

Fewer Dangerous Send Warnings

Now that Brakeman warns on dangerous uses of constantize and friends, there is no reason to warn on uses of send, try, etc. with user input as a target. User input for the method name will continue to warn.

For example, this will no longer generate a warning:

params[:name].try(:downcase)

(changes)

Faster Sexp Cloning

Brakeman spends a lot of time cloning Sexps, so this version introduces a slightly faster custom method instead of Marshal.load(Marshal.dump(...)).

(changes)

Another Strong Paramter Initializer

Brakeman now detects this approach to adding the strong_parameters functionality:

ActiveRecord::Base.send(:include,  ActiveModel::ForbiddenAttributesProtection)

(changes)

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.

Roadmap

This unexpected release means the roadmap has shifted again. The roadmap still has one more release (1.9.5) planned before 2.0. The next release will likely only include bug and false positive fixes. Again, Brakeman 2.0 will definitely include breaking changes, especially for JSON reports.

Changes since 1.9.2:

• Add warning fingerprints
• Add check for unsafe reflection (Gabriel Quadros)
• Add support for Slim templates (#214)
• Add check for skipping authentication methods with blacklist (#199)
• Add render path to JSON report
• Remove empty tables from reports (Owen Ben Davies)
• Handle prepend/append_before_filter
• Performance improvements when handling branches
• Fix processing of production.rb (#264)
• Fix version check for Ruby 2.0
• Expand HAML dependency to include 4.0 (#263)
• Scroll errors into view when expanding in HTML report

Warning Fingerprints and New Identifiers

This is a breaking change: brakeman --compare will not work with reports generated from earlier versions.

Tracking of new and fixed warnings is often required when integrating Brakeman with other tools. Current approaches rely on fragile values such as the warning messages or formatting of the code output.

Additionally, warnings are grouped into large categories, such as “SQL Injection”. Sometimes more fine-grained categorization is required that does not rely on a value intended for display that may need to changed.

With these two issues in mind, warnings now have a “warning code” and a “fingerprint”. Warning codes are integers which will never change and provide more specific categorization of warnings. For example, each CVE has a separate code. This should make tracking and sorting warnings easier, but also allow for fixes to warning category names in the future.

The warning fingerprint is a SHA256 hash of five values:

• Warning code
• S-expression of code that caused the warning
• Location (i.e., template name or class/method)
• Relative file path
• Confidence level

Note that line numbers are not included. Identical warnings on different lines will have the same fingerprint. External tools can make the decision for how to handle this situation.

Warning fingerprints allow quick comparison of warnings (either by fingerprint, or fingerprint + line number) but are also less fragile than existing approaches. The fingerprint will not change if the warning category (meant for display) changes, if the formatting of the code changes, or if the line number changes (e.g., some blank lines are added at the top of a file).

If there are any issues with fingerprints, please report them before Brakeman 2.0!

(changes)

Check for Unsafe Constant Creation

Gabriel Quadros has contributed a check for methods that create constants (usually classes) from user input. His blog post on the subject provides a good explanation of why this should be considered very dangerous.

(changes)

Support for Slim

Support for templates using Slim is now here! This should be considered experimental, as it has not yet been tested on a wide set of applications. Also, thanks tubaxenor for reporting a require issue with this change.

Please report any issues, especially false negatives!

(changes)

Check for Skipping of Authentication Methods

The check for skip_before_filters using except instead of only has been expanded to include authentication filters from popular libraries.

(changes)

Render Paths in JSON Reports

In HTML reports, templates which have a render path longer than one entry have been “expandable” to show the entire render path instead of just one level up. For example, a partial is usually rendered from a view, which is rendered from a controller action.

JSON reports now also include this information in the render_path value.

(changes)

No Empty Report Tables

Owen Ben Davies contributed a patch to hide empty warning tables in the text and HTML reports. Looks much cleaner, thanks Owen!

(changes)

Handle (Pre|Ap)pended Filters

Brakeman will now recognize before filters added with prepend_before_filter and append_before_filter.

(changes)

Branching Performance Improvements

It is entirely embarrassing, but Brakeman stopped working on Redmine some time ago due to how assignments in if expressions are handled.

In order to be somewhat flow sensitive, Brakeman combines variables assignments in if branches into or expressions. This captures the possible values a variable may have. However, Brakeman was doing that for every assignment in an if branch, even if there were multiple assignments to the same variable in the same branch (i.e., the value was not actually branching since the assignments were sequential). This release fixes that issue.

Additionally, simple arithmetic operations are now distributed across or expressions containing simple values (strings or numbers at this point), providing some memory savings.

(changes)

Fix Processing of Production Environment Settings

Processing of production.rb has been broken for some time, but poor test coverage meant it went unnoticed. But it is fixed now, so settings in production.rb should override those found in environment.rb. This only applies to Rails 3 applications.

(changes)

Fix Version Check for Ruby 2.0

Brakeman appears to work fine with Ruby 2.0, but the version check for Ruby 1.9 (which affected some behavior and checks) needed to be modified to include 2.0. Definitely report any issues with Ruby 2.0!

(changes)

Allow HAML 4.0

There appear to be no changes in HAML 4.0 that affect Brakeman, so the gem dependency has been expanded to include the 4.x series.

(changes)

Fix Error Show/Hide in HTML Report

Now clicking on “Exceptions” to show or hide scan errors will keep the errors in view.

(changes)

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.

Roadmap

The Brakeman roadmap has one more release (1.9.4) planned before 2.0. The next release will likely only include bug and false positive fixes. Brakeman 2.0 will definitely include breaking changes, especially for JSON reports.

This release is almost entirely enhancements to old checks or new checks for recent vulnerabilities. New features in the next release, I promise.

Changes since 1.9.1:

• Add check for CVE-2013-0269
• Add check for CVE-2013-0276
• Add check for CVE-2013-0277
• Add check for CVE-2013-0333
• Check for more send-like methods (joernchen)
• Check for more SQL injection locations
• Check for more dangerous YAML methods (#246)
• Support MultiJSON 1.2 for Rails 3.0 and 3.1 (#247)

CVE-2013-0269 - Vulnerabilities in JSON gems

CVE-2013-0269 is not strictly a Rails issue, but since it was announced on the Rails security list and was relatively easy to check, Brakeman will warn on it.

Versions of the json/json_pure gem on the 1.7.x branch will raise remote code execution warnings, while any other affected version will be reported as a denial of service vulnerability.

Applications which do not parse user input are not affected by these issues, but it is a good idea to upgrade anyway, as it should be relatively painless.

(changes)

CVE-2013-0276 - attr_protected Bypass

Brakeman has been warning on uses of attr_protected since version 1.4.0, but it was reported with weak confidence, since it is really a best-practice issue.

Now, however, uses of attr_protected will be reported as medium confidence unless used in a Rails version affected by CVE-2013-0276, in which case it will be high confidence.

(changes)

CVE-2013-0277 - Serialized Attributes

CVE-2013-0277 allows attackers to insert malicious YAML into serialized model attributes. Using attr_accessible or attr_protected somewhat mitigates this, but it is still possible for an application to manually assign user input to a serialized attribute.

Brakeman will warn on affected models, with confidence level depending on whether or not the attribute can be mass assigned.

(changes)

CVE-2013-0333 - JSON Parsing Vulnerability

CVE-2013-0333 is another side effect of the recent YAML vulnerabilities. Rails’ default JSON request parser converted requests to YAML then parsed them as YAML.

Brakeman will warn on affected versions unless the provided workaround (setting the JSON backend to JSONGem) is present.

(changes)

Check for More Send-like Methods

Thanks to joernchen, Brakeman will now warn if user input is passed to try, public_send, or __send__.

(changes)

Check for More SQL Injection Sites

While researching for rails-sqli.org, a few more methods came up for Brakeman to check.

Brakeman will now warn on SQL injection in update_all and pluck methods.

Check for More Dangerous YAML Methods

Brakeman will now warn on dangerous uses of load_documents, load_stream, parse_documents, and parse_stream.

(changes)

Support MultiJSON 1.2

The MultiJSON gem changed some APIs around version 1.3. For convenience, Brakeman supported 1.3 or higher. However, for the same reason, Rails 3.0 and 3.1 are locked at versions before 1.3.

For those using Rails 3.0 or 3.1 and including Brakeman in the Gemfile, Brakeman now supports both the old and new interfaces for MultiJSON and the depedency has been pushed back to MultiJSON 1.2.

(changes)

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.

Finally, please check out rails-sqli.org and send in any feedback. Thanks!

This released was forced due to messed up dependencies with Brakeman 1.9.0 and Ruby2Ruby - my fault entirely! As such, this release does not match the roadmap for 1.9.1, which will be changed to 1.9.2.

Changes since 1.9.0:

• Add check for CVE-2012-5664 - SQL Injection
• Add check for CVE-2013-0155 - SQL Injection
• Add check for CVE-2013-0156 - Remote Code Execution
• Add check for unsafe YAML.load
• Update to RubyParser 3.1.1 (neersighted)
• Remove ActiveSupport dependency (Neil Matatall)
• Do not warn on arrays passed to link_to (Neil Matatall) (#232)
• Warn on secret tokens (#200)
• Warn on more mass assignment methods (#223)

CVE-2012-5664 - SQL Injection

CVE-2012-5664 is a vulnerability Rails’ dynamic finders. While dynamic finders (such as User.find_by_name) appear to take a single argument, they also accept a hash options which can be used to modify the SQL query. Normally the hash of options would be the second argument, but it can also be the first. If an application passes in user code as the first argument, it will be interpreted as the options hash, leading to SQL injection.

The provided fix is to only accept the hash if the dynamic finder is called with the proper number of arguments. A workaround is to always cast input to dynamic finders.

(changes)

CVE-2013-0155 - SQL Injection

CVE-2013-0155 is a SQL vulnerability where certain JSON input can cause find methods to add NULL as a valid value.

(changes)

CVE-2013-0156 - Remote Code Execution

CVE-2013-0156 is the worst Rails vulnerability in recent memory. It allows attackers to easily execute arbitrary code on any Rails application.

Besides upgrading Rails, there are workarounds for this issue: disable XML request parsing or disable YAML/symbol types inside XML requests.

Exploits for this vulnerability are easily available and already in use in the wild. Please upgrade, patch, or use a workaround.

(changes)

Check for YAML.load

In light of CVE-2013-0156, Brakeman will now warn on any uses of YAML.load with user input. Do not load arbitrary YAML in applications!

Dependency Changes

Brakeman now uses the latest RubyParser and Ruby2Ruby versions.

Thanks to Neil, Brakeman no longer depends on any version of ActiveSupport or i18n.

Namespaced URLs in link_to

Brakeman will no longer warn on array arguments to link_to.

(changes)

Secret Tokens

Secret tokens stored in source control are bad! Doubly bad if the source code is available publicly. Anyone with access to an application’s secret token can generate any session cookies they would like. See this post for details.

(changes)

More Mass Assignment

Bryan Helmkamp pointed out more Rails methods which perform mass assignment. The following methods have been added: first_or_create, first_or_create!, first_or_initialize!, assign_attributes, and update.

(changes)

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.

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.

This is primarily a false positive reduction release. One major change is the change in dependency from the json_pure gem to multi_json.

Changes since 1.8.2:

• Use multi_json gem for better harmony (#164)
• Performance improvement for call indexing
• Fix issue with processing HAML files (#168)
• Handle pre-release versions when processing Gemfile.lock (#174)
• Only check first argument of redirect_to (#98)
• Fix false positives from Model.arel_table accesses
• Fix false positives on redirects to models decorated with Draper gem (#172)
• Fix false positive on redirect to model association (#111)
• Fix false positive on YAML.load (#142)
• Fix false positive XSS on any to_i output
• Fix error on Rails 2 named routes with no args
• Fix error in rescan of mixins with symbols in method name
• Do not rescan non-Ruby files in config/

Change to MultiJSON

Brakeman now depends on the multijson gem instead of json_pure. This should make it easier for people who include Brakeman as a dependency.

(changes)

Faster Call Indexing

Dumb code in the CallIndex was causing call indexing to be slow on some large applications. This should now be faster and require less memory!

(changes)

Fix HAML Processing

Some HAML files were causing Brakeman’s alias processing to slow to a crawl. This was due to the template code (sometimes) directly appending to the output variable via <<. Since Brakeman attempts to treat targets of << as arrays, Brakeman was generating large data structures each time << was encountered.

(changes]

Handle Pre-release Versions

When a Gemfile.lock file is present in a Rails application, Brakeman uses it to determine the version of Rails in use. Previous versions did not accept pre-release version numbers (like 3.1.2.rc1), leading to version inappropriate warnings.

(changes)

Redirect False Positives

Several false positives related to redirects have been fixed, and the scope of the redirect check is somewhat reduced.

Calls beginning with Model.arel_table should no longer be treated as user input (in any context).

Model instances returned by the decorate method in the Draper gem are considered safe.

Redirects to model associations (e.g, belongs_to :account) are considered safe.

Redirects to method calls with safe values should no longer warn. For example:

redirect_to blah(User.first) #No warning

Additionally, only the first argument of redirect_to will be checked for user input.

(changes)

YAML False Positive

File access warnings for YAML calls have been reduced to only those calls which actually access files.

(changes)

Integer Output False Positives

Calls to to_i should not trigger XSS warnings.

(changes)

Errors on Named Routes

Rails 2 named routes with no arguments were causing errors, which have now been fixed.

(changes)

Future Work

Now that RubyParser 3.x is officially released, work is underway to use the new version. This will increase Ruby 1.9 syntax compatibility and remove the need to parse applications with the same Ruby version as the application uses. Additionally, it will allow us to get rid of the vendored version of RubyParser that Brakeman uses for Ruby 1.9. Unfortunately, RubyParser 3.x introduces a lot of incompatibilities and upgrading requires a significant amount of effort.

Another exciting feature in development is limited interprocedural analysis. Brakeman will be able to handle simple things like calls to helper methods in controllers which set instance variables or return user input. This should help with the “obvious” vulnerabilities that Brakeman often misses.

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.

This is a bugfix release, in particular fixing rescanning (used by guard-brakeman).

Changes since 1.8.1:

• Fixed rescanning problems caused by 1.8.0 changes
• Fix scope calls with single argument
• Report specific model name in rendered collections
• Handle overwritten JSON escape settings (Neil Matatall)
• Add CHANGES to gemspec

Rescan Fixes

Brakeman supports rescanning a subset of files in an application, with the caveat that the previous scan must still be in memory. This functionality was broken in the the 1.8.0 release, due to the lack of tests.

This release updates rescanning to be more robust and work with the 1.8.0 changes to how “render paths” are stored. Also, a number of tests were added to help prevent breakage in the future.

(changes)

Scope Calls with One Argument

Calls to scope with a single argument were causing errors in Brakeman’s SQL injection check.

The fixed error looked like:

undefined method `node_type' for nil:NilClass  /something/brakeman/lib/brakeman/checks/check_sql.rb:75:in `block (2 levels) in find_scope_calls'

(changes)

Model Names for Rendered Collections

In cases like below, where a collection of models is being rendered and the model name could be known, any resulting warnings will now reference the actual model name.

<%= render 'user', :collection => User.all %>

Previously, Brakeman would report warnings with UnknownModel, whether or not the model name was actually known.

(changes)

Overwritten JSON Escape Config

It is possible that a config setting in one initializer overrides a setting in a different initializer. This is now handled for the JSON escape settings.

(changes)

CHANGES File in Gem

The CHANGES file is now included in the gem file as requested.

(changes)

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.

Brakeman Roadmap

A rough guide to Brakeman 1.9 and 2.0 has been posted here.

Bug fixes!

Changes since 1.8.0:

• Recover from errors in output formatting (#148)
• Fix false positive in redirect_to (Neil Matatall) (#143)
• Fix problems with removal of Sexp#method_missing (#150)
• Fix array indexing in alias processing (#145)
• Fix old mail_to vulnerability check (#147)
• Fix rescans when only controller action changes (#141)
• Allow comparison of versions with unequal lengths (#144)
• Handle super calls with blocks (#146)
• Remove malformed Sexps from HAML processing (#149)
• Respect -q flag for “Rails 3 detected” message

Fix Crashes when Generating Report

Some scans were causing Brakeman to crash while generating reports with an error like:

lib/brakeman/warning.rb:78:in `format_code': undefined method `gsub' for nil:NilClass (NoMethodError)

This was due to a combination of the removal of method_missing behavior from Sexp and the OutputProcessor not handling errors well.

The problem should be fixed now, but please report an issue if “[Format Error]” shows up in reports.

False Positive in Redirect Check

Neil Matatall fixed an issue with a false positive when redirecting to an array.

When redirect_to is given an array, Rails eventually falls through to polymorphic_path, which will only return a path, not a full URL. Brakeman only checks for redirects that can redirect to a different host, so this is considered safe.

Sexp and method_missing

The original Sexp code from RubyParser uses method_missing to find and optionally delete nodes. This functionality is not used very often (never in Brakeman) but has covered up bugs that would otherwise been found. Therefore, Sexp#method_missing has been removed in Brakeman. However, it turns out that Ruby2Ruby uses it in a couple places. Brakeman uses Ruby2Ruby to covert s-expressions back to readable Ruby code, particularly when generating reports. This lead to some crashes.

Fix Array Indexing

Brakeman can handle pulling values out of simple arrays. Or it should be able to, but it keeps breaking. Should be fixed now!

Fix mail_to Check

There is a Brakeman check for an old vulnerability in mail_to. However, it turns out this check has been broken for a while. But now it is fixed! And there are regression tests.

Fix Rescans on Controller Changes

There were some crashes when rescanning was triggered by a controller change.

HAML Processing

Some very old code for HAML processing was generating malformed s-expressions, which then had to be handled specially in the output formatter. It turns out these nodes were not even used, so they were removed. Please report any problems arising from this! We do not have a lot of HAML test cases.

Report Issues

Please report any issues with this release!

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

Changes since 1.7.1:

• Support relative paths in reports (fsword)
• Allow Brakeman to be run without tty (fsword)
• Fix exit code with --compare (fsword)
• Fix --rake option (Deepak Kumar)
• Add high confidence warnings for to_json XSS (Neil Matatall)
• Fix redirect_to false negative
• Fix duplicate warnings with raw calls
• Fix shadowing of rendered partials
• Add “render chain” to HTML reports
• Add check for XSS in content_tag
• Add full backtrace for errors in debug mode
• Treat model attributes in or expressions as immediate values
• Switch to method access for Sexp nodes

Relative Paths in Reports

The --relative-paths option will now cause Brakeman to output relative paths for warnings in reports in either JSON or tabs format. This is useful when comparing reports run on different machines or just in different directories.

Brakeman without TTY

Thanks to fsword, Brakeman can now run without a TTY available.

Exit Code for Compare

Also thanks to fsword, Brakeman will return a proper exit code when run with -z --compare. If any changes are found, the exit code will be nonzero.

Rake Task Generation Fixed

The --rake option was broken, but Deepak Kumar noticed and fixed it!

High Confidence Warnings for JSON

Older versions of Rails default to not escaping to_json calls, leading to cross site scripting problems. Since Rails 2.1.0, Rails has provided an option to escape JSON output by default. Brakeman will check this option, and warn on unescaped to_json calls.

Fix Redirect False Negative

Brakeman was incorrectly checking for :only_path => true in any argument to redirect_to. However, it is only valid as part of the first argument.

Fix Duplicate Warnings on Raw Calls

A logic mistake sometimes caused a high and weak confidence warning to be reported for the same code using raw. This has been fixed.

Fix Shadowing of Rendered Partials

Due to the way Brakeman was storing rendered partials, a view that was rendered multiple times via different code paths would only store a single instance of the rendered view. This could result in some vulnerabilities not being reported.

To fix this, Brakeman now stores the entire “render chain” (that is, each location of a render). This ensures a unique key for each rendered template.

Report Render Chain in HTML

HTML reports now have a new feature that reports the “render chain” for view warnings (if the chain is more than a single call deep).

A warning like this:

Might expand to show this chain:

Check for XSS in content_tag

content_tag is a view helper for generating HTML tags containing some content. In Rails 2.x, content_tag did not escape this content. In Rails 3.x, this changed so that now it is escaped. While content_tag does have an escape parameter (true by default), this only applies to the tag attribute values.

Brakeman now warns on possible cross site scripting via content_tag calls. See here for more details.

Backtraces in Debug Mode

By default, Brakeman tries its best to recover from errors and produce a report. However, this can sometimes make it difficult to track down the sources of errors. Now, with the -d option, Brakeman will report backtraces for errors encountered while running, as well as including backtraces in HTML reports.

Convenience Methods for Sexp Access

Previously, all code dealing with s-expressions in the Sexp class accessed nodes via array access, e.g. exp[1] or exp[2]. This led to hard-to-read code like exp[2][3][1][1..-1]. This release includes convenience methods to replace those types of calls. Available methods are documented here.

Hopefully this leads to code that is both easier to read and easier to write.

Reporting Problems

This release touches a lot of code (76 changed files with 1,515 additions and 598 deletions), so there is ample opportunity for bugs to sneak in. Please report any issues!

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