Advanced Rails - Building Industrial-Strength Web Apps in Record Time

Web Issues | 139

exception if either of these are missing. These options can be set alongside other ses-
sion options inconfig/environment.rb:

config.action_controller.session = {

:session_key => "_myapp_session",

:secret => "Methinks it is like a weasel"

}

There are a few limitations to the CookieStore:

• In most cases, cookies are limited to 4 KB each. The CookieStore will raise a
  CookieOverflowexception if the data and HMAC overflow this limit. This is not
  an error you want to get in production (as it requires architectural changes to
  remedy), so make sure your session data will be well below this limit.


• The entire session and HMAC are calculated, transmitted, and verified on each
  request and response. The CookieStore is smart enough not to retransmit the
  cookie if it has not changed since the last request, but the client must transmit all
  cookies on each request.


• Unlike the server-side session stores, the CookieStore allows the client to read all
  session data. This is not usually an issue, but it can be a problem in certain cases.
  Some applications require sensitive user data (such as account numbers or credit
  card numbers) to be hidden even after a user is logged in, for extra security. Also
  consider that the data may be stored as plain text in the browser cache on the cli-
  ent. Sensitive data should be stored on the server, not in the session.


• The CookieStore is vulnerable to replay attacks: since the cookies do not incor-
  porate a nonce,*a user who has a valid session can replay that session at any
  later time, and convince the server that it is current. Never store transient data,
  such as account balances, in the session.

Cross-Site Scripting

Cross-site scripting(XSS, to avoid confusion with Cascading Style Sheets and Con-
tent Scramble System) is one of the most common vulnerabilities in web applica-
tions created recently. “Web 2.0”-style applications are particularly vulnerable due
to the shifting emphasis toward user-generated content.

XSS usually is made possible because of inadequate escaping of user-entered code,
particularly in blog posts, comments, and other user-generated content. In an XSS
attack, an attacker inserts code, particularly JavaScript, into a third-party site (the
target) in such a way that the browser treats it as part of the target page for security
purposes.

*Anonce, or “number used once,” is a random value generated by the server that the client must include with
its request. Because the nonce is different on each request, the server can ensure that the same request is not
sent twice.