Web安全测试之跨站请求伪造（CSRF）篇

　　因此，如果我们键入值“*”，并按下删除按钮，会提交下列GET请求：

　　https://www.company.example/fwmgt/delete?rule=*

　　其结果当然是删除所有防火墙规则了，呵呵，后果很严重呀!如下图所示：

图3 删除所有防火墙规则

　　实际上，这并非可能的情形。用户也可以手动提交URLhttps://[target ]/fwmgt /delete ?Rule =*来达到相同的效果。或者通过单击一个直接指向以上URL的链接或通过重定向到达以上URL的链接。或者同样也可访问一个嵌入了指向相同的URL的img标签的HTML页面。在这些情况下，如果用户当前已经登录到防火墙管理程序，那么该请求将得逞并会修改防火墙的配置。

　　此外，我们还可以设想攻击是针对敏感的应用程序、进行自动的拍卖投标、转帐、订货、改变关键软件组件的配置等等。

　　更有趣的是，这些漏洞都可以在防火墙之后进行利用，即只要被攻击的链接是受害者所能访问的即可，而不必非得攻击者能够直接访问才行。

　　尤其是，它可以是任何内部网Web服务器，例如，之前提到的防火墙管理工作站，它大不可能暴露于国际互联网。对于那些既可以用作攻击矢量，有是攻击目标的应用程序(例如web邮件应用程序)，情况更糟了：如果这样的应用程序是易受攻击的，那么用户阅读包含CSRF攻击的信件时很明显已经登录到程序了，它会以web邮件应用程序为目标，并让邮件应用程序执行删除信件、发送消息等动作，而这些动作看起来将像是用户本身所做的。

　　四、黑盒子测试

　　为了进行黑盒测试，需要知道受限制的(认证的)区域的URL。如果您具有有效证书，那么可以扮演攻击者和受害者这两种角色了。在这种情况下，仅仅通过浏览应用程序您能获悉受测试的有关URLs。否则，如果没有有效的证书可用的话，必须组织一个实际的攻击，以引诱一个合法的已登录的用户来点击某个适当的链接，这可以通过社会工程来进行。

　　不管怎样，测试案例可以如下构造：

　　把u改成受测的URL，例如u=http://www.example.com/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安全界称为“沉睡的巨人”，其威胁程度由此“美誉”便可见一斑。本文不仅对跨站请求伪造本身进行了简单介绍，还详细说明造成这种漏洞的原因所在，以及针对该漏洞的黑盒测试与灰盒子测试具体方法和示例，后提提了一些防范该攻击的建议，希望本文对读者的安全测试能够有所启发。