Rails Security

Above and beyond the defaults

kiskolabs.com

Ma#as Korhonen

• Twi%er: @ma-askorhonen.fi

• GitHub: ma-askorhonen

• Email: me@ma-askorhonen.fi

• Web: ma-askorhonen.fi

• Blog: randomerrata.com

I start too many side projects

Homebrew

No, not the package manager

beerstyles.co

An iOS app for

browsing beer style

guidelines

piranhas.co

Book price comparison

on the web and iOS

Disclaimers

I am not a cryptographer

I am not a white/grey/black hat hacker

I'm just a developer who wants to keep his

apps as secure as reasonably possible

On with the show

What's this talk about?

Mostly generic web applica*on

security (with some Rails specific

implementa6on details)

RISKS

“Why would anyone ever

hack my website?”

— straw man developer

Understand that the a+acks

affec/ng a large number of website

owners … are predominantly

automated.1

— Sucuri

1 h$ps://blog.sucuri.net/2015/02/why-websites-get-hacked.html

In our analyses, we have found that

it takes about 30 – 45 days for a

new website, with no content or

audience, to be iden7fied and added

to a bot crawler.1

— Sucuri

1 h$ps://blog.sucuri.net/2015/02/why-websites-get-hacked.html

“But there's nothing

valuable on my site”

— straw man developer

All websites have something of

value for a4ackers: reputa'on2

— Troy Hunt

2 h$ps://www.troyhunt.com/all-websites-have-something-of-value-for-a$ackers-reputa=on/

Every site on the

web is a target

Rails

Rails is a great base for a secure web

applica0on

Sane defaults

Rails's sane (security) defaults

• CSRF protec-on

• XSS protec-on

• Injec-on protec-on

• SQL

• HTML

• JavaScript

Rails's sane (security) defaults

• Default headers

• X-Frame-Options: SAMEORIGIN

• X-XSS-Protection: 1; mode=block

• X-Content-Type-Options: nosniff

Rails's sane (security) defaults

• Encrypted session store

• Encourages good development prac5ces

• has_secure_password (bcrypt hashed passwords)

• secrets.yml

• user inputs escaped by default

You get all this for “free” when you use Rails

• CSRF protec-on

• XSS protec-on

• Injec-on protec-on

• SQL

• HTML

• JavaScript

• Default headers

• X-Frame-Options

• X-XSS-Protection

• X-Content-Type-Options

• Encrypted session store

• Encourages good development prac-ces

• has_secure_password (bcrypt hashed passwords)

• secrets.yml

• etc

What more can we do?

HTTPS

I firmly believe that as web

developers it is our duty to use

HTTPS for everything possible

HTTPS: why?

Even if your site has “nothing valuable”, do you trust:

• every shady wifi hotspot a user might be using?

• all the world's ISPs

Beyond underhanded, Comcast and

other carriers are inser3ng their own

ads and no3fica3ons into their

customers’ data streams

— InfoWorld3

3 h$p://www.infoworld.com/ar4cle/2925839/net-neutrality/code-injec4on-new-low-isps.html

Google Inves+ga+on: Ad Injec+on Is

Infes+ng Millions of Devices

