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

　　Web安全测试之跨站请求伪造（CSRF）篇～教育资源库 　　跨站请求伪造（即CSRF）被L标签等。下面分别加以解释。 　　首先，我们来了解一些L/JavaScript中的URL以及表单来了解应用程序有关的URL、参数和容许值。 　　接下来，我们讨论一下应用程序赖以管理会话的信息对浏览器的透明性问题。我们知道，为了提高L标签，如果页面内出现这些标签，会立刻引起浏览器对http[s]资源的访问，例如图像标签img便是其中之一。 　　为简单起见，我们这里讨论GET方式的URL（不过这里讨论的内容同样适用于POST请求）。如果受害者已经通过身份验证，那么当他提交其它请求时，该cookie也会自动地随之发送（如图，这里用户正在访问.example.上的一个应用程序 ）。 　　图1　浏览器发送请求的同时还自动发送cookie 　　那么，什么情况下会引起发送这个GET请求呢？这可就有多种可能了，首先当用户正常使用该L格式的电子邮件消息，等等）的内容中，并且指向应用程序的资源。如果用户单击了该链接，由于他已经通过了站点上L内容（注意，内容已作精简）的页面： [html][body] ... (img src=https://.pany.example/action l] 用时将[]换成lt;gt;　　当浏览器显示该页面时，它也将设法显示这个指定宽度为0的图像，即该图像是不可见的这会导致自动向站点中的L标签问题是总结如下： 123下一页 友情提醒：，特别！ 　　页面中有许多标签会导致自动发出HTTP请求（img标签便是其中之一）； 　　浏览器无法断定img标签所引用的资源到底是不是图像以及是否是有害的； 　　当加载图像时，根本就不考虑所涉及的图像所在的位置，即表单和图像不必位于同一个主机上，甚至可以不再同一个域内。虽然这是一个非常便利的特性，但是却给应用程序的隔离制造的障碍。正是由于与L内容可以引用应用程序中的各种组件，以及浏览器可以自动为该应用程序构造一个有效的请求这两个事实才导致了这种攻击的出现。这意味着，正确的URL必须包含用户会话有关的信息，而攻击者却无法得知这些信息，因此不可能识别这样的URL。 　　对于集成了邮件/浏览器功能的工作平台，跨站请求伪造问题可能更为严重，因为，仅仅显示一封包含该图像的电子邮件就会导致请求及有关浏览器cookie一起向L页面，让它包含引用url u（规定全部相关参数；使用GET方式的时候很简单，如果使用的是POST请求，则需要诉诸于一些JavaScript代码）的HTTP请求； 　　确保合法的用户已经登录该应用程序； 　　引诱他点击一个链接，而该链接指向受测试的URL（如果你无法冒充用户的话，则需要借助于社会工程）； 　 上一页123下一页 友情提醒：，特别！观察结果，如检测格式邮件/浏览器集成是式软件以及集成了新闻阅读程序/浏览器的软件都会带来额外的风险，因为只要查看邮件或者新闻就有可能被迫执行一次攻击，所以使用这类软件时格外小心。 　　开发人员 　　开发人员应当向URL添加跟会话有关信息。该攻击类型之所以得逞，是因为会话是由cookie唯一标识的，并且该cookie是由浏览器自动发送的。 　　如果我们在URL级别为会话生成其它相关信息，那么就会给攻击者为发动攻击而了解URL的结构造成更多的障碍。 　　至于其它的对策，虽然也无法解决该问题，但是能够使得利用该漏洞更加困难，例如使用POST而不是GET。虽然POST请求可以通过JavaScript进行模仿，但是它提高了发动这种攻击的难度。使用中间确认页也能带来相同的效果，比如您确信要这样做吗？之类的页面。虽然攻击者可以绕过这些措施，但是这些措施提供了实施攻击的难度。因此，不能完全依赖这些手段来保护您的应用程序。自动登出机制也能减轻这种攻击带来的危害，但这最终依赖于具体情况（一个整天跟有这种漏洞的网络银行程序打交道的用户所面临的风险要远远大于临时使用同一网络银行的用户所面临的风险）。 　　七、小结 　　跨站请求伪造，即CSRF，是一种非常危险的Web安全威胁，它被Web安全界称为沉睡的巨人，其威胁程度由此美誉便可见一斑。本文不仅对跨站请求伪造本身进行了简单介绍，还详细说明造成这种漏洞的原因所在，以及针对该漏洞的黑盒测试与灰盒子测试具体方法和示例，最后提提了一些防范该攻击的建议，希望本文对读者的安全测试能够有所启发。 上一页123友情提醒：，特别！