Historical errata for Security on Rails

last paragraph on the page.

‘They allows us’ should maybe be ‘They allow us’?

Dave Raphael acknowledgement:

‘Yhere’ should be ‘There’?

first paragraph after the bullets:
“to the new( ) and will be set in User object”

should maybe be something like:
“to the new( ) method will be set in the User object”

3rd paragraph:

‘in anyway’ should be ‘in any way’

paragraph after the SELECT statement:
“rows then selects returns the first value”
should be:
“rows then returns the first value”

4th paragraph
“password so application will”

should be:
"password so the application will

first bullet:
“accept input form a user”

should be:
“accept input from a user”

paragraph 1 talks about how role_id is equal to 2
but the code on the previous page never
shows how this happens. Presumably this is in an
after_create method or something?

last paragraph:
“protecting our application a multitude of attacks”

should be:
“protecting our application from a multitude of attacks”

4th paragraph
“make sure they our application”

should be:
“make sure our application”

In 3. Web Server, “…the our application…” should be “…then our application…”

“Administrator: Because business analyst are not allowed…” should be “Administrator: Because business analysts are not allowed…”
Further in the same paragraph, “This group will only be allowed to add other business analyst” should be “This group will only be allowed to add other business analysts”.

Last sentence on the page, “Let’s make
sure we those mistakes are easy to fix.” should be “Let’s make
sure those mistakes are easy to fix.”

In first paragraph:
“we first need learn how to break it” should be “we first need to learn how to break it”

lunchedin_broken> rake db:fixtures:load

Before launching this it would be good if you briefly described the assumed environment required for this command to execute successfully.

I installed a freah version of instant rails 2.0, and then did an online update. That resulted in me having rails (2.3.2, 2.0.2). On trying to execute this command, I was informed that it needed rails 2.2.2.

After installing rails 2.2.2 and repeating the command, I got the following error:

rake aborted!
Unknown database ‘lunchedin_development’

Note:
The error is in the lunchedin_broken code, and I saw it as already filed as bug #49, but incorrectly set as suggestion and with the wrong diagnosis.

Description:
When trying to break into the lunchedin_broken, the role_id is never set to 1, but to 2.

Bug:
The User model has “attr_protected :role_id”, so it’s not vulnerable to the attack descripted. This should be removed and kept only in the non-broken version of the project.

First paragraph, last sentence: “We can also use them to manipulate the response before the it is received by the browser” should be “We can also use them to manipulate the response before it is received by the browser”.

Second Paragraph, last sentence: “We will to hack the administration console using an ordinary account” should be “We will hack the administration console using an ordinary account”.

First paragraph after the bullets, end of first sentence: “… all attributes passed to the new( ) method and will be set in User object” should be “… all attributes passed to the new( ) method will be set in the User object”.

First paragraph after the bullets, end of last sentence: “… we can insert our own form fields and the application will gladly set values form if a column exists” should be “… we can insert our own form fields and the application will gladly set values if a column exists”.

Second paragraph after the bullets, last sentence: “This protection helps prevents leaks of internal information that may be used against our applications” should be “This protection helps prevent leaks of internal information that may be used against our applications”.

Last paragraph, first sentence: “The reason we add this value as a new form element is because of how Rails maps form parameters to a newly instantiated objects” should be either “The reason we add this value as a new form element is because of how Rails maps form parameters to newly instantiated objects” or “The reason we add this value as a new form element is because of how Rails maps form parameters to a newly instantiated object”.

First paragraph after the bullet, first sentence: “We are able to draw these assumptions without ever looking the source code on server …” should be “We are able to draw these assumptions without ever looking at the source code on server …”.

In the http link: “localhost:3000/venues/show” should be something like “localhost:3000/venues/1”. Using show generates an ActiveRecord::RecordNotFound in VenuesController#show error.

First paragraph, first full sentence: “If you are you running the sample application with the development mode …” should be “If you are running the sample application with the development mode …”.

First paragraph, last sentence: “Luckily for use we can all agree cross site scripting vulnerabilities are bad, regardless of what subcategory someone wants to put them under” should be “Luckily for us we can all agree cross site scripting vulnerabilities are bad, regardless of what subcategory someone wants to put them under”.

Third paragraph, second sentence: “Given this, let’s see if developer has missed …” should be “Given this, let’s see if the developer has missed …”.

Fifth paragraph, second sentence: “While italics are only slightly menacing, such an action does proves the applications is in fact vulnerable to html injection” should be “While italics are only slightly menacing, such an action does prove the application is in fact vulnerable to html injection”

