主页 > imtoken钱包下 > 如何渗透测试以太坊 dApp
如何渗透测试以太坊 dApp
英文原文：
一、简介
所谓以太坊（Ethereum）去中心化应用（decentralized application，dApp）是指基于共识协议（consensus protocol）交互的应用。 在本文中，我们选择针对 dApp 最常见的应用场景类型之一：与一个或多个智能合约交互的常规 Web 应用程序。
当我们通过网络访问 dApp 时（例如使用 MetaMask 等扩展程序），我们可以使用我们的私钥与网站交互并通过网络界面签署交易。
一个典型的 dApp 看起来像这样，我使用网络界面和一个包含以太坊钱包的 Chrome 扩展来购买 Cryptokitty：
当浏览器与常规 Web 应用程序交互时，Web 应用程序可能会再次与其他内部服务器、数据库或云进行交互。 最后，在我们看来，整个交互过程非常简单：
对于 dApp，大多数交互都是相似的，但这里涉及第三个要素：所有人都可以公开访问的智能合约。
与 Web 应用程序的某些交互涉及读取和写入以太坊区块链上的一个或多个智能合约。
二、多管齐下
dApp 的目的是让最终用户更容易与智能合约进行交互。 但是现在并没有明确的规定要求我们通过dApp的web界面与dApp的智能合约进行交互。 由于所有人都可以公开访问智能合约，因此我们可以直接与智能合约进行交互，而不受可能限制我们发起的特定交易的 Web 服务器处理逻辑的限制。
到目前为止，我们可以通过两种方式进行渗透测试：
标准的Web应用程序渗透测试涉及身份认证、访问控制和会话管理等技术。 智能合约审计。
换句话说，我们可以检查Web应用程序和智能合约的处理逻辑，看看两者是否存在逻辑错误。
由于以太坊中的修饰符（modifier）特性，我们其实可以挖掘出另一种方式来进行渗透测试。
3.修饰符
在以太坊中，我们可以编写仅在从特定以太坊地址调用时才能执行的函数。 onlyOwner 是修饰符的典型例子。 如果我们正确实现 onlyOwner，只有合约的所有者才能运行某些功能。
contract mortal {
/* Define variable owner of the type address */
address owner;
modifier onlyOwner {
require(msg.sender == owner);
_;
}
function writeData(bytes32 data) public onlyOwner returns (bool success) {
// will only run if owner sent transaction
}
...
}虽然我们可以直接与智能合约交互，但如果像 onlyOwner 这样的修饰符被正确实现，我们将无法执行某些功能。 但是在处理dApps的时候，web服务器基本上都会保存特权地址对应的私钥数据，而web应用总是有特定的逻辑，可以在web端接受用户输入，然后使用其中一个私钥调用智能合约。 特权功能。
由于dApps确实可以访问这些特权以太坊地址，渗透测试的第三个分支就变成了：“我们如何让dApps帮助我们在智能合约中编写这些特权功能？”
考虑到这一点，我们的攻击面现在已经扩展到：
标准 Web 应用程序评估（身份验证、访问控制、会话管理）。 这个过程可能不涉及智能合约，而只是水平或垂直提权、数据库注入、XSS等智能合约审计。 权限问题、溢出或下溢、竞争条件等。尝试通过 Web 界面伪造对智能合约的写访问。 我们能否找到一种方法让 Web 应用程序以意想不到的方式与智能合约进行交互？
我之前写过一段可以用来描述dApp的攻击面：
想象一个普通的 Web 应用程序，可能存在各种安全漏洞。 现在，想象一个具有以下特征的应用程序：
1. 从头开始构建自己的数据库软件；
2. 对外开放这些数据库；
3.有时这些数据库中会有真钱。
这是以太坊 dApp 开发者需要面对的安全挑战。
——Brandon Arvanaghi (@arvanaghi) 2018 年 5 月 28 日
四、使用Burp拦截请求
当我们注册一个 Cryptokitties 账户时，Web 应用程序的处理逻辑会从用户的 MetaMask 扩展中提取用户的公共以太坊地址，然后网站会要求我们输入电子邮件地址和账户昵称。
下一步很重要：由于 dApps 面向以太坊账户，因此它们基于公钥身份验证而不是密码身份验证。
因此，Cryptokitties 会要求我们签署某个消息（“Cryptokitties”），确保我们拥有与该地址对应的私钥。
如果我们拦截这个请求，我们可以看到如下数据：
理论上，Cryptokitties 会验证 sign 参数中的数据（即签名的“Cryptokitties”消息）是否与 address 参数中的数据（即我们的以太坊地址）相对应。
这个验证过程位于Web应用程序的处理逻辑中。 我遇到过一些没有正确处理签名验证过程的 dApp，因此我可以将请求中的以太坊地址替换为与签名不匹配的以太坊地址，如下所示：
Cryptokitties 可以正确处理签名验证逻辑，但如果 dApp 无法做到这一点，我可以通过虚假的以太坊地址和应用程序上的虚假账户身份发起拒绝服务攻击。
5.登录流程
Bloom 是我们可以用来创建去中心化身份的最先进的 dApp 之一。 其背后的原理是将ID绑定到用户的以太坊地址，使其无法像社保号（SSN）一样被盗用或伪造。 由于 Bloom 是迄今为止最成熟的 dApp 之一，我强烈推荐这个应用程序给大家。 如果您还没有创建自己的 BloomID，可以考虑尝试一下。
Bloom 在身份验证处理方面非常严格。 注册完账户后，如果我们在后续过程中需要从以太坊地址登录，就需要对消息进行签名，消息中包含用户的意图（我正在登录）、邮箱地址、当前时间。
为什么布卢姆考虑签署这些领域？ 有几个原因：
1. 操作意图：如果用户不理解所签名的具体内容，签名并发送签名数据有时是一种危险的操作。 Bloom在消息文本中明确给出了签名操作的具体意图。
2. 邮箱地址：Bloom会从签名中恢复邮箱地址，并检查是否为签名该消息的以太坊地址的注册邮箱。 如果两者匹配，则登录是有效的登录操作（在当前登录会话中）。
3.时间戳：用于防止重放攻击。 如果签名中不包含当前时间信息，则获得签名数据的攻击者可以随时重放数据以验证目标用户的身份。 签名成功后，如果 Web 应用程序在几分钟的时间窗口内收到签名数据，Bloom 将认为签名有效。
如果任何字段被篡改以太坊的前景，就会出现一条错误消息以太坊的前景，表明 Bloom 很好地处理了身份验证机制。
6. 智能合约中的漏洞
之前我们讨论了智能合约的某些攻击方式，直接分析了智能合约是否存在安全漏洞。 接下来，让我们看一下现实世界中已经挖掘出的一些漏洞。
批量溢出
这个漏洞被称为 batchOverflow 漏洞。 从名字我们很容易猜到这是一个溢出漏洞。
我发起了一个小测试，看看有没有人有这个溢出漏洞的解决方案。 在看答案之前，你可以试试看能不能找到具体的漏洞利用方法。
