*
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 serverside
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 consists
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 provide
URL-based (query-string) sessions so that a user may even have multiple sessions
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.
Pages:
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214