First paragraph, fourth sentence: “When sending special and reserved we must URL encode them” should be “When sending special and reserved characters we must URL encode them”.

First paragraph, last sentence: “In Ruby we can accomplish by calling the escape(string) method of the CGI class” should be “In Ruby we can accomplish this by calling the escape(string) method of the CGI class”.

Third paragraph, first sentence: “This alert will be shown every time the page is loaded”.
I did not find this statement to be true. The alert occurred initially, but never again. Although the comment associated with the alert is initially displayed on the response screen, it subsequently appears to be discarded.

Second paragraph, fourth sentence: “… allowing them to anything that your account is allowed to do” should be “… allowing them to do anything that your account is allowed to do”.

Script at top of page: Not sure what should be the observed result here??? I got nothing other than an empty comment box displayed after the previous entered commentd.

Fourth paragraph, second sentence: “The prefix, _lunchedin_session_id is used by Rails to manage make sure
each application’s session id does not collide with another” should be “The prefix, _lunchedin_session_id is used by Rails to make sure each application’s session id does not collide with another”.

Fifth paragraph, second bullet: “Cross site vulnerabilities typically occur without any knowledge of of the user’s knowledge and typically appear as normal traffic” should be “Cross site vulnerabilities typically occur without the user’s knowledge and typically appear as normal traffic”.

Second paragraph, first sentence: “For example, a browser interpreting malicious markup in saved into a comment on a forum is an example of XSS …” should be “For example, a browser interpreting malicious markup saved into a comment on a forum is an example of XSS …”.

Fourth paragraph, first sentence: “How can we prevent automatic binding of parameters parameters to ActiveRecord properties” should be “How can we prevent automatic binding of parameters to ActiveRecord properties”.

Third paragraph, last sentence: “Now subsequent calls to vote on a venue will be blocked, regardless if what rendered view is displayed to the user” should be “Now subsequent calls to vote on a venue will be blocked, regardless of what rendered view is displayed to the user”.

First paragraph, first sentence: “The updated code is isn’t pretty, but it does the job …” should be “The updated code isn’t pretty, but it does the job …”.

First paragraph, first sentence: “On line 3 we changed the check_login( ) to use an class method on our User model” should be “On line 3 we changed the
check_login( ) to use a class method on our User model”.

Second paragraph, first sentence: “Now we that we have fixed our SQL injection flaw …” should be “Now that we have fixed our SQL injection flaw …”.

Also it would be better to put this paragraph before the test code example, rather than after it.

Second paragraph, second sentence: “On line 7 …” should be “On line 6 …”.

Second paragraph, third sentence: “On line 8 …” should be “On line 7 …”.

Second paragraph, third sentence: “Unfortunately, these input patterns deceptively difficult to blacklist” should be “Unfortunately, these input patterns are deceptively difficult to blacklist”.

Second paragraph, first sentence: “We will cover input validation in the chapter, Chapter 5, Validation …” should be “We will cover input validation in Chapter 5, Validation …”.

Last paragraph, first sentence: “We can fix this by changing how each attribute rendered in the view, Rails includes the view helper method h( ) designed for such purpose” should be “We can fix this by changing how each attribute is rendered in the view. Rails includes the view helper method h( ) for this purpose”.

Third bullet, first sentence: “Do filter or sanitize model attributes are displayed in a view” should be either “Do filter or sanitize model attributes that are displayed in a view” or “Do filter or sanitize model attributes displayed in a view”.

Technique #4: You may want to define the term CAPTCHA as this is the first time it is used in the text.

Second paragraph, first sentence: “For this chapter will focus on technique #1” should be “This chapter will focus on technique #1”.

First paragraph, first sentence: “The Rails designers have thought of situations such as these and have given us the class method, verify( )” should be “The Rails designers have thought of situations such as these and have given us the class method verify( )”.

Repeated word ‘as’ end of line 4 and beginning of line 5.

… this part works as
as expected.

First paragraph, third sentence: “Figure Figure 4.1 shows what types of tests are suited for various vulnerability categories” should be “Figure 4.1 shows what types of tests are suited for various vulnerability categories”.

Second paragraph, end of first sentence: “… we’ll need more that the basic Rails testing infrastructure” should be “… we’ll need more than the basic Rails testing infrastructure”.

Code refers to a Rating object, not a Rate object.
“We can see on line 3, a new Rate object is instantiated and added to the Venue object. Nothing stops this code from creating a new Rate object.”

End of section 1.6: “If the condition the first code example fails” doesn’t seem right. Was “In the condition …” meant? That sounds awkward.

