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.
* http://mongrel.rubyforge.org/docs/security.html
138 | Chapter 5: Security
The traditional session storage methods in Rails are server-side; they store all of the
session data on the server, generate a random key, and use that as the session ID.
The session ID is not tied to the data other than as an index, so it is safe to present to
the client without compromising confidentiality.
Rails uses as much randomness as possible to create the session ID: it takes an MD5
hash of the current time, a random number, the process ID, and a constant. This is
important: guessable session IDs allow session hijacking. In a session hijacking
attack, an attacker sniffs or guesses a session ID from an authenticated user and presents
it to the server as his own, thus assuming the authenticated user??™s session. This
is similar to the TCPsequence-number prediction attack, and the mitigation is the
same: make the session IDs as random as possible.
Cookie-based sessions
There are many problems with server-side session storage. File-based storage, which
marshals the sessions to a local file on the server, is not scalable: to make it work in a
cluster, you either need a shared filesystem or a load balancer that supports sticky
sessions (directing all requests in the same session to one server in the cluster).
Pages:
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215