Regenerate guides again

1 files changed, 54 insertions, 2 deletions

diff --git a/railties/doc/guides/html/security.html b/railties/doc/guides/html/security.html
index 4ece0814d5..a135d9b486 100644
--- a/railties/doc/guides/html/security.html
+++ b/railties/doc/guides/html/security.html
@@ -303,6 +303,8 @@ ul#navMain {
 						
 							<li><a href="#_command_line_injection">Command Line Injection</a></li>
 						
+							<li><a href="#_header_injection">Header Injection</a></li>
+						
 						</ul>
 					</li>
 					<li>
@@ -316,7 +318,7 @@ ul#navMain {
 			<div id="preamble">

 <div class="sectionbody">

 <div class="para"><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 at 42 {<em>et</em>} rorsecurity.info. After reading it, you should be familiar with:</p></div>

+mail me, Heiko Webers, at 42 {<em>et</em>} rorsecurity.info. After reading it, you should be familiar with:</p></div>

 <div class="ilist"><ul>

 <li>

 <p>

@@ -1206,7 +1208,10 @@ s = sanitize(user_input, :tags =&gt; tags, :attributes =&gt; %w(href title))</tt
 <div class="para"><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="para"><p>&#8212; <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="para"><p>For example, RedCloth translates <em>test</em> 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:</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

@@ -1241,6 +1246,53 @@ s = sanitize(user_input, :tags =&gt; tags, :attributes =&gt; %w(href title))</tt
 <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="para"><p>&#8212; <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="para"><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="para"><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="para"><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="para"><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="para"><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="para"><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="para"><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="para"><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'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">