While the step up to 1.0 was essentially forced by major changes since 0.9.2, this is still an important release for Brakeman. Internally, Brakeman is no longer reliant on a global options variable, allowing it to be used as a library inside other applications. Also, all Brakeman modules, classes, and constants have been placed inside the Brakeman namespace.
Support for Rails 3 is continuing to improve, although it is probably a good idea to run Brakeman with the -m
option to see what routes it is seeing. If you receive a message that says “Error while processing routes - assuming all public controller methods are actions,” please consider opening an issue and (if possible) providing your routes.rb
file as evidence.
The performance of vulnerability checks that search for calls to specific methods (CheckExecute, CheckFileAccess, CheckSQL, etc.) has been drastically improved with the introduction of a call site index. If your scans were spending a lot of time running checks, you should see significant decrease in run time (although memory use may be slightly higher).
If you are looking for an introduction to Brakeman, there are some presentations available to watch or read.
As usual, please report any issues! You can also send a tweet to @Brakeman if you have any questions.
Changes since 1.0rc1:
- Better handling of assignments inside ifs
- Check more expressions for SQL injection
- Use latest ruby_parser for better 1.9 syntax support
- Better behavior for Brakeman as a library
Assignments Inside ‘if’ Branches
Brakeman is now a little smarter about handling assignments inside if
.
For example:
if some_condition
x = params[:blah]
else
x = "no blah"
end
Previously, x
would end up with the last value encountered, with no regard for execution branches. In this release, Brakeman will now combine the branches (unfortunately, Brakeman still operates along a ‘no branching’ policy) and x
will be given the value of params[:blah] or "no blah"
.
While not strictly semantically sound (and, trust me, Brakeman does many things that are not), it will still catch problems like
User.all(conditions => "blah = '#{x}'")
Thanks to this message on Rails Core for mentioning this problem.
Use Latest ruby_parser
A few releases ago, Brakeman included a slightly modified version of ruby_parser to help with Ruby 1.9 syntax issues.
The very latest ruby_parser source has much better 1.9 support, but there has been no official release yet. So Brakeman comes with the latest code. This is necessary because Rails 3 will generate 1.9 syntax if you happen to run it with Ruby 1.9 when generating code.
Brakeman as a Library
While it is now possible to use Brakeman as a library (essentially just Brakeman.run
), it is not very well polished. This release improves it slightly from the release candidate.
More SQL Injection
CheckSQL
will now search most expressions inside a SQL call for user input and string interpolation.
Changes Since 0.9.2
As a summary, here are the changes since 0.9.2:
- Brakeman can now be used as a library
- Faster call search
- Add option to return error code if warnings are found (tw-ngreen)
- Allow truncated messages to be expanded in HTML
- Keep expanded context in view in HTML output
- Fix summary when using warning thresholds
- Better support for Rails 3 routes
- Reduce SQL injection duplicate warnings
- Lower confidence on mass assignment with no user input
- Ignore mass assignment using all literal arguments
See the earlier post for more details.