应该都不影响吧。早就没人会在 cookie 里存 session 数据了吧

#1 楼 @bhuztez 那不是默认手段吗？

session 默认是存在 cookie 里的，一般项目会选择存 DB 或缓存吗... 啥叫if they only use rails managed seesions...

#3 楼 @keating 难道你那神奇的 Web 程序在服务端不用存任何数据？

#3 楼 @keating rails 的 cookie 加密方式和 rack 提供的不一样

#4 楼 @bhuztez 一般项目会选择session存DB或缓存吗...

#6 楼 @keating 除非你说的一般项目永远不上线。

#7 楼 @bhuztez 你会把 session 存哪里？存数据库还是缓存？小项目的话，很少用缓存吧。

#8 楼 @keating 难道存数据库会有问题，都小项目了...

#9 楼 @bhuztez 抱歉，除非 session 数据很大，要不然我确实会让 session 存 cookie 里的，不知道为什么早就没人会在cookie里存session数据了

一般都是 cookie 吧毕竟默认的

毕竟要目标群体绝大多数人完全不懂么，有几个人知道这个东西的。

timing attack 是通过时间 profile 来破解 cookie secret 的... 但是要网速超快才有效果吧...

devise 代码里也有 secure_compare 之类的，也是为了把计算固定到常数时间

#13 楼 @luikore 具体如何攻击呢？

#15 楼 @luikore 佩服 安全专家啊。。

#15 楼 @luikore 为啥你啥都懂，好羡慕~~~

#15 楼 @luikore 如果用 Passenger 或 Unicorn 开启OOBGC 客户端遇到 Ruby GC 的概率会很低的。会更利于这种 timing attrack 攻击。

其实 Rails 的 session 是没有加密的（前面那串就是简单的序列化），只做了防串改／伪造。而防伪造的唯一工具就是那个 secret_token，但是大多数开源项目是直接把这个东西放到源码库里的。所以，大部分 Rails 开源项目的 session 是很容易伪造的。不过 devise 使用 warden 这样的 gem 做法好像有些不同，没只细看。像 Ruby China 的 session 前半部分反序列化回来是这样的：

"session_id"=>"b8d724a***7f5c27494a51906",
 "_csrf_token"=>"oWVFfkGLJ***MelmIzFnQ+GpFkE7wtn2IM2Wn0=",
 "warden.user.user.key"=>["User", [8], "$2a$****W9LTJb2zsX2y."]} 

Rails4 貌似在引入防 cookie 篡改／伪造的机制，和 session 原理一样。

跑题：http://python-china.org/member/hooopo 这个漏洞还没修，怎么才能拿到站长 session。。。

Rack::Session::Cookie 以前是可以伪造的：https://github.com/rack/rack/commit/054bc0203012c0e3ad6e1385cebe9e5d3d072b11

#3 楼 @keating 因为 Rails 在三年前已经 fix 了这个问题：https://github.com/rails/rails/commit/5e6dab8b34152bc48c89032d20e5bda1511e28fb

#1 楼 @bhuztez 大部分 Rails 项目是在 cookie 里存 session 的，因为那是默认设置。

写了一篇博客解释一下：http://hooopo.herokuapp.com/posts/1

#16 楼 @iBachue #17 楼 @KoALa 现学现卖的...

#19 楼 @hooopo rack 改用 json 了？json 比 marshal 慢很多的说...

#20 楼 @luikore 看commit message是说 1.6+ 会默认用 JSON，现在使用的 rack 还都是 1.5 的。还加了一个 okjson，不知道是不是速度快一些？

json 空间和时间占用都比 marshal 高，标准库和 yajl 效率都不如 marshal, okjson 是更慢的...

#22 楼 @luikore 看了介绍 okjson 是从 go port 过来的，连发布方式也像 go，不做成 gem，直接 copy 到项目里，避免命名冲突和依赖。设计目的是简单便携。

PS. 上次 Rails 的 json-yaml 漏洞 patch 也引人的这个 okjson。

#15 楼 @luikore 这个 timing attack 攻击条件虽然苛刻，难以利用，但是如果成功的话会带来潜在的 SQL 注入和任意代码执行漏洞。序列化换成 json 也是这个原因，yaml 做和外部输入相关的风险太大，json 是最佳的。

上面也提到了如果是在云平台内部的话延迟是可以很低的，timing attack 还是可行的。

#15 楼 @luikore 真佩服想出这些手段的人。。

#15 楼 @luikore 明文 Session 数据，加签名还是有点问题的吧。简单的 Salted Hash 方式很容易被显卡爆，除非你用几百字节的 secret，即便是 HMAC 也不会更好。

#26 楼 @bhuztez 爆 sha-256 就已经不实际了，明文+http only 往往已经足够了，尤其是 ssl 连接的情况下。另外 rack session 只是个中间件，自己改成加密 + proof of work validation 也很容易

RoR 里通常把 session 数据存在服务器端，只在 cookie 里存 session_id。使得这样猜测 session secret 的攻击更难。如果每次系统维护的时候更改 session secret，攻击就更难了。