— Adver(singAge4

4 h$p://adage.com/ar1cle/digital/google-ad-injec1on-affec1ng-millions/305321/

HTTPS doesn't just provide privacy

and security, it also provides

integrity

Eventually, Chrome will show a Not

Secure warning for all pages served

over HTTP

— Eric Lawrence5

5 h$ps://developers.google.com/web/updates/2016/10/avoid-not-secure-warn

More technical reasons

• SSL/TLS is essen+ally mandatory with HTTP 2.0

• Some browser features are only available over HTTPS6

• Geoloca+on

• Service workers

• Fullscreen

• and others

6 h$ps://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/2LXKVWYkOus/gT-ZamfwAKsJ

Visitors to your site will blame you,

not the shady ISP/hotspot

How?

HTTPS: cer*ficates

• Let's Encrypt7 is your friend

• Free 90 day cer8ficates

• Automated verifica8on and renewal

• AWS Cer8ficate Manager8 is your friend on AWS

• Free cer8ficates for AWS services

• Including wildcard cer8ficates!

• Paid cer8ficates go for as liHle as $5/year (! ~70 rand)9

9 h$ps://www.ssls.com/

8 h$ps://aws.amazon.com/cer3ficate-manager/

7 h$ps://letsencrypt.org/

HTTPS: force_ssl is your friend

Rails.application.configure do

...

# Force all access to the app over SSL,

# use Strict-Transport-Security, and

# use secure cookies.

config.force_ssl = true

...

end

HTTPS: configura/on

Ubuntu 16.04 LTS, Rails 5.0, Ruby 2.4, Phusion Passenger 5.1

Everything seems fine and dandy

But is it?

Qualys SSL Labs10

SSL Server Test

10 h%ps://www.ssllabs.com

Ah, a B.

I mean it's not bad…

…but we can do be-er

This server supports weak Diffie-

Hellman (DH) key exchange

parameters. Grade capped to B.

Learn more

— SSL Report

Mozilla SSL Configura0on Generator11

11 h$ps://mozilla.github.io/server-side-tls/ssl-config-generator/

server {

listen 443 ssl http2;

listen [::]:443 ssl http2;

# certs sent to the client in SERVER HELLO are concatenated in ssl_certificate

ssl_certificate /path/to/signed_cert_plus_intermediates;

ssl_certificate_key /path/to/private_key;

ssl_session_timeout 1d;

ssl_session_cache shared:SSL:50m;

ssl_session_tickets off;

# modern configuration. tweak to your needs.

ssl_protocols TLSv1.2;

ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:...';

ssl_prefer_server_ciphers on;

# HSTS (15768000 seconds = 6 months)

add_header Strict-Transport-Security max-age=15768000;

# OCSP Stapling ---

# fetch OCSP records from URL in ssl_certificate and cache them

ssl_stapling on;

ssl_stapling_verify on;

## verify chain of trust of OCSP response using Root CA and Intermediate certs

ssl_trusted_certificate /path/to/root_CA_cert_plus_intermediates;

resolver <IP DNS resolver>;

....

}

TADA !

One more thing: HSTS preload12

12 h%ps://hstspreload.org/

HSTS preload

1. Serve a valid cer+ficate.

2. Redirect from HTTP to HTTPS on the same host

3. Serve all subdomains over HTTPS.

4. Serve an HSTS header on the base domain for HTTPS requests

CSPContent Security Policy

Content Security Policy is an added

layer of security that helps to detect

and mi3gate certain types of

a5acks, including Cross Site

Scrip3ng (XSS) and data injec3on

a5acks.

— MDN

Content Security Policy: a header

which tells the browser where

assets (scripts, stylesheets, fonts,

and so on) can be loaded from.

— Me

Supported by all major browsers,

even Internet Explorer (kind of)

CSP: Why?

• Reduces the poten.al surface area for a3acks or malicious

injec.on of scripts

• Can help prevent malicious browser extensions and malware

from inser.ng crap into your pages.

• For example, the CSP on Piranhas.co has stopped some shady

browser extensions from injec.ng ads? onto the page.

static.cmptch.com

I'm not 100% sure what this is, but I'm 100% sure I don't want it on my site

Content Security Policies allow quite

fine grained control over what can

be loaded from where.

Simple example of a CSP

Content-Security-Policy: script-src 'self'

Only allow scripts from the same origin as the page

Simple example of a CSP

Content-Security-Policy: script-src 'self' https://apis.google.com

Same origin as the page and apis.google.com

Available direc,ves

• default-src: fallback policy

• script-src: which scripts the protected resource can execute

• style-src: which CSS applies to the protected resource

• img-src: where the protected resource can load images

• font-src: where the protected resource can load fonts

• and a lot more, if you have more esoteric needs

Repor&ng

The report-uri direc)ve lets you get JSON reports for viola)ons

{

"csp-report": {

"document-uri": "http://example.com/signup.html",

"referrer": "",

"blocked-uri": "http://example.com/css/style.css",

"violated-directive": "style-src cdn.example.com",

"original-policy": "style-src cdn.example.com; report-uri /_csp-reports"

}

}

report-uri.io

Free repor'ng endpoint and UI for CSP viola'ons

Where to start?

Adding a CSP header to a long

standing site can be … tricky

Having it there from the start is a lot easier

Where to start?

