How To Use SSL To Secure Your Rails App Against e.g. FireSheep

http://www.kalzumeus.com/2010/10/25/how-to-use-ssl-to-secure-your-rails-app-against-firesheep-and-other-evils/

by patio11 • 16 years ago

115 43 16 years ago

patio113• 16 years ago

I spent almost an entire day doing this today, and in the course of getting documentation the traditional Rails way -- Googling for blog posts from 2007 and finding what changed right after it took the site down -- got a little frustrated. To vent a bit, I wrote it up cookbook-style so that someone in 2014 can curse my name.

samd2• 16 years ago

Well someone in 2010 is extremely grateful for your effort.

simonista2• 16 years ago

At least you have a date on your article. Half the articles I find have no date, and so then you're left wondering, 'exactly how out-of-date is the information I just found?'

flogic• 16 years ago

I hate that. It really perplexes me when things pretending to be News Papers leave off dates.

pasbesoin• 16 years ago

And you place the date at the top, so we don't have to scroll down an indefinite amount and maybe find one, maybe not. :-)

fendale• 16 years ago

My one and old Rails app is running using Apache + Passenger. When I set it up, I wanted to get it using SSL site wide as easily as possible, so I just stuck in a rewrite rule in Apache:

  RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}

It's been a year since I did that, but I think that's what I used to force the entire site into https only requests.

Confusion• 16 years ago

I don't understand why you go through the trouble of letting Mongrel/Rails handle the SSL. I've always opted to just let Apache handle it and I don't doubt nginx could just as well. Our Passenger simply doesn't know that everything between client and server happens to be encrypted.

zumda• 16 years ago

nginx has a SSL module[1], so you could do that. Just redirect all traffic coming to port 80 to https[2]. But he might have had a good reason to handle it in Mongrel.

[1] http://wiki.nginx.org/NginxHttpSslModule

[2] Add this to your config: server { listen 80; server_name example.com; rewrite ^/(.*) https://example.com/$1 permanent; }

stephencelis• 16 years ago

Keep in mind that if you do any kind of proxy caching (Rack::Cache, etc.), AssetHostingWithMinimumSsl is going to cause problems (if, say, Safari generates a cached response, serves images and CSS from http:, and then any other browser is served that response).

elbenshira• 16 years ago

SSL certs for $13.99? I don't see this anywhere on the GoDaddy page.

simonk• 16 years ago

Don't know where GoDaddy's cheap ones went, but NameCheap has them for $10. http://www.namecheap.com/learn/other-services/ssl-certificat...

gst• 16 years ago

you can also get them for free at startssl.com (yes - they are recognized by major browsers, but you need to know how to configure a "chained" certificate in your server).

xsc• 16 years ago

http://www.godaddy.com/Compare/gdcompare_ssl.aspx?isc=sslqgo...

kijinbear2• 16 years ago

Fuck GoDaddy, they always cost twice as much by the time you're ready to enter your CC info. I buy my certificates from a RapidSSL reseller for $12/year. Single root, no chains, recognized everywhere.

dpapathanasiou• 16 years ago

Another problem with GoDaddy certs is that they're chained: http://news.ycombinator.com/item?id=1308619 (or at least they used to be), so going with rapidssl or namecheap instead is a better option, and not just b/c of the cost difference.

akira410• 16 years ago

Which reseller do you use?

IgorPartola3• 16 years ago

I bought a couple from http://cheapssls.com (no affiliation). There they are under $10.

electrum• 16 years ago

Google for "godaddy ssl" and click the $12.99 ad to get that price.

symkat• 16 years ago

Also keep in mind that SSL makes serving sites based on the host header much more difficult, and is one of a handful of justifications for additional IPs according to ARIN. Last I checked running multiple sites from a single IP with one of them using SSL was against something, but I can't seem to find that now.

Although it is trivial to implement SSL, you should only do it if you need to because of the above, using up all the IPv4 addresses because your random video sharing website might have a user somewhere on a wireless network where their cookies are hijacked. This attack has existed for pretty much ever and isn't very useful for a dedicated focused attack.

tomjen3• 16 years ago

It is not generally possible to serve more than one https domain from a server, because browsers won't accept more than one certificate.

However just because you serve one site doesn't mean that you use one IP more, nor do you contribute to the exhausting of ipv4 addresses -- you already use your ip to connect to your server.

kree10• 16 years ago

There's something called Server Name Indication that allows name-based virtual hosting with https. There's some good information here about it: http://wiki.apache.org/httpd/NameBasedSSLVHostsWithSNI

The problem is browser support isn't quite where it needs to be, with IE only supporting it in 7.0+ on Vista or later (IE 6 or IE anything running on Windows XP is out of luck).

tedkimble• 16 years ago

I was testing an app with SNI SSL today and can confirm Firefox on Windows 7 throws an error.

kijinbear2• 16 years ago

It's also possible to run multiple SSL sites on one IPv4 address by assigning them to ports other than 443. It won't look pretty, but not too much hassle if you absolutely want to protect your logins.

Erwin• 16 years ago

There are three options that I know of:

1) SNI -- this has just too poor support at this time

2) Separate ports -- you can make make Apache listen on for example port 446 and use links like https://subdomain.foobar.com:446/.... -- however some corporate firewalls etc. may be blocking connections out on non-standard ports; we just that just for multiple testing environments. This still requires multiple certs or a wildcard cert.

3) Wildcard certs -- they are are usually quite bit more expensive but they'll let you register *.domain.com. So if a client wants a subdomain you can let them have client.yourdomain.com that way without multiple certs or IPs -- FogBugz uses that for example.

_b8r03• 16 years ago

That's quite interesting. Don't forget to make sure you have the secure flag set on your cookies, that way you won't send the cookies over non-SSL connections.

You should also set the HttpOnly flag, which implements some XSS-limiting features, dependent on the browser.

While you're looking at securing session management, it's probably worth looking at Cross-Site Request Forgery:

http://www.owasp.org/index.php/Cross-Site_Request_Forgery_(C...

Some frameworks, such as Django have Cross-Site Request Forgery protection built in for free. The OWASP site linked earlier is an invaluable resource for all things web application security, and is definitely worth bookmarking.

tptacek• 16 years ago

That's what I came here to say. You almost might as well not use SSL at all if you're not going to set the secure flag, because the same vulnerability that makes "FireSheep" work also allows you to intercept requests and coerce cookies out of them.

Of course, there's no trivially installable exploit with a pretty UI that plugs into Firefox to do that yet, so it'll be at least another few years before anyone takes that attack seriously.

WALoeIII• 16 years ago

It should be noted that even cookies marked 'Secure' will be sent over HTTP for versions of Rails prior to 2.3.10 and 3.0.2.

https://rails.lighthouseapp.com/projects/8994/tickets/5629-s...

And it has been further enhanced recently: http://github.com/rails/rails/commit/2d5a12a50bcd83fcc99865d...

samd2• 16 years ago

Rails 3 has helpers you can use to prevent CSRF attacks. This is a good article for any Rails developer: http://guides.rubyonrails.org/security.html

_b8r03• 16 years ago

A more agnostic way of doing this is to serve all your non-security required static content from a subdomain over HTTP, set the secure flag on your cookies, and scope the cookie to the fully qualified domain name (e.g. www.myapp.com rather than myapp.com).

pilif• 16 years ago

if a page contains mixed content (secured and nonsecured), browsers will complain (and rightfully so). If you want to go the SSL route, then you'll have to serve all assets over SSL too.

Also note that SSL doesn't really work with name based virtual hosts (Host:-header), so every site you enable SSL with requires its own IP address.

With addresses in general running out quickly, this might be a problem for you (or your host).

_b8r03• 16 years ago

You are of course, completely correct. Thanks for pointing that out.

With larger SSL sites, it's not uncommon to use SSL accelerators and reverse proxy through to the HTTP servers at the back. It's definitely not cheap though.

CitizenKane• 16 years ago

For those who have sites built on Drupal the combination of two modules can keep you relatively safe. First secure pages (http://drupal.org/project/securepages) and secure pages hijack prevention (http://drupal.org/project/securepages_prevent_hijack). With the combination of the two, a user session can still be hijacked. However, it will only allow them to go to non-SSL pages. In the case where a user may login and visit a lot of pages that aren't sensitive, but some that are this is a good option and pretty easy to set up.

Janteh• 16 years ago

Wow, I use one before_filter on my Heroku hosted app. Am I doing something wrong here, or is this just Heroku's awesomeness?

  def redirect_to_ssl
    redirect_to :protocol => "https://" unless (request.ssl? or request.local?)
  end

mnutt• 16 years ago

Heroku is awesome, but one of the drawbacks (to my knowledge) is that you can't set up nginx redirects. So with that setup each user incurs an extra rails request once per session.

kyleslattery• 16 years ago

The new Rails 3 router makes it super easy to require SSL for certain routes: http://kyleslattery.com/entries/requiring-ssl-using-route-co...

IgorPartola3• 16 years ago

Why are these tutorial framework specific? Just set up your nginx/lighttpd/apache to server traffic over HTTPS and set up redirects from http://example.com to https://example.com.

patio113• 16 years ago

"Just" setting up Nginx to redirect http:// to https:// just comprehensively broke your site if it previously existed on HTTP only and used some fairly common web dev practices, like splitting images over multiple domains to reduce load time. You now pop Big Scary Warnings all over the place.

IgorPartola3• 16 years ago

That's why I'd set up https://static.example.com as well or use a CDN that already allows me to serve my static media over HTTPS. Once again, nothing to do with RoR.

How To Use SSL To Secure Your Rails App Against e.g. FireSheep

Related Stories