Rails' Insecure Defaults

Rails’ Insecure Defaults Bryan Helmkamp @brynary

Insecure by default is insecure.

@brynary True or false? “Rails is secure by default.”

@brynary Rails’ Secure Defaults • SQL Generation (SQLi) • Cross-site
Request forgery (CSRF) • HTML Sanitization (XSS)

Let’s Talk About Insecure Defaults

Warm Ups

@brynary Verbose Server Header Still risky in master

@brynary HTTP/1.1 200 OK Last-Modified: Sun, 10 Mar 2013 18:32:18
GMT Content-Type: text/html Content-Length: 5906 Server: WEBrick/1.3.1 (Ruby/1.9.3/2012-04-20) Date: Tue, 12 Mar 2013 18:08:41 GMT Connection: Keep-Alive

@brynary 2012-04-20 == p194

@brynary Who cares? • Exposes Ruby patchlevel • Spray and
prey scanners • Tailor attack payload • Avoid setting oﬀ any alerts

@brynary Best Practice • Avoid WEBrick in production • Use
Passenger, Unicorn, Thin or Puma • Heroku users: WEBrick is the default

@brynary Proposed Fix • Rails conﬁgures WEBrick to use a
less verbose Server header

@brynary Binds to 0.0.0.0 Still risky in master

@brynary Who cares? • Production data loaded onto laptop •
San. Francisco. Coﬀee. Shops. • IP forgery

@brynary Best Practice • Use -b option to bind to
127.0.0.1 • Avoid loading real data into development environments • If you must, delete it as soon as you’re done

@brynary Proposed Fix • Change default conﬁguration to bind to
127.0.0.1 only

@brynary Logging SQL Values Still risky in master

@brynary Started POST "/users" for 127.0.0.1 at 2013-03-12 14:26:28 -0400
Processing by UsersController#create as HTML Parameters: {"utf8"=>"✓œ“", "authenticity_token"=>"...", "user"=>{"name"=>"Name", "password"=>"[FILTERED]"}, "commit"=>"Create User"} (0.1ms) begin transaction SQL (7.2ms) INSERT INTO "users" ("created_at", "name", "password_digest", "updated_at") VALUES (?, ?, ?, ?) [["created_at", Tue, 12 Mar 2013 18:26:28 UTC +00:00], ["name", "Name"], ["password_digest", "$2a$10$r/ XGSY9zJr62IpedC1m4Jes8slRRNn8tkikn5.0kE2izKNMlPsqvC"], ["updated_at", Tue, 12 Mar 2013 18:26:28 UTC +00:00]] (1.1ms) commit transaction Redirected to http://localhost:3000/users/1 Completed 302 Found in 91ms (ActiveRecord: 8.8ms)

@brynary Who cares? • Database gets sensitive values, like params
• ﬁltered_params_logging doesn’t apply • Production log level turned up to debug

@brynary Best Practice • Be aware of what you’re logging
in production • If you must increase the log level temporarily, remove that data when it’s no longer needed

@brynary Possible Solutions • Introduce config.filter_logs and filter SQL values
when possible • Redact entire SQL statement if it contains any references to filtered fields

Risky Business

@brynary Versioned Secret Tokens Still risky in master

@brynary Who cares? • Secret token == application root key
• Encryption is only as good as key management

@brynary Best Practice • Use a diﬀerent secret token in
production • Inject secrets in ENV vars (Heroku, envdir) • Or symlink secret_token.rb on deploy

@brynary Proposed Fix • Minimum: Git-ignore secret_token.rb in generated app
skeleton • Better: Introduce a “secret store” to solve this problem for the Rails ecosystem

@brynary Oﬀsite redirect_to Still risky in master

@brynary class SignupsController < ApplicationController def create # ... if
params[:destination].present? redirect_to params[:destination] else redirect_to dashboard_path end end end

@brynary Who cares? • Phishing • Send user to malicious
site • Looks like you sent them there • OWASP Top 10 Critical Web Application Security Risks #A10

@brynary Best Practice • When passing a hash to redirect_to
use the “only_path: true” option • When passing a string, extract the path via URI.parse

@brynary Proposed Fix • Rails should only allow redirects within
the same domain by default • Add an “external: true” option to opt-in to unsafe behavior

@brynary #link_to with JavaScript Still risky in master

@brynary <%= link_to "View public site", user.public_site_url %> <a href="javascript:alert('hi')">View
public site</a> becomes

@brynary Who cares? • Not immediately obvious you can put
JavaScript in there • Cross-site scripting (XSS) risk

@brynary Best Practice • Don’t allow unsafe input to control
HREFs • Run the input through URI.parse and sanity check protocol and host

@brynary Proposed Fix • Rails should only allow http://, https://
and mailto: HREFs by default • Developers can opt-in to risky behavior with a new option

@brynary SQL Injection Still risky in master

Rails is not a SQLi silver bullet

#pluck

@brynary params[:column] = "password FROM users--" Order.pluck(params[:column]) SELECT password FROM
users-- FROM "orders" becomes

@brynary becomes params[:column] = "age) FROM users WHERE name =
'Bob';" Order.calculate(:sum, params[:column]) SELECT SUM(age) FROM users WHERE name = 'Bob';) AS sum_id FROM "orders"

Aﬀected APIs • #calculate • #delete_all • #destroy_all • #exists?
• #ﬁnd • :from • :group • :having • .pluck • .order • .reorder • etc. @brynary

@brynary http://rails-sqli.org

@brynary Who cares? • You. It’s SQL injection. :) •
Not obvious which APIs are vulnerable • Some APIs violate Principle of Least Surprise and Least Privilege

@brynary Best Practices • Understand which APIs are dangerous •
Use the safest AR API possible for your operations • Whitelisted expected inputs (e.g. column names)

@brynary Proposed Fix • Only permit SQL fragments where they
are commonly used • Avoid attribute names that imply safety improperly • Provide alternative, more-risky APIs for less common cases

@brynary YAML Serialization Still risky in master

@brynary class User < ActiveRecord::Base # ... serialize :preferences store
:theme, accessors: [ :color, :bgcolor ] end

@brynary YAML is #eval in disguise Lesson learned on January
8th, 2013. Never forget.

@brynary It’s fucking #eval

@brynary Would you store Ruby in your database and #eval
it?

@brynary Who cares? • Looks safe to the untrained eye
• Obvious today, but what about someone who learns Rails tomorrow? • Springboard database injection into full scale site ownage • Least Privilege violation

@brynary Best Practices • Use JSON serialization instead of YAML
for #serialize and #store • Be cautious of storing YAML-encoded data in queues, caches, etc. • (Note: Ruby marshal-ed data has the same problems as YAML)

@brynary Proposed Fix • Change the default serialization format from
YAML to JSON • Provide YAML behavior as an option or extract into a Gem

@brynary Wrapping Up

@brynary Thank You @brynary https://codeclimate.com

@brynary One More Thing

@brynary http://RailsSecurity.com

Rails' Insecure Defaults

Rails' Insecure Defaults

More Decks by Bryan Helmkamp

Other Decks in Programming

Featured

Transcript