Errata for Security on Rails

#41740: I think some explanation and a figure have disapeared from the end of p.138 / begining of p.139:

Figure 7.5 does not show that Bob is denied access to the site. It however illustrates the last paragraph of p.138 (Joe's Friends group), but for the Figure 7.5 to be correct, the text should also tell us that Bob is member of this group.--Frederic BLANC

#43569: I think the description of symmetric versus asymmetric cryptography could use some extra exposition. Instead of:

For the purposes of the book, we can divide cryptography into two main
groups: symmetric and asymmetric. Each group has its own strengths and
weaknesses, and neither group is always better than the other.

I suggest something more like:

For the purposes of the book, we can divide cryptography into two main
groups: symmetric and asymmetric. Because each group has its own
strengths and weaknesses, it is important to know how each is used
before deploying an application that relies on cryptography.

Asymmetric ciphers are normally used for key distribution and digital
signatures. Asymmetric ciphers are never used to encrypt messages
directly; instead, messages are encrypted with a random session key
using a symmetric cipher, and the session key is encrypted to a specific
public key. Only the holder of the private key can recover the session
key, and the message can only be recovered with the session key. When
used with digital signature schemes, an asymmetric cipher signs
a digest of the message using a private key; any one with the public key
can validate that the message digest was signed with the private key,
and thus know the message was signed by the private key.

Symmetric ciphers are used either when key distribution happens out of
band, over time (storage and retrieval from encrypted data bases), or
when keys can be negotiated using asymmetric ciphers.

The general gist is that the text doesn't make clear that asymmetric ciphers are suitable only for very specific purposes, such as key distribution and signing message digests. The examples later in the text showing human-readable messages being encrypted directly using RSA are fine as examples go, but _please_ annotate the examples to clearly indicate that real applications do not sign or encrypt messages directly with RSA.--Seth Arnold

#43568: Something about the voice of the introductory paragraph of section 9.1 struck me as aimed at the entirely wrong audience:

"As a resident of the World Wide Web, you've probably heard about digital signatures. Digital signatures are crypto-systems built using message digests and asymmetric cryptography.Crypto-system is just a fancy way of describing a collection of cryptography techniques used"

Ignore the missing space, I think the whole thing needs to be re-written. :) The book is _already_ being read by people already interested in security, and can probably guess what 'crypto-system' means without being told that it is fancy in any way :) and mostly just want to know: (a) x509 vs openPGP? (b) does anyone actually _use_ these mechanisms? with which MUAs?

Please take this as it is meant, with kindness. :) This book is really good, but this paragraph rubbed me the wrong way. It's not a blog post "so what's all this digital signature stuff?" aimed at the Internet in general, but rather 170 pages into a Pragmatic Programmers book on how to program Rails securely. :)--Seth Arnold

#43576: The receive() method that does S/MIME email validation and comment parsing doesn't actually make sure that:

(a) the user rating the venue actually booked the venue.
The venue finder should be replaced with something like this:

user = User.find_by_email(cert_email[1])
venue = user.venues(id)

Otherwise someone could easily rate venues they've never booked.

(b) that the date the user attempts to rate the venue has already passed (perhaps it makes sense to let voters rate venues before they have used them -- perhaps venue staff are annoyingly pedantic people :) -- but users could be rating venues they've never used and have no intention of ever using (say, they book the venue for the year 2525 or something.)--Seth Arnold