226
CSRF冒充用户之手
起初我一直弄不清楚CSRF 究竟和XSS 有什么区别，后来才明白CSRF 和XSS 根本是两个不同维度上的分类。XSS 是实现CSRF 的诸多途径中的一条，但绝对不是唯一的一条。一般习惯上把通过XSS 来实现的CSRF 称为XSRF。
CSRF 的全称是“跨站请求伪造”，而XSS 的全称是“跨站脚本”。看起来有点相似，它们都是属于跨站攻击——不攻击服务器端而攻击正常访问网站的用户，但前面说了，它们的攻击类型是不同维度上的分类。CSRF 顾名思义，是伪造请求，冒充用户在站内的正常操作。我们知道，绝大多数网站是通过cookie 等方式辨识用户身份（包括使用服务器端Session 的网站，因为Session ID 也是大多保存在cookie 里面的），再予以授权的。所以要伪造用户的正常操作，最好的方法是通过XSS 或链接欺骗等途径，让用户在本机（即拥有身份cookie 的浏览器端）发起用户所不知道的请求。
严格意义上来说，CSRF 不能分类为注入攻击，因为CSRF 的实现途径远远不止XSS 注入这一条。通过XSS 来实现CSRF 易如反掌，但对于设计不佳的网站，一条正常的链接都能造成CSRF。
例如，一论坛网站的发贴是通过GET 请求访问，点击发贴之后JS 把发贴内容拼接成目标URL 并访问：
https://www.yunsec.net/bbs/create_post.php?title=标题&content=内容
那么，我只需要在论坛中发一帖，包含一链接
https://www.yunsec.net/bbs/create_post.php?title=我是脑残&content=哈哈
只要有用户点击了这个链接，那么他们的帐户就会在不知情的情况下发布了这一帖子。可能这只是个恶作剧，但是既然发贴的请求可以伪造，那么删帖、转帐、改密码、发邮件全都可以伪造。
如何解决这个问题，我们是否可以效仿上文应对XSS 的做法呢？过滤用户输入， 不允许发布这种含有站内操作URL 的链接。这么做可能会有点用，但阻挡不了CSRF，因为攻击者可以通过QQ 或其他网站把这个链接发布上去，为了伪装可能还使用bit.ly 压缩一下网址，这样点击到这个链接的用户还是一样会中招。所以对待CSRF ，我们的视角需要和对待XSS 有所区别。CSRF 并不一定要有站内的输入，因为它并不属于注入攻击，而是请求伪造。被伪造的请求可以是任何来源，而非一定是站内。所以我们唯有一条路可行，就是过滤请求的处理者。
比较头痛的是，因为请求可以从任何一方发起，而发起请求的方式多种多样，可以通过iframe、ajax（这个不能跨域，得先XSS）、Flash 内部发起请求（总是个大隐患）。由于几乎没有彻底杜绝CSRF 的方式，我们一般的做法，是以各种方式提高攻击的门槛。
首先可以提高的一个门槛，就是改良站内API 的设计。对于发布帖子这一类创建资源的操作，应该只接受POST 请求，而GET 请求应该只浏览而不改变服务器端资源。当然，最理想的做法是使用REST 风格的API 设计，GET、POST、PUT、DELETE 四种请求方法对应资源的读取、创建、修改、删除。现在的浏览器基本不支持在表单中使用PUT 和DELETE 请求方法，我们可以使用ajax 提交请求（例如通过jquery-form 插件，我最喜欢的做法），也可以使用隐藏域指定请求方法，然后用POST 模拟PUT 和DELETE （Ruby on Rails 的做法）。这么一来，不同的资源操作区分的非常清楚，我们把问题域缩小到了非GET 类型的请求上——攻击者已经不可能通过发布链接来伪造请求了，但他们仍可以发布表单，或者在其他站点上使用我们肉眼不可见的表单，在后台用js 操作，伪造请求。
接下来我们就可以用比较简单也比较有效的方法来防御CSRF，这个方法就是“请求令牌”。读过《J2EE 核心模式》的同学应该对“同步令牌”应该不会陌生，“请求令牌”和“同步令牌”原理是一样的，只不过目的不同，后者是为了解决POST 请求重复提交问题，前者是为了保证收到的请求一定来自预期的页面。实现方法非常简单，首先服务器端要以某种策略生成随机字符串，作为令牌（token），保存在Session 里。然后在发出请求的页面，把该令牌以隐藏域一类的形式，与其他信息一并发出。在接收请求的页面，把接收到的信息中的令牌与Session 中的令牌比较，只有一致的时候才处理请求，否则返回HTTP 403 拒绝请求或者要求用户重新登陆验证身份。
请求令牌虽然使用起来简单，但并非不可破解，使用不当会增加安全隐患。使用请求令牌来防止CSRF 有以下几点要注意：
虽然请求令牌原理和验证码有相似之处，但不应该像验证码一样，全局使用一个Session Key。因为请求令牌的方法在理论上是可破解的，破解方式是解析来源页面的文本，获取令牌内容。如果全局使用一个Session Key，那么危险系数会上升。原则上来说，每个页面的请求令牌都应该放在独立的Session Key 中。我们在设计服务器端的时候，可以稍加封装，编写一个令牌工具包，将页面的标识作为Session 中保存令牌的键。
在ajax 技术应用较多的场合，因为很有请求是JavaScript 发起的，使用静态的模版输出令牌值或多或少有些不方便。但无论如何，请不要提供直接获取令牌值的API。这么做无疑是锁上了大门，却又把钥匙放在门口，让我们的请求令牌退化为同步令牌。
第一点说了请求令牌理论上是可破解的，所以非常重要的场合，应该考虑使用验证码（令牌的一种升级，目前来看破解难度极大），或者要求用户再次输入密码（亚马逊、淘宝的做法）。但这两种方式用户体验都不好，所以需要产品开发者权衡。
无论是普通的请求令牌还是验证码，服务器端验证过一定记得销毁。忘记销毁用过的令牌是个很低级但是杀伤力很大的错误。我们学校的选课系统就有这个问题，验证码用完并未销毁，故只要获取一次验证码图片，其中的验证码可以在多次请求中使用（只要不再次刷新验证码图片），一直用到Session 超时。这也是为何选课系统加了验证码，外挂软件升级一次之后仍然畅通无阻。
如下也列出一些据说能有效防范CSRF，其实效果甚微的方式甚至无效的做法。
通过referer 判定来源页面：referer 是在HTTP Request Head 里面的，也就是由请求的发送者决定的。如果我喜欢，可以给referer 任何值。当然这个做法并不是毫无作用，起码可以防小白。但我觉得性价比不如令牌。
过滤所有用户发布的链接：这个是最无效的做法，因为首先攻击者不一定要从站内发起请求（上面提到过了），而且就算从站内发起请求，途径也远远不知链接一条。比如<img src=”./create_post.php” /> 就是个不错的选择，还不需要用户去点击，只要用户的浏览器会自动加载图片，就会自动发起请求。
在请求发起页面用alert 弹窗提醒用户：这个方法看上去能干扰站外通过iframe 发起的CSRF，但攻击者也可以考虑用window.alert = function(){}; 把alert 弄哑，或者干脆脱离iframe，使用Flash 来达到目的。
总体来说，目前防御CSRF 的诸多方法还没几个能彻底无解的。所以CSDN 上看到讨论CSRF 的文章，一般都会含有“无耻”二字来形容（另一位有该名号的貌似是DDOS 攻击）。作为开发者，我们能做的就是尽量提高破解难度。当破解难度达到一定程度，网站就逼近于绝对安全的位置了（虽然不能到达）。上述请求令牌方法，就我认为是最有可扩展性的，因为其原理和CSRF 原理是相克的。CSRF 难以防御之处就在于对服务器端来说，伪造的请求和正常的请求本质上是一致的。而请求令牌的方法，则是揪出这种请求上的唯一区别——来源页面不同。我们还可以做进一步的工作，例如让页面中token 的key 动态化，进一步提高攻击者的门槛。
摘自中国云安网(www.yunsec.net) 原文：https://www.yunsec.net/a/security/web/jbst/2011/1125/9611_2.html
最后更新：2017-01-04 22:34:54