这个指南描述的是在web应用里普遍的安全问题，同时也给出了在Rails里如何避免这些问题。如果你有任何问题，请mail作者，Heiko Webers, at 42 {et} rorsecurity.info. 读完此文后，你应该会了解：
1.所有的对策已经被高亮显示了
2.在Rails里session的概念， 该放什么在session里，以及一些流行的***方法
3.只是浏览一个站点，怎么就有安全问题呢？(with CSRF)
4.当你使用files或提供一个管理界面的时候需要注意些什么
5.The Rails-specific mass assignment problem
6.如何管理用户：登陆，注销以及对所有层面的***方法。
7.以及最流行的注入***方法。
一 介绍
web application框架帮助开发者建立种种web应用，某些框架在安全方面也帮你省心不少。事实上，一个框架并不比另一个安全。对于大多数的框架来说，如果你正确使用它，可以建立安全的应用。Ruby on Rails有许多聪明的helper方法，例如防止注入***的方法，这让sql注入变成了困难的事情。很高兴看到我审定的所有rails app都有一个良好的安全级别。
一般没有这种即插即用的安全，安全依赖于正在使用的框架，有时候也依赖于开发方式。它取决于web应用的所有环境：后端存储，网络服务器和网络应用程序本身（以及可能的其他层或应用程序） 。
Gartner组织估计大约75%的***都是在web应用，并且在300个调查的web应用里，97%都是容易被***的。这是因为web应用容易***，因为它们易于理解和操作，甚至是懒人。
在受到威胁的web应用中，包括用户帐户劫持，绕开访问控制，阅读或修改敏感数据，或出示虚假的内容。或***者可以安装一个特洛伊***程序或不请自来的电子邮件发送软件，目的是在金融活动或造成损害品牌名称，修改公司的资源。为了防止***，最大限度地减少其影响和消除***点，首先，你必须充分了解***方法，以便找到正确的对策。这正是该指南的目的。
为了开发安全的Web应用你必须不断更新的所有层次和了解你的敌人。要不断更新订阅的安全邮件列表，请阅读安全博客，并更新和安全检查的习惯。我手工做这些，因为这你才能找到讨厌的合乎逻辑的安全问题。
二 Sessions
我们的安全之旅最好是从最易受到特别***的sessions开始。
2.1 什么是sessions
— HTTP is a stateless protocol Sessions make it stateful.
－ HTTP是一个无状态协议，Sessions使它有状态。
大多数的应用需要对一个特别用户的某些状态进行跟踪。比如，一个购物车的内容，一的当前登陆用户的id，如果没有sessions这个好主意，用户必须在每一个请求都得去标识验证身份。如果一个新用户访问这个应用，Rails会自动创建一个新的session。如果用户之前使用过这个应用，它会自动加载一个存在的session。
一个session通常是一个hash和一个session id（通常是一个32个字符的字符串）来标识这个hash。Rails里你可以用如下方式保存和使用session：
session[:user_id] = @current_user.idUser.find(session[:user_id])2.2 session id
— The session id is a 32 byte long MD5 hash value.
－ session id就是个一32位的md5 hash值。
一个session id由一个随机字符串的hash值组成。这个随机字符串是当前的时间，一个0和1之间的随机数字，一个ruby解释器进程id数字和一个常量字符串组成。
2.3 session劫持
－ 窃取用户session id的***者可以在一个web应用里使用受害者的名字。
许多web应用都有一个验证系统：一个用户提供一个用户名和密码，web应用检查并且存储相应的user id到session的这个hash里。从现在开始，session是有效的。在每个http请求里， 应用会加载这些在session里用user id来标识的用户，并不需要新的验证。这个session id是放在cookie里用来标识这个session的。
因此cookie作为web应用的临时验证。任何人得到一个别人的cookie，他就可以伪装为这个人使用对应的web应用－可能会有严重的后果。这里有一些session劫持的方法，以及对策：
1.在不安全的网络进行嗅探cookie。无线局域网就是这样一个例子。在这样的一个网络里，特别容易去监听所有链接的客户端， 这就是不去咖啡店工作的原因（某些sb就喜欢去星巴克打开本本装比）。对于web应用开发者，这就意味着去提供一个安全的ssl连接。
2.大多数的人在公共场所工作之后不清除cookie，所以如果是最后一个没有在web应用注销的用户，你有可能伪装成这个用户。在web应用里提供给用户一个注销按钮，并且放在醒目的位置。
3.许多跨站点脚本（ XSS ）***的目的是获得用户的cookie 。你之后会看到关于xss的更多内容。
4.Session定制，之后会读到.
大多数***者的目的是为了钱，失窃的银行登陆帐号的价格范围从$10 - $1000不等（取决于可用的资金数额），信用卡号码是$0.40-$20，在线拍卖网站的帐号为$1-$8，email密码为$4-$30 ，参考赛门铁克的网络安全威胁报告。
2.4 session 准则
－这里有一些session的一般准则
1.不要在session里存储大的对象。相反，你应该把它们存储在数据库里，把它们的id保存在session里。这将消除同步的麻烦，而且也不会占用你session的存储空间（取决于你选择的session的存储）
2.关键的数据不应该被存储在session里。如果用户清除了cookie或者关闭了浏览器，它们都将丢失，用一个客户端session存储，用户可以读取数据。
2.5 session存储
－ Rails为session提供了很多存储机制，最重要的是ActiveRecordStore和CookieStore。
大多数实际生活的应用选择ActiveRecordStore （或其衍生物）的文件存储由于性能和维修的原因。 ActiveRecordStore保持session ID和散列在一个数据库表，在每次请求里都保存和检索这个hash。
Rails2介绍了一种新的session存储机制， CookieStore. 它直接在客户端的cookie里保存这个session hash。服务端从cookie里检索这个session hash，无须session id。这将大大增加速度的应用，但它是一个有争议的存储选项，你必须思考安全的影响：
1.cookie意味着严格的大小限制，4k。 这点是好的，本身就不应该存储大的数据在session里，前面也说过。存储一个当前用户的数据库id一般是没有问题的。
2.客户端能看到你存储在session里的一切。因为是明文的（实际是base64编码的），所以，你别想在这里存储任何秘密。为了防止session hash被篡改，会从服务端加一个secret到cookie的末尾。
这就意味着，这个安全存储取决于这个scret（digest算法，默认是sha512，至今没有被破解），所以不要用一个简单的scret，例如字典里的一个单词，或者比30个字符短的任意字符串。把这个scret放在environment.rb里：
config.action_controller.session = { :session_key => ‘_app_session’, :secret => ‘0x0dkfj3927dkc7djdh36rkckdfzsg...’}但是也有经过加密session hash的CookieStore派生存储机制，为了客户端不能看到它。
2.6 针对于CookieStore sessions的重放***
－ 另一种必须要知道的***是针对于cookiestore***是重放***。
它的运作方式如下：
1.用户收到贷款，金额是储存在一个session里，（这是坏主意，但是我们做这些只是示范）
2.这个用户买了一些东西
3.他的new，lower credit将要被存储在session里。
4.邪恶的用户得到了他的cookie并且覆盖了当前的cookie。
5.这个用户有了他的credit， 就可以进行重放***了。
在session里加一个（nonce）暂时标志（随机值）可以解决重放***这个问题。一个nonce仅有效一次，并且服务端保持对所有有效nonce的跟踪，如果你有多个应用服务器，它可能甚至会更复杂，避免把nonce存储在数据库里，这样会破坏整个CookieStore。
最好的解决方法是不要存放这种数据在session里，而是在数据库里。这个例子，存储credit在数据库里，logged in user id 放在session里。
2.7 session 定制***
－ 除了窃取用户的session id，***者还可能去定制一个session id来伪装，这就是所谓的session定制。
这个***的重点是定制一个用户的可以识别他的session id，并且强制用户的浏览器用这个id。因此后来***者也不需要去窃取一个session id了。来看看***是如何展开的：
1.***者创建一个有效的session id： 他登陆想定制session的那个web应用的登陆页面，这时就通过response在cookie里有一个session id了（图中的1，2）
2.他可能保持这次会话（session）。session是会过期的，比如每隔20分钟，这会大大的减少了***者的时间。因此，他会不断的访问这个web应用以便于保持session可用。
3.现在，***者会强迫用户来使用这个session id（看图里的3），因为你不能改变另一个域的cookie，***者不得不在目标web应用里运行一个javascript脚本。通过往目标web应用注入javascript代码来完成这次***。下面是一个例子：
<script>
document.cookie="_session_id=16d5b78abb28e3d6206b60f22a03c8d9";
</script>
4. ***者引诱受害人向被感染的网页上的JavaScript代码。通过查看网页时，受害者的浏览器将把session id改变成***者定制好的session id。
5.因为这个陷进session id没有被用，web应用会需要用户去验证。
6.从现在开始，受害者和***者都会共有一个相同的session在这个web应用里。此时受害者并没有注意到这次***。
2.8 session 定制 －－－ 对策
－ 一行代码就保护你不被session定制侵害。
（我的这篇文章也写了一些对策：[url]http://blackanger.blog.51cto.com/140924/91764[/url]）
最有效的对策就是在成功登陆以后，创建一个新的session id，并且宣告旧的session id失效。那样，***者就不能用固定的session id了。这是一个对方session劫持的好的对策。Rails里我们可以这样来产生一个新的session：
reset_session
如果你用流行的rails插件，RestfulAuthentication，请在SessionsController#create action里加 reset_session. 注意，这个行为消除了原session里存储的所有值，你必须把这些值得转移到新的session里。
另一个有效的对策是，在session里保存用户的特定属性，在每次请求进来的时候验证他们，如果信息不匹配，则拒绝访问。可以用远程ip地址，或者是访问浏览器名称，尽管后者是不常用的。当保持ip的时候要注意，应该保持用户真实ip,而不是互联网服务供应商或大型组织的ip，如果这些变化以后，某些用户可能无法使用这个web应用，或者会有限制。
2.9 session 过期
－ 永不过期的session会更加方便这些session***。
session过期时间在服务端设置更加安全。下面是一个例子， 如何在数据库里设置session的过期时间。如果超过20分钟就调用Session.swap(20m)：
class Session < ActiveRecord::Base def self.sweep(time_ago = nil) time = case time_ago when /^(\d+)m$/ then Time.now - $1.to_i.minute when /^(\d+)h$/ then Time.now - $1.to_i.hour when /^(\d+)d$/ then Time.now - $1.to_i.day else Time.now - 1.hour end self.delete_all "updated_at < '#{time.to_s(:db)}'" end
end这节讲述了session定制需要保持连接。虽然你有过期时间，但***者也不傻， 他会保持每隔五分钟使session可用，不过期。一个简单的解决方法是，增加一个created_at到你的session表里。现在你可以删除被创建了很久的那些session，用下面的这行替换上面swap方法的：
self.delete_all "updated_at < '#{time.to_s(:db)}' OR created_at < '#{2.days.ago.to_s(:db)}'"