Rails安全导读【一】 - 编程入门网

因此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.邪恶的用户得到

凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!