你公司网络上的Web应用程序是否容易遭受跨站请求伪造攻击呢？这是一个值得讨论的问题，因为一次成功的CSRF攻击的后果往往是破坏性的，会花费公司的大量金钱，甚至导致机密信息丢失。
什么是CSRF（跨站请求伪造）？
CSRF攻击通过使应用程序相信导致此活动的请求来自应用程序的一个可信用户，从而诱使应用程序执行一种活动（如转移金融资产、改变账户口令等）。用户可以是公司的一位雇员，企业合伙人，或者是一个外部的客户。
CSRF攻击依赖于这样一个事实：许多Web应用程序使用cookie，其终结时间相对较长，从而使用户在通过最初的验证之后仍能访问应用程序。
要使CSRF攻击得逞，潜在的受害者必须使用其浏览器进行验证，并登录到公司的Web应用程序。只要用户没有退出应用程序，浏览器中的应用程序的cookie没被终止，该用户就是CSRF攻击的一个潜在受害者。
CSRF攻击如何运行？
为执行CSRF攻击，黑客需要把一个特别伪造的到达公司应用程序的链接放置到其它网页上或放到电子邮件中。但黑客并不把此链接作为一个超级链接，而是将它放在一个图像或脚本标签中，从而隐藏链接，将链接作为图像或脚本的源。
下面是一个来自维基百科的例子：
- img src="http://bank.example.com/withdraw?account=bob&amount=100000&for=mallory"
现在，如果受害者在其浏览器中查看包含此图像的网页，或读取包含此链接的电子邮件程序，浏览器会跟踪链接，试图获取图片。如果受害者近来登录过此站点，其浏览器会提供一个用于验证的cookie，告诉浏览器将10万美元从“bob”的账户转移给“mallory”。一般而言，受害人不会知道执行了什么业务（至少在检查其账户余额之前），因为受害人的浏览器在执行业务时并不从bank.example.com那里显示任何反馈（如一个确认网页）。
在上面的例子中，该链接专门针对bob，限制其实用性。在实践中，黑客有可能使用一个更为通用的链接，可适用于碰巧登录到企业Web应用程序的任何潜在受害者。但对黑客来说，伪造一次成功的CSRF攻击并不容易，因为在攻击过程中，黑客并不能从Web应用程序获得任何反馈。这意味着，只有从你的Web应用程序发出的响应完全可预测时，这种攻击才可能发生。
所以说，一个易于遭受攻击的Web应用程序必须：
1、 准许用户用一个合法的cookie进行访问，其到期时间必须足够长。
2、 在提交适当的URL（可从外部站点发送）时，准许执行交易。
3、 以一种可预测的方法进行响应。
CSRF攻击可以达到什么目标？
虽然CSRF攻击仅能在Web应用程序中执行业务，其后果却可能蔓延很广。例如，这会导致受害人在不知情的情况下向论坛发帖子、订阅邮件列表、网购或股票交易，或变更用户名或口令。对受到受害人防火墙保护的所有应用程序而言，CSRF攻击都能发挥作用。如果受害者的机器位于受限的某个IP范围，就会使得黑客访问此范围内的相关应用程序。
还有一种CSRF变种，称为登录CSRF，它能够使用攻击者的登录凭证记录受害人在Web应用程序中的活动。这将使黑客以后可以登录进入并检索关于受害人的信息，如用户活动历史，或由受害者所提交的任何机密信息。
五大方法减轻Web应用程序易受CSRF攻击的风险
限制验证cookie的到期时间。这些cookie的合法时间越短，黑客利用你的Web应用程序的机会就越小。不过，这个时间越短，用户就越不方便。因此，你需要在安全性和方便性之间进行平衡。
执行重要业务之前，要求用户提交额外的信息。要求用户在进行重要业务前输入口令，这可以防止黑客发动CSRF攻击（只要浏览器中没有包含口令），因为这种重要信息无法预测或轻易获得。
使用秘密的无法预测的验证符号。当保存在用户浏览器中的cookie仅由一次会话确认时，CSRF攻击才会有效。所以在每次HTTP请求（当然攻击者无法提前知道）中都有附加的特定会话的信息，这样就可以挫败CSRF攻击。不过，如果这种应用程序存在跨站脚本漏洞，黑客就有可能访问这种验证符号。
使用定制的HTTP报头。如果执行交易的所有请求都使用XMLHttpRequest并附加一个定制的HTTP报头，同时拒绝缺少定制报头的任何请求，就可以用XMLHttpRequest API来防御CSRF攻击。由于浏览器通常仅准许站点将定制的HTTP报头发送给相同站点，从而了防止由CSRF攻击的源站点所发起的交易。
检查访问源的报头。在浏览者发送HTTP请求时，它通常会包含源自访问源报头的URL。理论上讲，你可以使用这些信息来阻止源自其它任何站点（而不是来自Web应用程序自身）的请求。不过，访问源报头并不总是可用的，（例如，有些单位由于私密性的缘故而将它剥离了），或者这个报头容易被欺骗，所以说，这条措施并不真正有效。
推荐专题：十大工具及应用策略搞定OWASP热门威胁
