RoR Patching
Vulnerabilities
XSS, SQL injection, session hijacking, and data tampering, standard web-application vulnerabilities afflict Ruby on Rails. One more less commonly known or used vulnerability is called Mass Assignment Abuse.
XSS
Standard XSS is possible. session hijacking via cookies is possible. Be sure to sanitize your database inputs as well as your cookies for XSS.
vulnerable code :
<%= comment.content %> <%= sanitize(comment.content) %> |
patched code :
<%= h(comment.content) %> |
on output OR
[[CGI]]::escapeHTML(user_input) |
on input.
The code below :
<%= comment.content %> <%= sanitize(comment.content) %> |
Is vulnerable because it only strips HTML tags. It does not save your program from javascript injection. The h() function does.
Params Injection & Mass Assignment Abuse
Params can't be trusted, SQL injection may take place still, but is rare in Ruby on Rails. It can be fuzzed for just like any other SQL injection vulnerability.
params injection : curl can be used for posting and can specify params. example hash manipulation :
$ curl -d "user[name]=hacker&user[admin]=1" server:port/users |
vulnerable code :
@user=User.new(params[:user]) |
patched code :
attr_protected :admin
|
Best patch :
attr_accessible :user
|
More vulnerable code:
has_many :comments
|
use curl to repossess comments or posts. example :
$ curl -d "user[name]=hacker&user[admin]=1&user[comment_ids][]=1&user[comment_ids][]=2" server:port/users |
best fix is white-listed input. To make it so that only the user[name] param is read by ActiveRecord, change :
attr_protected :admin
|
To:
attr_accessible :name
|
This will make it so that only the name attribute matters to activerecord when params is passed to the sql query. Now, activerecord will not pay attention to any other values set inside of the params[ ] hash.
<center>
