Understand Rails Authenticity Token

主要翻译的是第一个回答，另外结合了下面的一些有用的评论，整理成文。

一直对authenticity-token 这东西不太理解，想想把SO看一遍也没啥用，索性还是翻译整理一下印象比较深刻。

用途：

当用户对一个表单进行 create, update, 或是删除一个资源的操作时,

rails应用会随机生成一个唯一的'鉴别权标'（authenticity token），并将该鉴别权标存储在session中，

然后再把它放在该表单的一个隐藏区域中(hidden_field)。

当用户提交表单的时候， rails会查找鉴别权标(表单的隐藏区域里的那个)，

并将它和先前存储在session中的鉴别权标想比对,

如果两者相同则用户的请求得以继续发送.

Why we need it:

既然鉴别权标是存储在session中的, 客户端也就不知道它的值.

（注：此处客户端应该指的是在下文提到的案例中的可以运行恶意javascript代码的站点。）

这样做的好处是, 可以防止非当前rails应用表单的提交行为，也就是说为了确保客户向rails应用

发送的 POST/PUT/DELETE 请求是来自客户的浏览器, 而不是来自第三方攻击者.

假设你在使用A站点,你已经登陆到该站点了,一切正常, 接着你去使用B站点了,

你看到了一张很好看的图, 点开它想看大图。

这时候, 如果B站点上有一些恶意代码, 它可能会向A站点发送请求(因为你已经登陆了A站点)，

要求删除你的账户，类似于发送请求到: http://serviceA.com/close_account.

这就是大家熟知的跨站请求伪造( CSRF, Cross Site Request Forgery )攻击。

如果A站点使用了鉴别权标的话, 这种攻击方法就失效了,

因为请求是从B服务站点发出的, 它不含有正确的鉴别权标, 请求也就不能继续发送了。

ps: 当然, 如果攻击者获取了A站点的表单的隐藏元素, 进而得到了该用户的唯一鉴别权标,

比如, hijack了你在A站点的session,这样一来, 鉴别权标就不再保护你的请求了. 这种情况是有可能发生的！

注意:

rails只会检查 POST, PUT(在rails 4 中被改为 PATCH ) 和 DELETE 请求的鉴别权标.

GET 请求是不会被检查的.为什么呢? 很简单,

因为 HTTP 规范约定了 GET 请求不能创建, 改变, 删除服务器上的资源的.

另一方面，GET请求没必要是idempotent的( 所谓idempotent,也就是说不管你调用多少遍,得到的结果都是一样的,

注: 在数学中,该词意为等幂, 此处不知道该怎么翻译=。= )

安全也就意味着没有函数副作用。

（函数副作用指当调用函数时, 除了返回函数值之外, 还对主调用函数产生附加的影响,

如修改全局变量或修改参数。严格的函数式语言要求函数必须无副作用.具体参考中文wiki )

idempotent意味着不管调用多少次服务,都不会累加副作用。

所有的安全服务从本质上来说都是idempotent的，因为它们没有副作用。

对当前的一个资源多次发送GET请求, 每次都可能会得到不同的结果(因为资源可能会被服务器更新)，

但是它仍然是安全的, 也就是idempotent的.

ps：上面这段翻译了好几遍，还咨询了@蕊的安，对于翻译长了不少姿势，

不过还是不太确定，希望有朋友可以指正。原文如下：

Safe means no side-effects. Idempotent means the same side effect no matter how many time a service is called.

All safe services are inherently idempotent because there are no side effects. Calling GET on a current-time

resource multiple times would return a different result each time, but it's safe (and thus idempotent).

综上, 你应该使用鉴别权标来保护你的 POST,PUT(PATCH), DELETE 请求。

当然, 从Rails 3.0.4 版本以后, rails是默认开启 authenticity token来阻止CSRF攻击的。