游戏化思维自学英语,像玩游戏一样过关斩将,让你对学习上瘾,在无形之中用地道的英语跟老外谈笑风生。详情加微信了解:cool-smiler

跨站点请求的七种情况

今日限免 JackLeon 5个月前 (12-12) 426次浏览 0个评论 扫描二维码

痛点描述:网页可以向第三方站点发出请求,这是 CSRF 攻击的主要原因。本文获得了 USENIX Security 2018 的“杰出论文”奖,以及 2018 年的互联网防御奖。这篇文章总结了可能发出第三方请求的七种情况。

跨站点请求的七种情况
本文获得了 USENIX Security 2018 的“杰出论文”奖,以及 2018 年的互联网防御奖。它是对浏览器(以及通过扩展/附加组件)构建的防御机制的评估,旨在防止用户跟踪和跨站点攻击。通过对 7 个浏览器和 46 个浏览器扩展的测试,作者发现几乎每种浏览器和扩展组合都有一种绕过预期安全策略的方法。

尽管它们具有显着的优点,但在大多数现代浏览器中实现 cookie 的方式也会引入各种攻击和其他不需要的行为。更确切地说,因为 cookie 附加到每个请求,包括第三方请求,所以网站更难以验证请求的真实性。因此,攻击者可以从不知情的受害者的浏览器中触发带有恶意负载的请求……除了跨站点攻击之外,在第三方请求中包含 cookie 还允许在他们访问的各个网站上跟踪用户。
当您访问站点A 时,它可以将 cookie 设置为包含在将来对该站点的所有请求中。本文关注第三方请求。这是您访问的网站,但在现场的一些资源触发到现场进行请求一个(例如,img标签与src属性引用网站)。为站点A设置的 Cookie 使用该请求(取决于 cookie 策略)。利用这种机制的一个很好的例子是众所周知的CSRF 攻击

image | left
还存在其他跨站点攻击,例如跨站点脚本脚本(XSS)和跨站点计时攻击。
同一站点的 cookie机制旨在防止跨站攻击。同站点 cookie 具有SameSite由设置 cookie 的网站设置的属性。当设置为laxcookie 时,只能在顶级(地址栏中的 URL 更改)请求strict包含在第三方站点中,并且当设置为 cookie 时,可能永远不会包含在跨站点请求中。浏览器对主流浏览器中相同站点 cookie 的支持现在相当不错。

生成跨站点请求的方法

为了详尽地测试所有可能的跨站点请求机制,第一项工作是将它们全部列出。作者发现了七种不同的机制类别,包括它们之间的数百个单独机制。

  1. 也许最明显的类HTML 标记与引用外部资源的属性(例如imgiframescript)。HTML 标记有 196 种不同的方式可以触发外部请求,其中许多方法都记录在HTTPLeaks 中。所有基于 HTML 的请求都会生成 GET 请求。
  2. 一旦浏览器收到标题或某些事件,某些响应标头Link标头和Content-Security-Policy)可能会触发其他请求。该report-uri指令指示应报告违反安全策略的 URI(即将发布的 Reporting API 将启用相同的 URI)。任何浏览器都不支持该指令和 API,在本研究中将被忽略。
  3. 顶级重定向通常不被视为跨站点请求,但有些场景可能会被滥用。例如,跟踪器可以监听元素blur上的事件,该事件window指示用户切换的选项卡 – 此时它可以在后台触发重定向。
  4. JavaScript可以通过 XHR 和 Fetch API 发起请求。Beacon API 可以发出异步 POST 请求,WebSocket API 也可以用于打开通信会话。EventSource API 可以打开与 Web 服务器的单向持久连接。
  5. 列表中最有趣的机制之一是PDF JavaScript。PDF 可以通过嵌入在 PDF 文件中的 JavaScript 启用动态功能。可以使用此机制生成请求(例如,在填写表单时触发 POST 请求)。支持取决于浏览器。Chrome 和 Opera 使用的 PDFium 查看器支持发送请求,而 Firefox 则不支持。
  6. (已弃用但仍受支持)AppCache API可以指定在用户访问给定页面时要加载和缓存的其他资源。
  7. ServiceWorkers可以获取资源并使用大多数浏览器 API 来发起其他请求(不包括 XHR)。

所有这些请求启动机制都可以通过各种不同的方式触发(例如,通过 iframe 中的包含或 JavaScript 中的 importScripts)。最终的组成机制没有与测试结果有所不同,因此主要文章中省略了细节,但如果您感兴趣,可以在附录 A 中找到它们。

测试所有的东西

作者整理了一个测试框架,该框架可以跨不同的浏览器和扩展实现所有可能的跨站点请求机制。
image | left

我们评估的主要目标是分析不一致和绕过的影响最大的浏览器。一方面,我们包括最受欢迎和广泛使用的浏览器:Chrome,Opera,Firefox,Safari 和 Edge。另一方面,我们还整合了专门针对隐私感知用户的浏览器……
浏览器使用其保护机制的默认设置进行测试。此外,针对四个最流行的浏览器测试了 46 种不同的扩展,基于各个商店中报告的扩展流行度来选择。

结果

7 个评估浏览器的结果总结在下表中(填充圆圈表示 cookie 随请求一起发送)。
image | left

  • 在默认配置下,所有主浏览器都会发送 cookie 以及第三方请求。Safari 是个例外,只有重定向才有。
  • 当指示阻止所有第三方 cookie 时,浏览器仍然发送带有重定向的 cookie(通常不被视为跨站点请求)。作者还发现,使用 PDFium 阅读器呈现 PDF 的浏览器也发送了包含从 PDF 中的 JavaScript 启动的第三方请求的 cookie。
    > 因为 PDF 可以包含在 iframe 中,因此对最终用户不可见,并且因为它可以用于发送经过身份验证的 POST 请求,所以此旁路技术可用于跟踪用户或执行跨站点攻击,而不会引起注意受害者。
    评估了 31 个广告拦截扩展程序,并为所有这些扩展程序找到了旁路:

image | left
还评估了 15 个跟踪保护扩展,并为所有这些扩展找到了绕过!
image | left
扩展开发人员常见的错误是注册过滤 http 和 https 协议请求,但忘记了 ws://和 wss://协议。

总之,我们发现,对于每个内置的浏览器保护以及每个反跟踪和广告拦截浏览器扩展,至少存在一种可以绕过强制策略的技术……基于这些结果,我们认为我们提出的建议框架是一种非常需要的工具,用于检测旁路并评估暴露泄漏的解决方案。
测试同一站点 cookie 机制,Chrome,Opera 和 Edge 发现了不正确的行为。

未来的工作包括评估移动浏览器,并将测试覆盖范围扩展到其他策略实施,例如 Local Storage API 和 Content Security Policy。


温馨提示:若在升级会员或付费后阅读过程中遇到问题,请加客服微信号(cool-smiler)沟通解决,祝您生活愉快。
转载请注明原文链接:跨站点请求的七种情况
喜欢 (0)
[1186664388@qq.com]
分享 (0)
关于作者:
创享视界(creativeview.cn)是一个带动全民颠覆八小时工作制,通过投稿把自己的创意智慧变现的方式创造被动收入,从而实现财务自由的平台。我们相信,创新思维不仅有助于打造更出色的产品,还可以让世界变得更美好,让人人受益。
发表我的评论
取消评论
表情 贴图 加粗 删除线 居中 斜体 签到

Hi,您需要填写昵称和邮箱!

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址
%d 博主赞过: