作者：Immunefi 编译：Cointime.com 237
介绍
在本文中，我们将探讨 Web2 漏洞对 dApp 的影响，以及来自 Web2 世界的黑客如何发现并负责任地报告这些错误，从而在 Immunefi 上获得巨额错误赏金奖励。
我们之前讨论过 Web3 中 Web2 漏洞的具体示例。其中一个漏洞是NFT 市场中 XSS的盛行。我们还在另一篇文章中研究了子域接管的影响。
在这里，我们将研究四种类型的漏洞，以便更广泛地了解如何利用 Web2 漏洞来攻击 Web3 领域的 dApp。
这些漏洞包括跨站点请求伪造 (CSRF)、不安全的直接对象引用 (IDOR)、开放重定向和 SQL 注入。
CSRF
当 HTTP 请求不包含随机值（例如随机数或 CSRF 令牌）时，就会发生跨站点请求伪造 (CSRF) 攻击。由于缺少令牌，攻击者只需单击一下即可代表经过身份验证的用户执行操作，这可能会导致一些危险结果。
通常，CSRF 令牌包含在 HTTP 标头或帖子正文中，如以下请求所示：
示例 1：HTTP 帖子正文中的 CSRF 令牌
示例 2：HTTP 标头中的 CSRF 令牌
POST /profile HTTP 1.1
Host: secure-domain.tld
Content-type: application/x-www-form-urlencoded
X-token:eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZCI6MTMzNywidGltZXN0YW1wIjoxNjI0NTU0MjAwfQ.N1Vg7uyYFyijv8p7KUZTDgQfZJgvlY04TjFfgO9xz2U
现在，让我们看看不包含令牌或随机数的 HTTP 请求：
如果缺少 CSRF 令牌，攻击者可能会通过向受害者发送下面提到的 PoC 来更改受害者的电子邮件地址。当受害者访问攻击者的托管页面时，该页面会向 vulnerable-domain.tld/profile 提交 POST 请求，以将受害者的电子邮件地址更改为攻击者的电子邮件地址。更新电子邮件后，攻击者可以重置密码并接管整个帐户。
<html>
<body>
<script>
history.pushState(‘’, ‘’, ‘/’);
</script>
<form action=”https://vulnerable-domain.tld/profile" method=”POST”>
<input type=”hidden” name=”email” value=”[email protected]” /><input type=”submit” value=”Submit request” />
</form>
<script>
document.forms[0].submit();
</script>
</body>
</html>
让我们看一下具有不同内容类型的另一个示例。
请求 1：在 secure-domain.tld 上提交编辑电子邮件表单
POST /profile HTTP 1.1
Host: secure-domain.tld
Content-type: application/json
X-CSRF-token:eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZCI6MTMzNywidGltZXN0YW1wIjoxNjI0NTU0MjAwfQ.N1Vg7uyYFyijv8p7KUZTDgQfZJgvlY04TjFfgO9xz2U
{“email”: “[email protected]”}
请求 2：提交针对vulnerable-domain.tld 的编辑电子邮件表单
尽管第二个 JSON 请求可能缺少反 CSRF 令牌，但它不一定容易受到 CSRF 攻击，因为 HTML 表单不支持内容application/json类型。但是，如果应用程序未正确验证内容类型标头，则仍然可以利用 JSON 请求中的 CSRF；text/plain我们可以在下面提供的 PoC 中提交 HTML 表单时强制执行内容类型。
<html>
<body>
<script>
history.pushState(‘’, ‘’, ‘/’);
</script>
<form action=”https://vulnerable-domain.tld/profile" method=”POST” enctype=”text/plain”>
<input type=”hidden” name=”{‘email’:’[email protected]’,fakepram’’” value=”’}” />
<input type=”submit” value=”Submit request” />
</form>
<script>
document.forms[0].submit();
</script>
</body>
</html>
重要的是要记住，对于 Web3，CSRF 攻击与其他 Web2 漏洞相比影响最小，因为去中心化应用程序 (dApp) 使用客户端加密钱包来验证和批准敏感请求。
因此，对于攻击者来说，要在 dApp 中利用 CSRF，他们需要依赖不太可能的用户交互，例如受害者从攻击者控制的网站重定向后手动批准加密钱包上的修改请求。
IDOR
不安全直接对象引用 (IDOR) 是应用程序根据用户输入直接引用对象时发生的访问控制漏洞。这可能允许攻击者访问他们不应访问的对象，例如敏感数据或其他用户的帐户。
让我们看一下例子：
https://vulnerable-domain.tld/api/v1/users/1337
Userid 上述端点显示数据库中与 1337 关联的用户信息。如果后端没有适当的权限检查，那么我们可以通过更改 useridAPI 端点来简单地检索其他用户的数据。网址将如下所示：
https://vulnerable-domain.tld/api/v1/users/1338
既然我们现在对 IDOR 的工作原理有了基本的了解，那么让我们看一下 IDOR 的各种类型以及利用 IDOR 时遇到的复杂情况。
1、IDOR 的类型
当攻击者能够影响大范围的用户时，IDOR 被分类为水平的，而当用户可以访问或修改其用户帐户内未经授权的数据时，则发生垂直 IDOR。
假设应用程序具有具有各种权限的用户帐户功能，例如管理员和只读。只读用户无权访问用户管理功能，该功能允许管理员在组织帐户中添加、查看和编辑用户。
考虑以下用于查看组织的用户列表的端点：
/api/v1/organization/1337/users
如果应用程序在浏览上述端点时向只读用户显示用户列表，则这是垂直 IDOR 的示例。但是，如果在端点中更改组织 ID（在本例中为 1337 到 1338）会显示与 1338 组织 ID 关联的组织的用户列表，则它将被分类为水平 IDOR。
有时，利用 IDOR 具有挑战性，因为它可能需要额外的侦查技术来枚举 ID，因为应用程序并不总是使用顺序 ID，而是使用随机值（例如 UUID），这使得攻击者更难识别和枚举 ID。如果应用程序允许用户像在 NFT 平台上一样查看其他用户的个人资料，则可以在用户的页面源代码或个人资料图像 URL 中查找 UUID。它的结构可能如下：
https://vulnerable-domain.tld/images/<UID>.png 或https://vulnerable-domain.tld/images/ <UID>/image.png
在报告 Immunefi 上的 IDOR 漏洞时，清楚地证明所披露的信息或您能够篡改的数据的影响至关重要。Immunefi 严重性分类系统 v2.3具有三个与 IDOR 相关的影响。修改敏感信息（例如将您自己添加为子帐户的管理员）或披露 PII（例如电子邮件地址或家庭地址）均属于高级别。另一个中等影响是修改非敏感信息，例如名称和首选项设置。
我们强烈建议您在选择严重性之前阅读错误赏金计划政策，因为如果需要低权限用户访问，IDOR 可能会降级为中或低严重性。
开放重定向
当应用程序使用用户输入的 URL 将用户重定向到该 URL 时，就会发生开放重定向。
让我们看看易受攻击的 HTTP 端点：
https://vulnerable-domain.tld/login?redirect=https://attacker.tld
登录请求完成后，上述 URL 会将用户重定向到 Attacker.tld。
开放重定向的主要影响是网络钓鱼，因为恶意行为者可以将用户重定向到具有相似设计和域名的网站，以窃取敏感信息或诱骗他们执行恶意交易。此外，如果 Web 应用程序使用 302/301 重定向以外的技术，则可以通过将重定向 URL 设置为 来将开放重定向漏洞提升为 XSS Javascript:alert(document.domain)。
在 Immunefi 上提供 PoC 时，重要的是不仅仅是通过弹出输出来演示 DOM 访问document.domain。为了改进您的 PoC，我们建议您阅读我们之前关于NFT 市场中的 XSS 的博客文章，其中我们分享了各种 PoC，例如启动恶意交易以将 XSS 报告的严重性提高到严重程度。
SQL 注入
SQL 注入 (SQLI) 允许用户在后端操作动态查询，以强制应用程序显示数据库中本来不应该公开显示或访问的数据。
让我们看看易受攻击的 HTTP 端点：
https://vulnerable-domain.tld/api/proposal/Qmd10
该请求的后端查询如下所示：
SELECT * FROM proposal WHERE proposal_id = ‘Qmd10’
在黑盒测试期间，后端查询无法访问，这限制了我们制作成功有效负载的能力。然而，通过注入无效字符（例如单引号或双引号），我们可能会在易受攻击的应用程序中导致 SQL 错误，从而泄露有价值的信息，例如 SQL 查询以及正在使用的数据库。
此外，大多数应用程序严重依赖 Web 应用程序防火墙 (WAF) 来防止恶意查询发送到后端，因此不要复制和粘贴公共 SQLI 负载，而应始终检查应用程序如何处理用户输入。例如，在上面的示例中，您可以注入‘ OR 1=1–.
https://vulnerable-domain.tld/api/proposal/Qmd10'+OR+1=1–
结果查询如下：
SELECT * FROM proposal WHERE proposal_id = ‘Qmd10’ OR 1=1 — -’
由于 1=1 始终为 true，因此应用程序将返回数据库中存在的所有建议，从而确认应用程序容易受到 SQLI 的攻击。
Blind SQLI
然而，SQLI 并不总是那么简单，因为您可能会遇到盲目 SQLI 的情况，它不会显示 SQL 查询的结果或任何数据库错误。我们在利用 SQL 盲注时依赖应用程序的响应。例如，通过注入 sleep 函数，我们可以确定应用程序是否存在漏洞。
https://vulnerable-domain.tld/api/proposal/Qmd10'+AND+SLEEP(5)--
SELECT * FROM proposal WHERE PROPOSITION_ID = ‘Qmd10’ AND SLEEP(5) — ’
修改后的查询将导致响应延迟 5 秒。
然而，Web2 和 Web3 之间的最大区别在于，一般来说，dApp 不使用传统的 SQL 数据库，因为所有数据都直接存储在区块链上。然而，在 Web3 应用程序中发现 SQLI 并不罕见。事实上，Immunefi 上已经有几份关于 SQLI 漏洞的报告，这些漏洞导致了巨额赏金支出。一些平台仍然使用 SQL 数据库来存储敏感数据，例如电子邮件地址。
最近，一名白帽黑客因通过提案门户上的参数发现 SQL 注入而获得了巨额赏金。orderBy更改to的值后1，应用程序会根据提案 ID 按提案数据进行排序，这表明用户输入直接影响ORDER BY后端查询中的语句。此外，我们发现提供不存在的列索引号会导致错误。
由于它是基于错误的 SQLI，因此白帽黑客依赖应用程序的响应来获取更敏感的信息。例如，注入(SELECT(getpgusername()))导致应用程序正常响应，而(SELECT(@@version))触发错误，确认使用了 PostgreSQL。
然而，提取数据库版本不足以证明漏洞的严重性。因此，使用 SUBSTR 函数来确定表名和列名。
结论
Web2 漏洞和 Web3 dApp 之间的联系仍然是一个尚未被充分探索的领域，但希望我们已经对 CSRF、IDOR、开放重定向和 SQL 注入等漏洞类型进行了足够的简要介绍，以便您入门。
只要记住：
1、CSRF 对 dApp 的影响很小，因为它需要用户手动批准与敏感操作相关的请求。
2、IDOR 允许未经授权访问或修改敏感信息。由于应用程序使用非顺序或随机标识符，利用 IDOR 可能具有挑战性。
3、开放重定向可能会导致 XSS 或网络钓鱼攻击。
4、SQL 注入允许攻击者从数据库中检索未经授权的数据。一般来说，dApp 将数据存储在区块链上；但是，在使用传统 SQL 数据库进行某些数据存储的 Web3 应用程序中仍然可以发现 SQLI。
所有评论