有效预防跨站请求伪造攻击

严格意义上讲，CSRF攻击不能归类为注入攻击，因为CSRF攻击的实现途径远远不止XSS注入这一条。通过XSS来实现CSRF攻击易如反掌，但对于设计不佳的网站，一条正常的链接都能造成CSRF攻击。

例如，一论坛网站的发帖是通过GET请求访问，单击“发帖”之后JavaScript把发帖内容拼接成目标URL并访问：

http：//www.2cto.com/bbs/create_post.phptitle=标题&content=内容

那么，只需要在论坛中发一个帖，包含一个链接：

http：//www.2cto.com/bbs/create_post.phptitle=***&content=##

只要有用户单击了这个链接，那么他们的账户就会在不知情的情况下发布了这一帖子。

是否可以效仿上面应对XSS攻击的做法来过滤用户输入，不允许发布这种含有站内操作URL的链接，来解决这个问题呢？这么做可能会有点用，但阻挡不了CSRF攻击，因为攻击者可以通过QQ或其他网站把这个链接发布上去，为了伪装可能还压缩一下网址，这样单击到这个链接的用户还是一样会“中招”。所以对待CSRF攻击的视角需要和对待XSS攻击有所区别。CSRF攻击并不一定要有站内的输入，因为它并不属于注入攻击，而是请求伪造。被伪造的请求可以是任何来源，所以唯一的方法就是过滤请求的处理者。

请求可以从任何一方发起，但发起请求的方式多种多样，几乎没有彻底杜绝CSRF攻击的方式，一般的做法，是以各种方式提高攻击的门槛。(www.xing528.com)

首先，可以改良站内API的设计。对于发布帖子这一类创建资源的操作，一般只接受POST请求，而GET请求则只浏览而不改变服务器端资源。当然，最理想的做法是使用REST风格的API设计，这样GET、POST、PUT、DELETE四种请求方法对应资源的读取、创建、修改、删除。但现在的浏览器基本不支持在表单中使用PUT和DELETE请求方法。这时可以使用ajax提交请求（例如通过jquery-form插件），也可以使用隐藏域指定请求方法，然后用POST模拟PUT和DELETE。这么一来，不同的资源操作区分得非常清楚，从而把问题域缩小到了非GET类型的请求上。这时，攻击者已经不可能通过发布链接来伪造请求了。但他们仍可以发布表单，或者在其他站点上使用肉眼不可见的表单，在后台用JavaScript操作，伪造请求。

接下来，就可以用比较简单、也比较有效的方法来防御CSRF攻击，即“请求令牌”。“请求令牌”和“同步令牌”的原理是一样的，只不过目的不同，后者是为了解决POST请求重复提交问题，前者是为了保证收到的请求一定来自预期的页面。实现方法非常简单，首先服务器端要以某种策略生成随机字符串，作为令牌（token），保存在Session里。然后在发出请求的页面，把该令牌以隐藏域的形式，与其他信息一并发出。在接收请求的页面，把接收到的信息中的令牌与Session中的令牌比较，只有一致的时候才处理请求，否则返回HTTP 403拒绝请求或者要求用户重新登录验证身份。

请求令牌虽然使用起来简单，但并非不可破解，使用不当会增加安全隐患。使用请求令牌来防止CSRF攻击有以下几点要注意：

1）虽然请求令牌原理和验证码有相似之处，但不应该像验证码一样，全局使用一个Session Key。因为请求令牌的方法在理论上是可破解的，破解方式是解析来源页面的文本，获取令牌内容。如果全局使用一个Session Key，那么危险系数会上升。原则上来说，每个页面的请求令牌都应该放在独立的Session Key中。在设计服务器端的时候，可以稍加封装，编写一个令牌工具包，将页面的标识作为Session中保存令牌的键。

2）在ajax技术应用较多的场合，因为很多请求是JavaScript发起的，使用静态的模版输出令牌值或多或少有些不方便。但切勿提供直接获取令牌值的API。这么做无疑是锁上了大门，却又把钥匙放在门口，让的请求令牌退化为同步令牌。

3）无论是普通的请求令牌，还是验证码，服务器端验证过一定要销毁。忘记销毁用过的令牌是很低级但杀伤力很大的错误。

总体来说，作为开发者，需要做的就是尽量提高破解难度。当破解难度达到一定程度，网站就逼近于绝对安全的位置了（虽然不能到达）。上述请求令牌方法，是最有可扩展性的，因为其原理和CSRF原理是相克的。CSRF攻击难以防御之处就在于对服务器端来说，伪造的请求和正常的请求本质上是一致的。而请求令牌的方法，则是获得这种请求上的唯一区别——来源页面不同。另外，还可以做进一步的工作，例如让页面中验证码动态化，以进一步提高攻击者的门槛。