解析跨站请求伪造漏洞
　|　　|　　|　　|　　|　　|　　|　　|　　|　　|　　|　
您现在的位置：
解析跨站请求伪造漏洞
天诺时空 版权所有！未经授权禁止转载、摘编、复制或建立镜像，如有违反，追究法律责任。
Copyright &
All Rights Reserved本类阅读排行
本类推荐阅读
本类好评文章测试技术与自动化（25）

跨站请求伪造（即CSRF）被Web安全界称为诸多漏洞中“沉睡的巨人”，其威胁程度由此“美誉”便可见一斑。本文将简单介绍该漏洞，并详细说明造成这种漏洞的原因所在，以及针对该漏洞的黑盒测试与灰盒子测试具体方法和示例，最后提提了一些防范该攻击的建议，希望本文对读者的安全测试能够有所启发。
一、CSRF概述
我们首先来了解一下什么是跨站请求伪造（CSRF）？跨站请求伪造是一种挟制终端用户在当前已登录的Web应用程序上执行非本意的操作的攻击方法。攻击者只要借助少许的社会工程诡计，例如通过电子邮件或者是聊天软件发送的链接，攻击者就能迫使一个Web应用程序的用户去执行攻击者选择的操作。例如，如果用户登录网络银行去查看其存款余额，他没有退出网络银行系统就去了自己喜欢的论坛去灌水，如果攻击者在论坛中精心构造了一个恶意的链接并诱使该用户点击了该链接，那么该用户在网络银行帐户中的资金就有可能被转移到攻击者指定的帐户中。
当CSRF针对普通用户发动攻击时，将对终端用户的数据和操作指令构成严重的威胁；当受攻击的终端用户具有管理员帐户的时候，CSRF攻击将危及整个Web应用程序。
二、造成CSRF的原因
跨站请求伪造能否得逞，与以下几个方面密不可分，分别是浏览器对会话的处理，攻击者对Web应用有关URL的了解，应用程序赖以管理会话的信息对浏览器的透明性以及各种能够引发资源请求HTML标签等。下面分别加以解释。
首先，我们来了解一些Web浏览器对于Cookie和HTTP身份验证信息之类的会话信息的处理方式。目前，浏览器会自动地发送标识用户对话的信息，而无需用户干预，换句话说，当浏览器发送这些身份信息的时候，用户根本感觉不到。假设站点A上有一个Web应用程序，并且受害者正好已经在该站点上通过了身份认证，这时，站点会向受害者发送一个cookie作为响应，这个cookie的作用是什么呢？主要是被站点作为用户会话的标志，即如果站点收到了带有受害者的cookie的请求，那么它就会把这个请求看作是已登录的受害者发来的。一般情况下，浏览器收到站点设置的cookie之后，每当向该站点发送请求的时候，浏览器都会“自动地”连同该cookie一起发出。
然后，我们再来讨论一下攻击者对Web应用程序URL的了解。如果应用程序没有在URL中使用跟会话有关的信息的话，那么通过代码分析或者通过访问该应用程序并查看嵌入HTML/JavaScript中的URL以及表单来了解应用程序有关的URL、参数和容许值。
接下来，我们讨论一下应用程序赖以管理会话的信息对浏览器的透明性问题。我们知道，为了提高Web应用的便利性，用来管理会话的信息，例如Cookie或者基于HTTP的身份验证（例如HTTP基本认证、非基于表单的认证）等敏感信息，都是由浏览器来存放的，并在每当向需要身份验证的应用程序发送请求时自动捎带上这些信息。也就是说，浏览器可以访问会话管理信息，如果Web应用程序完全依赖于这类信息来识别一个用户会话，这就为跨站请求伪造创造了条件。
上面所说的三个因素，是跨站请求伪造攻击的必要的条件，而下面所说的，是一个“锦上添花”的因素，即没有它也能发动跨站请求伪造攻击，但是有了它能使该攻击更加容易。这就是存在多种HTML标签，如果页面内出现这些标签，会立刻引起浏览器对http[s]资源的访问，例如图像标签img便是其中之一。
为简单起见，我们这里讨论GET方式的URL（不过这里讨论的内容同样适用于POST请求）。如果受害者已经通过身份验证，那么当他提交其它请求时，该cookie也会自动地随之发送（如图，这里用户正在访问上的一个应用程序 ）。
图1& 浏览器发送请求的同时还自动发送cookie
那么，什么情况下会引起发送这个GET请求呢？这可就有多种可能了，首先当用户正常使用该Web应用程序的过程中有可能引发这个GET请求；其次，当用户直接在浏览器地址栏中键入该URL时也会引发该GET请求；再者，用户单击了指向该URL的链接，即使该链接位于该应用程序外部，也会引发该GET请求。
对于应用程序来说，它是无法区分上面的这些差别的。特别是第三种可能是非常危险的。有许多技术（和漏洞）可以隐藏一个链接的真实属性。链接可以嵌入电子邮件消息中，也可以出现在存心不良的Web站点，然后引诱用户浏览该站点，例如链接出现在位于其他主机上（其它Web 站点、HTML格式的电子邮件消息，等等）的内容中，并且指向应用程序的资源。如果用户单击了该链接，由于他已经通过了站点上Web 应用程序的认证，所以浏览器就会发出一个GET请求给该Web 应用程序，同时将验证信息（包含会话id的cookie）一并发过去。这样会导致在Web
应用程序上执行一个有效操作——该操作可能不是该用户所想要的，例如一个引起在网络银行上进行转帐恶意的链接，等等。
如前所述，通过使用诸如img之类的标签，甚至不需要用户点击具体的链接就能发动攻势。假设攻击者向用户发送了一封电子邮件，诱骗用户访问一个URL，而该URL则指向一个包含下列HTML内容（注意，内容已作精简）的页面：
[html][body]
(img src=”pany.example/action” width=”0” height=”0”)
[/body][/html]
用时将[]换成&&
当浏览器显示该页面时，它也将设法显示这个指定宽度为0的图像，即该图像是不可见的——这会导致自动向站点中的Web 应用程序发送一个请求。要紧的是，浏览器不管该图像URL实际是否指向一个图片，只要src字段中规定了URL，就会按照该地址触发一个请求。当然，这里有一个前提，那就是浏览器没有禁止下载图像——实际上浏览器都配置成允许下载图像，因为禁用图像后大多数Web应用程序的可用性就会大打折扣。与跨站请求伪造有关的HTML标签问题是总结如下：
页面中有许多标签会导致自动发出HTTP请求（img标签便是其中之一）；
浏览器无法断定img标签所引用的资源到底是不是图像以及是否是有害的；
当加载图像时，根本就不考虑所涉及的图像所在的位置，即表单和图像不必位于同一个主机上，甚至可以不再同一个域内。虽然这是一个非常便利的特性，但是却给应用程序的隔离制造的障碍。正是由于与Web 应用程序无关的HTML内容可以引用应用程序中的各种组件，以及浏览器可以自动为该应用程序构造一个有效的请求这两个事实才导致了这种攻击的出现。这意味着，正确的URL必须包含用户会话有关的信息，而攻击者却无法得知这些信息，因此不可能识别这样的URL。
对于集成了邮件/浏览器功能的工作平台，跨站请求伪造问题可能更为严重，因为，仅仅显示一封包含该图像的电子邮件就会导致请求及有关浏览器cookie一起向Web应用程序发去。
另外，攻击者还可以对这些东西进行伪装，例如引用貌似合法的图像URLs，例如
(img src=”https://[attacker]/picture.gif” width=”0” height=”0”)
用时将()换成&&
这里，[attacker]是攻击者控制下的站点，并通过重定向机制将 ]/picture. gif转向 ]/action。
如果Web应用程序的会话信息完全靠浏览器来提供的话，那么这样的Web应用程序也都易于受到攻击，其中包括那些仅依赖于HTTP身份验证机制的那些应用程序，因为浏览器知道这些验证信息，并会在发送每个请求的时候自动附带这些验证信息。当然，这不包括基于表单的认证，它只发出一次，并且生成了有关会话信息的表单——当然，如果这样的信息就像cookie那样进行简单的传递的话，这就有回到了之前的情形。
三、跨站请求伪造情景分析
假如受害者已经登录到一个防火墙的Web管理应用程序上。我们知道，当用户登录时，Web应用会进行身份验证，通常是要求用户提供其用户名和密码，如果用户名和密码正确则会通过身份认证；随后，Web应用会在客户端存放一个小文本文件，即cookie来存放会话信息。
假设防火墙有一个基于Web的管理接口，我们称之为防火墙Web管理程序，其中具有一个这样功能或者说一个页面，即允许认证的用户通过规则编号删除指定的规则，或者通过输入“*”删除全部已配置的规则——这的确是一个非常危险的功能。该删除页面显示如下。假如该表单（我们已经对其进行了简化）引起一个GET请求，那么该请求将如下所示
(删除一号规则）
(删除全部规则)。
该范例是故意十分天真的，这是为了便于说明CSRF的危险性。删除防火墙规则的页面如下所示：
图2& 防火墙管理页面
因此，如果我们键入值“*”，并按下删除按钮，就会提交下列GET请求：
其结果当然是删除所有防火墙规则了，呵呵，后果很严重呀！如下图所示：
图3& 删除所有防火墙规则
实际上，这并非唯一可能的情形。用户也可以手动提交URLhttps://[target ]/fwmgt /delete ?Rule =*来达到相同的效果。或者通过单击一个直接指向以上URL的链接或通过重定向到达以上URL的链接。或者同样也可访问一个嵌入了指向相同的URL的img标签的HTML页面。在这些情况下，如果用户当前已经登录到防火墙管理程序，那么该请求将得逞并会修改防火墙的配置。
此外，我们还可以设想攻击是针对敏感的应用程序、进行自动的拍卖投标、转帐、订货、改变关键软件组件的配置等等。
更有趣的是，这些漏洞都可以在防火墙之后进行利用，即只要被攻击的链接是受害者所能访问的即可，而不必非得攻击者能够直接访问才行。
尤其是，它可以是任何内部网Web服务器，例如，之前提到的防火墙管理工作站，它大不可能暴露于国际互联网。对于那些既可以用作攻击矢量，有是攻击目标的应用程序（例如web邮件应用程序），情况就更糟了：如果这样的应用程序是易受攻击的，那么用户阅读包含CSRF攻击的信件时很明显已经登录到程序了，它会以web邮件应用程序为目标，并让邮件应用程序执行删除信件、发送消息等动作，而这些动作看起来将像是用户本身所做的。
四、黑盒子测试
为了进行黑盒测试，需要知道受限制的(认证的)区域的URL。如果您具有有效证书，那么就可以扮演攻击者和受害者这两种角色了。在这种情况下，仅仅通过浏览应用程序您能获悉受测试的有关URLs。否则，如果没有有效的证书可用的话，必须组织一个实际的攻击，以引诱一个合法的已登录的用户来点击某个适当的链接，这可以通过社会工程来进行。
不管怎样，测试案例可以如下构造：
把u改成受测的URL，例如u=/action
构造一个HTML页面，让它包含引用url u（规定全部相关参数；使用GET方式的时候很简单，如果使用的是POST请求，则需要诉诸于一些JavaScript代码）的HTTP请求；
确保合法的用户已经登录该应用程序；
引诱他点击一个链接，而该链接指向受测试的URL（如果你无法冒充用户的话，则需要借助于社会工程）；
观察结果，如检测Web服务器是否执行了该请求。
五、灰盒子测试
对应用程序进行安全评估的时候，要调查其会话管理是否是易受攻击的。如果会话管理完全依赖于客户端的值（即对于浏览器来说也是可用的），那么该应用程序是易受攻击的。通过这些客户端的值，我们就弄明白了Cookie和HTTP认证证书（基本认证及其他形式的HTTP认证；不是基于表单的认证，即应用程序级别的认证）。对于没有此弱点的应用程序来说，它在URL中必须包括跟会话session有关信息，并且要采取一种令用户无法辨认或者不可预见的形式([3]使用术语secret来表示这种信息单元)。
可以经由HTTP的GET请求访问的资源很容易受弱点的影响，但是POST请求可以通过JavaScript实行自动化，并且也易于受到攻击；因此，单独使用POST不足以防止CSRF漏洞的发生。
六、跨站请求伪造对策
跨站请求伪造的危害非常之大，所以无论是用户还是开发人员都应该引起足够的重视，下面是给Web应用程序终端用户和Web应用程序开发人员的一些有用的建议。
因为CSRF漏洞有流行之趋势，所以建议用户遵循最佳实践来降低风险，可以降低风险的习惯包括：
使用Web应用程序之后立即登出
不要让浏览器保存用户名/口令，也不要让站点“记住”您不要使用同一个浏览器同时访问敏感的应用程序和随意冲浪；如果必须同时做多件事情的话，最好单独使用不同的浏览器。
对于支持HTM格式邮件/浏览器集成是式软件以及集成了新闻阅读程序/浏览器的软件都会带来额外的风险，因为只要查看邮件或者新闻就有可能被迫执行一次攻击，所以使用这类软件时格外小心。
开发人员应当向URL添加跟会话有关信息。该攻击类型之所以得逞，是因为会话是由cookie唯一标识的，并且该cookie是由浏览器自动发送的。
如果我们在URL级别为会话生成其它相关信息，那么就会给攻击者为发动攻击而了解URL的结构造成更多的障碍。
至于其它的对策，虽然也无法解决该问题，但是能够使得利用该漏洞更加困难，例如使用POST而不是GET。虽然POST请求可以通过JavaScript进行模仿，但是它提高了发动这种攻击的难度。使用中间确认页也能带来相同的效果，比如“您确信要这样做吗？”之类的页面。虽然攻击者可以绕过这些措施，但是这些措施提供了实施攻击的难度。因此，不能完全依赖这些手段来保护您的应用程序。自动登出机制也能减轻这种攻击带来的危害，但这最终依赖于具体情况（一个整天跟有这种漏洞的网络银行程序打交道的用户所面临的风险要远远大于临时使用同一网络银行的用户所面临的风险）。
跨站请求伪造，即CSRF，是一种非常危险的Web安全威胁，它被Web安全界称为“沉睡的巨人”，其威胁程度由此“美誉”便可见一斑。本文不仅对跨站请求伪造本身进行了简单介绍，还详细说明造成这种漏洞的原因所在，以及针对该漏洞的黑盒测试与灰盒子测试具体方法和示例，最后提提了一些防范该攻击的建议，希望本文对读者的安全测试能够有所启发。
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：111054次
积分：1474
积分：1474
排名：千里之外
原创：13篇
转载：162篇
(3)(1)(7)(3)(2)(13)(8)(5)(5)(12)(3)(28)(6)(6)(8)(4)(6)(1)(10)(10)(6)(2)(3)(6)(17)security（4）
本文的上篇中，我们着重介绍了跨站请求伪造的原理，并指出现有的安全模型并不能真正防御这种攻击。在下篇中，我们将向读者介绍在一些大型站点上发现的几个严重的CSRF漏洞，攻击者利用这些漏洞不仅能够采集用户的电子邮件地址，侵犯用户隐私并操控用户帐户。如果金融站点出现了跨站请求伪造漏洞的话，这些漏洞甚至允许攻击者从用户的银行帐户中划走资金。为了全面的防御CSRF攻击，建议对服务器端进行改造。此外，本文还会介绍服务器端解决方案应具备的特征，如果缺乏这些特性，就会导致CSRF保护措施不必要地妨碍典型的web浏览活动。除此之外，本文还将介绍一个客户端浏览器插件，有了该插件的保护，即使站点自身没有保护措施的情况下，用户也能免受某些类型的CSRF攻击的滋扰。跨站请求伪造是一种严重的Web漏洞，希望大家能提高对CSRF攻击的防范意识。
下面是安全人员于今年在现实世界中、Metafilter 和YouTube曾经出现过的跨站请求伪造漏洞。
一、纽约时报网站上的跨站请求伪造漏洞
今年，安全人员曾在上发现了一个CSRF弱点，它使得攻击者可以获取用户的电子邮件地址。如果您是的会员，那么任何站点都能利用该漏洞来获取您的电子邮件地址，并以您的名义来发送垃圾邮件。
这个攻击充分地利用了的“Email This”功能，它允许用户将一篇文章的链接发送给用户指定的收信人的电子邮件地址，如果需要的话，同时可以附带个人消息。收信人将收到一封类似下面的电子邮件：
This page was sent to you by: [USER’S EMAIL ADDRESS]Message from sender:Thought you’d be interested in this.NATIONAL DESKResearchers Find Way to Steal Encrypted DataBy JOHN MARKOFFA computer security research group has developed a way to steal encrypted information from computer hard disks.
要想利用该漏洞，攻击者需要设法让已登录用户的浏览器向的“Email this”页面发送一个请求。由于接收“Email this”请求的页面没有对CSRF攻击采取有效措施，所以只要设法让用户的浏览器向发送一个精心构造的请求，就会导致发送一封电子邮件到攻击者所指定的地址。如果攻击者把收信人电子邮件地址指定为他自己的电子邮件地址，他将收到一封来自电子邮件，当然其中必定含有某用户的电子邮件地址。
这个弱点的利用方法很简单。上的每篇文章都有一个指向“Email this”页面的链接，而“Email this”页面含有一个表单，用户可以在其中输入一个收信人的电子邮件地址。这个表单还包含一些隐形的变量，这些变量随文章的不同而不同，所以这些隐形的变量具有唯一性。下面是表单示例：
{formaction=&&method=&POST&enctype=&application/x-www-form-urlencoded&}{nput type=&checkbox& id=&copytoself&name=&copytoself& value=&Y&}{input id=&recipients& name=&recipients&type=&text& maxlength=&1320& value=&&}{nput type=&hidden& name=&state& value=&1&}{extarea id=&message& name=&personalnote&maxlength=&512&}/textarea}{nput type=&hidden& name=&type& value=&1&}{nput type=&hidden& name=&url&value=&[...]&}nput type=&hidden& name=&title&value=&[...]&}nput type=&hidden& name=&description&value=&[...]&}..{form}
因为没有区分GET和POST请求，所以攻击者可以把该表单转换成一个GET请求（这样就可以将来将其用于{mg}签中）。把表单转换成一个GET请求时，需要将每个参数附加到URL的查询字符串上（形式为NAME = VALUE，并用&号分隔）。
一旦攻击者构造好URL，他就可以把它设为{img}标签的SRC属性。如果某个的已登录用户访问了任何包含上述标签的页面，那么浏览器就会用攻击者的参数来加载“Email this”页面，并引起发送一封包含该用户的电子邮件地址的电子邮件给攻击者。攻击者可以存储这个电子邮件地址，以供将来之用（例如用于发送垃圾邮件）或者使用该电子邮件地址来识别他自己的站点的访客的身份。这可以引起严重的隐私泄漏，例如某些颇具争议的站点（例如政治的或者非法的站点）的管理员识别他们的用户的身份。
安全研究人员用Firefox、Opera 和Safari 等对该攻击进行了验证。由于P3P的原因，它对Internet Explorer无效。后来纽约时报将页面改成只允许POST请求，所以现在能够防止原来的攻击。
二、MetaFilter 网站的跨站请求伪造漏洞
同样是在今年，安全研究人员在MetaFilter发现了一个CSRF弱点，它允许攻击者劫持用户的帐户。MetaFilter有一个“Lost Password”页面，该页面允许用户请求他的口令。在该页面中输入一个用户名，MetaFilter就会把该用户的当前口令通过电子邮件发至该用户相应的邮件地址。这意味着，攻击者只要能够改变一个用户的电子邮件地址，他就能够利用“Lost Password”页面来接受该用户的口令，继而利用该口令来控制该用户的帐户。
研究人员发现的CSRF攻击允许攻击者改变一个用户的电子邮件地址。为了利用这个攻击，攻击者需要设法让用户的浏览器发送一个请求到更新用户概况的页面。这个页面将用户的电子邮件地址作为一位参数接收，所以，攻击者可以把传递给该页面的电子邮件地址换成他自己的地址。下面提供一个嵌入在一个页面中的HTML来演示这个攻击过程：
{mg src=& EMAIL]&/}
虽然这会改变任何已登录用户的电子邮件地址，但是攻击者不会知道到底修改了哪些用户的帐户。但是，攻击者可以通过利用MetaFilter的另一项功能来达到此目的，该功能使用户能将其他用户标记为“contacts”（即联系人）。 攻击者可以通过类似于像上面介绍的CSRF来设法让用户在不知不觉中将攻击者添加到他的联系人名单中。
研究人员用Firefox对该攻击进行了验证。不过由于P3P的原因，无法用Internet Explorer进行此项测试。
三、YouTube网站的跨站请求伪造漏洞
安全研究人员发现，在YouTube上几乎所有用户可以执行的动作都具有CSRF漏洞。如果攻击者已经将视频添加到用户的“Favorites”，那么他就能将他自己添加到用户的“Friend”或者“Family”列表，以用户的身份发送任意的消息，将视频标记为不宜的，自动通过用户的联系人来共享一个视频，为用户预订一个“channel”（一组由某个人或组提供的视频），将视频添加到用户的“QuickList”（一组用户打算将来观看的视频）。例如，要把视频添加到用户的
“Favorites”，攻击者只需在任何站点上嵌入如下所示的{mg}签：
{mg src=&_id=[VIDEO ID]&playlist_id=&add_to_favorite=1&show=1&button=AddvideoasFavorite&/}
攻击者也许已经利用了该漏洞来提高视频的流行度。例如，将一个视频添加到足够多用户的“Favorites”，YouTube就会把该视频作为“Top Favorites”（一组被大量收藏的视频）来显示。除提高一个视频的流行度之外，攻击者还可以导致用户在毫不知情的情况下将一个视频标记为“不宜的”，从而导致YouTube删除该视频。
这些攻击还可能已被用于侵犯用户隐私。YouTube允许用户只让朋友或亲属观看某些视频。这些攻击会导致攻击者将其添加为一个用户的“Friend”或“Family”列表，这样他们就能够访问所有原本只限于好友和亲属表中的用户观看的私人的视频。
攻击者还可以通过用户的所有联系人名单（“Friends”、“Family”等等）来共享一个视频。“共享”就意味着发送一个视频的连接给他们，当然还可以选择附加消息。这个消息可以包含一个连接，这就是说攻击者可以强迫用户包含一个具有攻击性的网站的链接。收到该消息的用户可能单击这个连接，这使得该攻击能够进行病毒式的传播。研究人员用Firefox对此攻击进行了验证。但是对于Internet Explorer来说，由于P3P的原因，无法用它对此漏洞进行攻击。
四、保护措施概述
上面讲述了现实世界中发现的一些跨站请求伪造漏洞。下面介绍如何从服务器端和客户端来防御这种攻击。目前，已有两个工具来保护大量用户免遭CSRF攻击。第一个工具是一个服务器端工具，它能全面保护一个潜在的目标站点免受CSRF攻击。第二工具是一个客户端工具，它可以保护用户免遭某些类型的CSRF攻击。表 1详细描述这两种技术的适用条件。我们还对服务器端解决方案应具备的特性进行了描述，具备这些特性的解决方案比之前倡议的解决方案更具优势，因为他们无需服务器状态，并且不会影响一般的web浏览活动。
目标服务器的安全措施&没有使用本文推荐Firefox插件的用户&使用本文推荐Firefox插件的用户&&
没有保护措施的目标服务器
仅仅接受POST请求的目标服务器
&使用服务器端保护措施的目标服务器&
表1：用户保护情况对照表
这个表显示了在那些情况下受到或没有受到CSRF攻击保护。服务器端保护措施可以对站点的所有用户提供保护；而客户端浏览器插件可以在服务器要求使用POST请求时为用户提供保护。下面先介绍服务器端的保护措施。
五、服务器端保护措施
最近，已经出现了许多简化web开发框架，这些框架支持不同的开发语言，例如Code Igniter(PHP)，Ruby on Rails(Ruby )，django(Python)，Catalyst(Perl)和Struts(Java)。这些框架的一个主要优点是可以直接将CSRF保护措施放到框架中，这样开发人员就不必亲自实现保护措施了。在框架级别实现的CSRF保护措施常遭受更大的疏漏，但是由于粗心引起的bug或者CSRF误报更低。
个别站点和框架可以通过采取下列措施来保护他们自己免受CSRF攻击：
⒈ 只允许GET请求检索数据，但是不允许它修改服务器上的任何数据。
这个修改可以防止利用{img}标签或者其它的类型的GET请求的CSRF攻击。另外，这个建议遵循RFC 2616(HTTP/1.1)：
具体说来，按照约定，GET和HEAD方法不应该进行检索之外的动作。这些方法应该被认为是“安全的”。虽然这个保护措施无法阻止CSRF本身，因为攻击者可以使用POST请求，但是它却可以与(2)结合来全面防止CSRF漏洞。这里，我们假定对手无法修改用户的cookie。
⒉ 要求所有POST请求都包含一个伪随机值。
当用户访问站点时，该站点应该生成一个（密码上很强壮的）伪随机值，并在用户的计算机上将其设为cookie。站点应该要求每个表单都包含该伪随机值（作为表单值和cookie值）。当一个POST请求被发给站点时，只有表单值和cookie值相同时，该请求才会被认为是有效的。
当攻击者以一个用户的名义提交表单时，他只能修改该表单的值。攻击者不能读取任何发自该服务器的数据或者修改cookie值，这是同源策略的缘故。这意味着，虽然攻击者可以用表单发送任何他想要的值，但是他却不能修改或者读取存储在该cookie中的值。因为cookie值和表单值必须是相同的，所以除非攻击者能猜出该伪随机值，否则他就无法成功地提交表单。
3. 使用一个与会话无关的伪随机值。
与会话无关的伪随机值并不能防止在中所述的CSRF攻击。
这种服务器端保护形式具有下列特性：
轻量级。这个解决方案不要求服务器端的状态。站点唯一要做的是生成一个伪随机值（如果当前没有的话），并在一个POST请求到达时比较这两个值，所以这种CSRF保护措施只需很少的计算工作。
兼容并行会话。如果用户在一个站点上同时打开了两个不同的表单，CSRF保护措施不应该影响到他对任何表单的提交。考虑一下如果每次表单被装入时站点生成一个伪随机值来覆盖以前的伪随机值将会发生什么情况：用户只能成功地提交他最后打开的表单，因为所有其他的表单都含有非法的伪随机值。必须小心操作以确保CSRF保护措施不会影响选项卡式的浏览或者利用多个浏览器窗口浏览一个站点。方法是，设立一个站点级别cookie，然后在一定时间内让所有表单都使用该cookie。
对认证没有任何要求。这种解决方案不要求使用特定类型的认证。它能工作在通过cookie会话、HTTP认证、SSL认证或者IP地址对用户进行认证的站点上。
之前也有人提议在表单中使用伪随机值，不过许多提议的实现没有提供上述特性。例如，有的需要服务器状态，而有的会破坏项卡式的浏览。但是，之前提议的解决方案没有强调跟正常浏览行为相兼容的重要性。
任何拦截POST请求并“包装”生成{form }标签的命令的框架都能够把以上所述CSRF保护措施透明地组合进该框架。例如，如果一个框架要求开发人员调用函数form_open (...)来生成一个{form ...}标签的话，那么就可以对这个框架加以修改，让它在每次创建一个表单的时候都自动地生成一个伪随机值：
{form ...}{input type=&hidden& name=&csrf value&value=&8dcb5ed4bbf333afdd154ca&}
此外，该框架还能处理跟cookie值有关的设置，并用该cookie值跟提交过来的值相比较。一个框架添加了这种CSRF保护措施，那么就能保护该框架的所有用户免受CSRF攻击。 因为这种CSRF保护措施是轻量级的，并且对于框架或者开发人员提供的认证方法没有任何要求，所以强烈建议那些拦截POST请求并提供了生成{form}标签的函数的框架都实现这种CSRF保护措施并将其设为默认保护措施。该框架还为开发人员提供了是否禁用该项保护措施的能力，例如他们已经单独地实现了CSRF保护措施或者他们不想要cookie。
框架Code Igniter提供了这样的一个插件，该插件不要求开发人员对现有表单做任何修改，并且会对POST请求(并且对POST请求的伪随机值进行验证）和创建{form}标签的函数调用进行拦截。该插件还提供了一个函数，该函数允许CSRF标志被添加到AJAX请求，尽管这要求开发人员的干预（Code Igniter没有提供执行AJAX请求的标准方式）。该插件的下载地址：。
六、客户端保护措施
由于使攻击者成功地执行CSRF攻击的请求是由浏览器发出的，所以可以创建客户端工具来保护用户不受此种攻击。现有的工具RequestRodeo通过在客户和服务器之间充当代理来防止CSRF攻击。如果RequestRodeo发现了一个它认为是非法的请求，它会从该请求剥离验证信息。虽然这种方式在很多情况下都能有效，但是它具有一些局限性。具体地说，当客户端使用了SSL认证或者使用JavaScript生成部分页面（因为RequestRodeo分析的是在浏览器显示之前的流经代理的那些数据）时，它就不起作用了。&&&& 人们已经开发了一个浏览器插件，不仅可以使用户可以免受某些类型的CSRF攻击，并且还能克服以上所述的局限性，这个工具是作为Firefox浏览器的扩展实现的，其地址是。为了有效地防范CSRF攻击，用户需要下载安装这个扩展。该扩展会拦截所有的HTTP请求，并判断是否允许该HTTP请求。这个判断要用到下列规则。首先，POST请求之外的任何要求都是允许的。第二，如果发出请求的站点和目标站点符合同源策略的要求，那么该请求被允许。第三，如果发出请求的站点被允许使用Adobe的跨域政策来建立一个请求的话，那么该请求也会被允许。如果我们的扩展拒绝一个请求，该扩展会通过一个常见的界面来提示用户（即Firefox所使用的popup
blocker）该请求已经被阻止，并且让用户选择是否将站点添加到一个白名单中。
该扩展仅仅拦截POST请求。这意味着，它无法保护用户免受使用GET请求的CSRF攻击 阻止这种类型的攻击的唯一方法是不允许任何跨域GET请求，或只允许用户一次只能登录到一个站点，但是这两个限制可能是用户无法忍受的。
CSRF攻击在漏洞识别、利用和修补上相当简单，人们可以在几秒内分析站点，发动攻击也只需几分钟的时间。对于这些攻击的流行，最合理的解释是Web开发人员对于该问题的无知，以及误认为所实施的针对更为人们所熟悉的跨站脚本攻击的防范措施还能防止CSRF攻击。
我们希望这里介绍的攻击足以显示CSRF攻击的危险性，并引起Web开发人员给予这些攻击足够的重视。建议框架的创建者为他们的框架添加CSRF保护措施，从而保护建立在该框架之上的站点。在框架级别添加CSRF保护措施使得开发人员免于复制代码，甚至不用对CSRF攻击有深入的了解，当然最好对这些攻击进行了解。当然，在所有的网站都对CSRF攻击采取防范措施以前，用户可以使用这里介绍的Firefox浏览器插件来设法保护他们自己，估计将来其它浏览器也会出现类似的插件。
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：277287次
积分：4575
积分：4575
排名：第5110名
原创：143篇
转载：274篇
评论：18条
(1)(1)(2)(2)(3)(1)(3)(2)(1)(1)(4)(2)(1)(33)(227)(102)(31)