Web Issues | 137This exception should be caught and logged to the Rails development log, but the
client should only see a nice “500 Internal Server Error” page.
Whitelist, Don’t Blacklist
A general principle of network security is thatwhitelists(lists of what to allow) are
more secure thanblacklists(lists of what to block). This principle descends from a
default-deny, or fail-secure, stance. Whitelists err on the side of caution, assuming
malice when presented with something they don’t understand.
Zed Shaw, creator of the Mongrel web server, is a vocal proponent of this philosophy.*
Much of Mongrel’s security comes from its default-deny stance. When presented with
a protocol violation, Mongrel closes the socket, rather than sticking around and trying
to guess what the client meant (possibly getting exploited in the process).
We will revisit this issue in the “Canonicalization: What’s in a Name?” section later
in the chapter.
Web Issues
Now that we have examined some of the architectural ways that you can protect
your application, we will take a look at some of the issues endemic to the Web.
Rails Sessions
Most web frameworks have some form of session management: a persistent server-
side storage mechanism for data specific to one client’s browsing session. The exact
scope of a “browsing session” depends on implementation details and the method of
session tracking. Most commonly, a non-persistent cookie is used, so a session con-
sists of all visits to a site before closing the browser. Alternatively, a persistent cookie
(one with an explicit expiration date) can be used; this will persist even when the
browser is closed. This is useful to remember information (such as a shopping cart)
across visits for otherwise anonymous users. Some frameworks such as Seaside pro-
vide URL-based (query-string) sessions so that a user may even have multiple ses-
sions active at the same time in different browser windows.
Most of Rails’s session storage methods provide the following properties:
Confidentiality
Nobody except the server can read the data stored in the session.
Integrity
Nobody except the server, including the client itself, can modify the data stored
in the session other than by throwing the session out and obtaining a new one. A
corollary is that only the server should be able to create valid sessions.