Mass assignment is not restricted using attr_accessible Open
class Context < ApplicationRecord
- Read upRead up
- Exclude checks
This warning comes up if a model does not limit what attributes can be set through mass assignment.
In particular, this check looks for attr_accessible
inside model definitions. If it is not found, this warning will be issued.
Brakeman also warns on use of attr_protected
- especially since it was found to be vulnerable to bypass. Warnings for mass assignment on models using attr_protected
will be reported, but at a lower confidence level.
Note that disabling mass assignment globally will suppress these warnings.
Possible SQL injection Invalid
scope :with_name, lambda { |name| where("name " + Common.like_operator + " ?", name) }
- Read upRead up
- Exclude checks
Injection is #1 on the 2013 OWASP Top Ten web security risks. SQL injection is when a user is able to manipulate a value which is used unsafely inside a SQL query. This can lead to data leaks, data loss, elevation of privilege, and other unpleasant outcomes.
Brakeman focuses on ActiveRecord methods dealing with building SQL statements.
A basic (Rails 2.x) example looks like this:
User.first(:conditions => "username = '#{params[:username]}'")
Brakeman would produce a warning like this:
Possible SQL injection near line 30: User.first(:conditions => ("username = '#{params[:username]}'"))
The safe way to do this query is to use a parameterized query:
User.first(:conditions => ["username = ?", params[:username]])
Brakeman also understands the new Rails 3.x way of doing things (and local variables and concatenation):
username = params[:user][:name].downcase
password = params[:user][:password]
User.first.where("username = '" + username + "' AND password = '" + password + "'")
This results in this kind of warning:
Possible SQL injection near line 37:
User.first.where((((("username = '" + params[:user][:name].downcase) + "' AND password = '") + params[:user][:password]) + "'"))
See the Ruby Security Guide for more information and Rails-SQLi.org for many examples of SQL injection in Rails.
NullContext has no descriptive comment Open
class NullContext
- Read upRead up
- Exclude checks
Classes and modules are the units of reuse and release. It is therefore considered good practice to annotate every class and module with a brief comment outlining its responsibilities.
Example
Given
class Dummy
# Do things...
end
Reek would emit the following warning:
test.rb -- 1 warning:
[1]:Dummy has no descriptive comment (IrresponsibleModule)
Fixing this is simple - just an explaining comment:
# The Dummy class is responsible for ...
class Dummy
# Do things...
end
Context has no descriptive comment Open
class Context < ApplicationRecord
- Read upRead up
- Exclude checks
Classes and modules are the units of reuse and release. It is therefore considered good practice to annotate every class and module with a brief comment outlining its responsibilities.
Example
Given
class Dummy
# Do things...
end
Reek would emit the following warning:
test.rb -- 1 warning:
[1]:Dummy has no descriptive comment (IrresponsibleModule)
Fixing this is simple - just an explaining comment:
# The Dummy class is responsible for ...
class Dummy
# Do things...
end