Last sentence of second paragraph: “Select the ‘tamper’ button and the a dialog box that looks like Figure 2.6, on page 31.’ ”the a" is wrong, and the clause following “and” needs a verb.

“Attacks that are initiated with ECMAScript can forge HTTP request method thus rendering the defense vulnerable.”

Should read “…can forge the…”

Page 66 lacks the “submit erratum” footer. ;-)

Also, the second sentence has “is is” rather than “it is”:
“But simply testing software doesn’t guarantee that is is secure—you have to test the right things.”

In section Data Protection, first paragraph:
" Are sensitive parameters properly masked in log files? Within the applications view?"

Missing ’s in “application’s view”.

“We use the user fixture users(:bob) as defined in users.yml, to attempt modification of the event events(:rubycon) is owned by Wally.”

Remove “is”.

“Do Not Repeat Yourself, is a principal…” should be
“Do Not Repeat Yourself, is a principle…”

Second paragraph, last sentence: “How would the the banking customer repudiate the transfer” should be “How would the banking customer repudiate the transfer”.

Third paragraph, first sentence: “What if we will require the user to answer some secret questions before transferring the funds” should be “What if we require the user to answer some secret questions before transferring the funds”.

Last Administrator response, fifth sentence: “This group will only be allowed to add other business analyst” should be “This group will only be allowed to add other business analysts”.

First bullet: “All Cryptographic Keys must be stored in separate files outside of application directory” should be “All Cryptographic Keys must be stored in separate files outside of application directories”.

Last paragraph, first sentence: “Ultimately, security requirements are a much like usability requirements” should be “Ultimately, security requirements are much like usability requirements”.

Last sentence before section 2.2: “If if you feel the need to start over with clean data, simply execute the command again and new data shall appear”

Which command or should it be “commands”?

Format of code line is different from the preceding two lines.

“lunchedin_broken> rake db:fixtures:load”

Third paragraph: “Navigate your browser to [http link] of LunchedIn and view the HTML source of of the page”.

Delete an “of”.

Also might be good idea th remind the reader to start things up with a “ruby script/server” command.

Error #40033 claims to be corrected in B4; however, it has not been changed.

First paragraph after the bullets, end of first sentence: “… all attributes passed to the new( ) method and will be set in User object” should be “… all attributes passed to the new( ) method will be set in the User object”.

The word “and” needs to be removed after the word “method”.

Second last sentence on the page: Remove the comma after the word “control”.

“It’s easy to overlook direct access to objects not belonging to a user.
This is an exploit easy to overlook.”

Second sentence is redundant.

Third bullet: “Do or sanitize model attributes displayed in a view” should read “Do filter or sanitize model attributes displayed in a view” (missing word “filter”).

def test_loged_out_redirect should be test_logged_out_redirect.

same typo in the downloadable code testing/lunchedin/test/functional/venues_controller_test.rb

missing d in “suppose”

“Testing for authorization is about making sure users are only able to access data or operations they’re suppose to.”
=> they are supposed to

e is replaced by c in “mime”

“Here we mimc an authenticated user attempting to modify another user’s event.”
=> Here we mime

missing verb

“How can we test to make sure sensitive parameters properly masked in log files?”
=> How can we test to make sure sensitive parameters are properly masked in log files?

“This also demonstrates an additional reason why our principal of Defense in Depth, from Chapter 1, Security in Ruby on Rails, on page 9, becomes so important.”

principal => principle

“– Double Dash - SQL Comment”

missing one dash

“Authentication is the process of identifying and verifying a principal. We’ll see what a principle is in just a few paragraphs. For now, just think of principal as a user.”

principle => principal

“control.Chapter 7, Authorization, on page 133 covers authorization in depth.”

missing space between control. and Chapter

Under “Data Protection,” I would strongly recommend not suggesting that DES or MD5 are currently regarded as secure. DES uses a 56 bit key and is readily broken these days; Triple-DES or AES-128 is the current recommendation for minimum symmetric encryption strength. MD5 is showing significant weakness, and the current advice is to move to SHA1 (which is also starting to show “cracks in the foundation”).

Grammar nit: the first sentence on this page (“On line 3, the query …”) does not have a verb.

The second-to-last bullet point reads “Writing code that fails close”. It should likely read “Writing code that fails closed”.

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.

Text:
Key distribution is not required as the same application decrypts and decrypts information.

Should read:
Key distribution is not required as the same application encrypts and decrypts information.

