Tag Archives: rack

Session-only cookie corruption in Ruby web apps

Posted on by
6

Rack and Rails have a cookie monster.

Browsers place limits on the number and size of cookies present for a domain or in a response. If you exceed these limits, Bad Things can happen. Rack and Rails try to prevent this in the obvious cases, but this post describes what they get wrong in their current implementations. We’ll also review the potential impact of—and how you can mitigate—this type of issue in your Ruby web apps.

This information is most relevant for web apps that transmit session cookies that contain the encoded contents of the entire session hash—not just the session ID. In other words, a cookie-only session. For example, Rack::Session::Cookie with Marshal or JSON, Rails’ default ActionDispatch::Session::CookieStore, or an implementation of JWT (JSON Web Tokens) that uses a cookie (instead of a dedicated response header) as its transport. The security risks are greatest when cookie-only sessions meet the cookie-truncation behavior of older browsers (and can be compounded when the sessions contain arbitrarily-large data, such as flash messages).

TL;DR: If your Ruby web apps use cookie-only sessions, consider adding Rack::Protection::MaximumCookie to their middleware stacks.

Continue reading →

How fanriff.com works, Part I

Posted on by
Reply

I thought I’d write about how fanriff.com serves its Ember.js index from its Sinatra.rb API, and how web clients interacts with the back-end once the application is loaded. It started to run a little long so I’ve broken it up into parts. This first chapter will cover some background information on Ember, the fanriff.com web architecture, and how we deploy our Ember index to our stack.

Continue reading →

Always set X-Forwarded-Proto

Aside

Reply

If your Rack application (and probably other types of applications) lives behind a reverse proxy, always set an X-Forwarded-Proto request header. I recently ran into an issue where Rack::Session (which I’m using for an OAuth1.0a server-side login flow) wouldn’t let me set a secure cookie because it didn’t think I was serving a secure web site.

I have forwardfor disabled in my HAproxy config because I’m using PROXY protocol to talk to Varnish. Manually adding the X-Forwarded-Proto header to the request fixed the issue, and now I want those three hours of my life back! Hopefully this comes up in someone else’s frantic googling at some point in the future and saves them a similar headache.

Rack::Deflater in Sinatra

Posted on by
Reply

“Can I use Rack::Deflater in my Sinatra application?” Yes, absolutely. It’s a piece of Rack middleware and therefore super easy to use:

use Rack::Deflater

Furthermore, the RubyDoc for Rack::Deflater gives a cool little example of how to conditionally enable Rack::Deflater based on the size of the response body:

use Rack::Deflater, :if => lambda {
  |env, status, headers, body| body.length > 512
}

Unfortunately, this doesn’t work in Sinatra, or at least not on Sinatra 1.4.6, Rack 1.6.4, and Ruby 2.2.3. Why? Well, body is (for some reason) an array, so its length is probably zero (nil body) or one. It also occurs to me that we care more about the byte size of the body than its string length; if you think a 513-byte response is worth compressing, 512 characters encoded in UTF-32 (2,048 bytes) certainly is!

Here’s a modified (and code-golfed) version of the above snippet for Sinatra:

use Rack::Deflater, :if => lambda {
  |*, body| body.map(&:bytesize).reduce(0, :+) > 512
}

Happy deflating!