Content-Security-Policy: default-src *;

Allow all sources, but disallow unsafe inline assets (for example

scripts and styles).

SecureHeaders13

Security related headers all in one gem

13 h%ps://github.com/twi%er/secureheaders

Provides support for CSP headers and a lot more

The defaults are strict

but not ridiculously so

The not ridiculously strict defaults

Content-Security-Policy: default-src 'self' …continues

Strict-Transport-Security: max-age=631138519

X-Content-Type-Options: nosniff

X-Download-Options: noopen

X-Frame-Options: sameorigin

X-Permitted-Cross-Domain-Policies: none

X-Xss-Protection: 1; mode=block

The CSP which didn't fit in the last slide

Content-Security-Policy: default-src 'self' https:;

font-src 'self' https: data:;

img-src 'self' https: data:;

object-src 'none';

script-src https:;

style-src 'self' https: 'unsafe-inline'

You'll probably want to add report-uri to that

S"ll afraid?

Content-Security-Policy-Report-Only

CSP pro-)ps

• New projects

• Enforce the CSP from the beginning

• Report viola8ons from your staging or produc8on environment

• Old projects

• Add a CSP with all the sources you think you need

• Deploy it as Report Only, leave it for a week or two to uncover anything

you might have forgoBen about

• Deploy the enforced policy once you've accounted for all the viola8ons

HTTP, HTTPS, CSP, SSL, TLS, XSS,

CSRF, and so forth

Enough alphabet soup yet?

HPKP

HTTP Public Key PinningWhat is it and should you use it?

One more security HTTP header

Public-Key-Pins:

pin-sha256="cUPcTAZWKaASuYWhhneDttWpY3oBAkE3h2+soZS7sWs=";

pin-sha256="M8HztCzM3elUxkcjR2S5P4hhyBNf6lHkmjAHKhpGPWE=";

max-age=5184000; includeSubDomains;

report-uri="https://www.example.org/hpkp-report"

Lets you limit what public keys the

browser will trust in the future

Foot, meet gun

If you mess it up, you can lock out

users for days, weeks, or months

If you mess up on a produc0on site,

there is no undo bu'on

(aside from wai-ng for it to expire)

IMO, not worth it

The benefits are too small compared to the

massive damage you can poten7ally do.

However

Some &ps if you do go down this road…

Some &ps if you do go down this road…

1. Start with a very short expiry 1me (minutes)

2. Include pins for one or two backup keys

3. The backup keys should not touch the server un4l you need

them

• Keep them in cold storage, preferable secure and offline

4. You can also choose to pin a CA public key

Summary

Summary

• Rails defaults are pre/y good, but can (fairly easily) be 9ghtened

• You should use HTTPS

• Test that HTTPS is set-up correctly

• The Mozilla SSL Configura9on Generator is great

Summary

• Use a Content Security Policy, if only to reduce the surface area available

for a9acks

• The more strict its is, the fewer chances there are for third par?es to

mess with your site

• Use the SecureHeaders gem to manage the policy

• It requires more thought than the Rails defaults, but I think it's worth it

• Excep&on to most of the above: If you're working on your first Rails

app, you probably shouldn't add this complexity.

Summary

• HTTP Public Key Pinning can be an excellent way to shoot

yourself in the foot

• If used correctly, you can effec=vely prevent a rogue CA from

issuing certs for your domain

• I don't consider this a major vulnerability for most sites

Thanks. Ques,ons?

Thanks again

• Twi%er: @ma-askorhonen.fi

• GitHub: ma-askorhonen

• Email: me@ma-askorhonen.fi

• Web: ma-askorhonen.fi

• Blog: randomerrata.com

Resources

• HTTPS

• h#ps://letsencrypt.org

• h#ps://mozilla.github.io/server-side-tls/ssl-config-generator/

• h#ps://www.ssllabs.com

• CSP

• h#ps://report-uri.io

• h#ps://sco#helme.co.uk/content-security-policy-an-introduc>on/

• h#ps://developer.mozilla.org/en-US/docs/Web/Security/CSP/Using_Content_Security_Policy

• h#ps://github.com/twi#er/secureheaders

• HPKP

• h#ps://developer.mozilla.org/en-US/docs/Web/HTTP/Public_Key_Pinning