Text:
Let’s add a security question to LunchedIn to help us authenticate a user that has managed to loose their password.

“loose” should be “lose”

On SQL injection on the statement page 39

SELECT * FROM users WHERE (username = ‘wally’ AND password = ‘fakepass’ or ‘a’ = ‘a’) LIMIT 1

will match all users, not Wally. Because of that the actual logged user will be Bob (id=1). To produce the commented result the statement had to be due to operators precedence as the following:

SELECT * FROM users WHERE (username = ‘wally’ AND (password = ‘fakepass’ or ‘a’ = ‘a’)) LIMIT 1

As it complicate more the code you can change the password to

fakepass’ or id = ’3

or

fakepass’ or username = ’wally

These anti-xss whitelists don’t cover unicode character sets, which are required for name and address entry in international applications.

A current book should really cover whitelisting non-English alphabets, or at least make a suggestion.

In figure 9.4, the CSR mays not include “the public key of the certificate authority email_ca.cer” as it is written. At this time, the csr has nothing to do with the CA.

Cheers

The LDAP authentic?() method on page 116 hard-codes all the values that should be read from the LDAP_CONF, as done on the next page.

The description of MAC versus DAC authorization is entirely wrong. :)

Discretionary access control is when object owners are allowed to specify which other users in the system may use the objects, and with which permissions. Standard Unix, extended Unix ACLs, Windows ACLs, etc., are all discretionary because the file or directory owner can choose which users or groups to grant read/write/execute (or delete/etc, for the fancier types).

It is discretionary because it is at the discretion of the owner.

Mandatory access control is when object owners do NOT have complete control over the allowed users and privileges of their objects. The security administrator decides what privileges may be granted and to whom. Users may also have some discretionary access control privileges, but they are subservient to the mandatory access control privileges.

MAC is mandatory, because users cannot modify the privileges themselves. MAC does not have to be implemented with labels — the Common Criteria LSPP protection profile requires labels, but it is by no means universally accepted. MAC can also be implemented in part by standard filesystem services, such as Samba, which can be configured to export some shares read-only, or apply its own per-group or per-user access controls in addition to whatever DAC ACLs might also exist on files in the filesystem.

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. :)

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.

“That said, both RSA and DSA serve as excellent starting points for encryption.”

DSA cannot be used with encryption. (DSA was selected to become the US Government’s digital signature standard because it can only be used for signature creation/validation, thus it could be easily exported from the United States. Because RSA could also be used for encryption, it was classified as a munition, and could only exported with a huge amount of paperwork.)

“We can do this by providing something functionality along these lines…”

s/something functionality/something functionally/

“We can use the an issued digital certificate…”

s/the an/an/

“certificate revocation lists (curls)”

s/curls/CRLs/

“revoke the ability to automate create comments”

Suggest remove “automate” and change to “create comments via email”.

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.)

“lunchedin@gmail.com” — we have example.com/net/org for a reason :)

“You can learn more about option this in…”

s/option this/this option/

Decide.erb has commented HTML included.

The decision action has commented “Not sure we should nil this out here” :)

“It’s primary intended use was to provide”

s/It’s/Its/

“but false if the call not complete”

s/call not/call did not/ (or rewrite to more-active “failed”. :)

“SPNEGO can operate over many different of network protocols.”

s/different of/different/

environment.rb includes a comment # BEGIN_HIGHLIGHT that feels like it was intended for the pragprog hamsters. :)

“In this file, all we modify only the skip_before_filter”

s/all we modify only/we only modify/

science live details lime

glacier evaporation down developed

back investigate developed

available disputed benefits sea

para 2: the URL …/profile/new should be …/users/new

para 2: “Click the Tamper button in the dialog box, as shown in Figure 2.6” should read “Click the Tamper button to bring up the dialog box shown in Figure 2.6” (The dialog box with the Tamper button is not shown in fig 2.6!)

para 3: “Control-click the column” should read “Control-click the Post Parameter column”

Example code download: The Partial lunchedin_broken/app/views/tags/cloud.html.erb needs to be renamed …/_cloud.html.erb (and 14 other instances of the file.)

The migration 007_create_tags_venues should be modified to read:
…create_table :tags_venues, :id => false do |t|…
to prevent the creation of a primary key in the link table tags_venues. This may not be a problem if using MySQL as in the text, but SQLite3 creates a primary key by default. (Because of the problems with the mysql gem in Rails 3, readers may be using SQLite3)

The XSS exploits in section 2.6 appear not to work in Rails 3.0.5 and Firefox 3.6.13 (Hooray?)