区块链浏览器够安全吗？了解 DoS 攻击影响与应对之策

超过 50% 的区块链浏览器面临着被 DoS 攻击的危险，可以采取措施增加攻击成本并降低区块链浏览器应用中存在漏洞的概率。

原文标题：《区块链浏览器可以逃离 DoS 的九阴白骨爪吗？》
撰文：CertiK

说到浏览器，大家脑海里蹦出来的一定是「百度一下，你就知道」、「上网从搜狗开始」......

这些家喻户晓甚至大爷都说的上来的浏览器，是互联网的代言人，更是互联网的入口。

但是如果说有谁和互联网是勾肩搭背的关系，那就是现今如日中天的区块链技术了。

互联网改变生活，区块链技术改变互联网。那么毫无疑问，作为互联网的入口，浏览器必然也与区块链技术脱不开关系。由此诞生的区块链浏览器，作为大家耳熟能详的落地产品，更是为区块链用户带来了相当程度的便利。

区块链浏览器安全性如何

区块链浏览器是区块链的搜索引擎，用户可使用此工具搜索区块链上的特定信息。

举个例子，Etherscan 是以太坊的区块链浏览器，通过 Etherscan，用户可以轻松获取以以太坊上的区块、地址、交易和其他活动的信息。也就是说，区块链浏览器，更像是一个区块链官方查询网站。

那么在如今大部分区块链应用都面临安全威胁的场景下，区块链浏览器的安全性又如何呢？

区块链浏览器应用程序的可被攻击点相对较少。原因如下：

这代表着区块链浏览器不会受到攻击吗？还是说，被攻击了也没事？

答案是：No

区块链浏览器攻击类型分类

先来看看区块链浏览器可能会受到什么类型的攻击。

因为区块链浏览器中的大多数功能都涉及从后端数据库中搜索数据，或直接从区块链节点中查询数据。而当提到搜索查询功能时，大家一般会想到两个可能存在的漏洞：

然而，在考察不同的浏览器时，CertiK 技术团队仅发现一例 SQL 注入 , 另外超过 50%的区块链浏览器面临着被 DoS 攻击的危险。

DoS 攻击是什么

举个通俗易懂的例子，某白胡子爷爷眼看某小丑大叔店的炸鸡越卖越好，因此找了几个混混去搞事情。他们站在点餐台前，顾左右而言他，提出了各种问题和需求，店员焦头烂额，点了两个小时的餐也不知道混混到底想要什么，饥肠辘辘的客人等不下去纷纷离店了。这还不够，如果小丑大叔店内部本来店员脾气就不好，一旦被外部矛盾激化，直接上演全武行，店铺一片狼藉 ..................

DoS：Denial of Service 的简称，既拒绝服务，造成 DoS 的攻击行为被称为 DoS 攻击，往往是被用来阻止系统向合法用户提供服务。

在服务器里，有一个事实就是：客户端可以不费任何力气发送 HTTP 请求，但是服务器可能需要消耗大量资源对请求进行处理和响应。应用层 DoS 正是利用这样的特性来进行攻击。

一般来说，DoS 攻防类似于就像是这样的过程，最终结果取决于谁拥有更多的资源。但是，如果后端代码实现有漏洞，单个请求就足以让服务器崩溃了。

本文即将为你分享：DoS 攻击的一些案例、DoS 攻击的影响以及保护应用程序的相关建议。

DoS 攻击案例分析

对服务器进行 DoS 攻击的途径多种多样。一般来说，目标会选择：

下面对一些可被 DoS 攻击的服务器进行案例分析，其中一些是由于代码实现错误引起的，而另一些是由于配置错误而引起的：

资源访问 API 缺少数量限制

https://fake.sample.com/api/v1/blocks?limit=10

以上请求以「limit」参数中指示的数量获取区块信息。当限制设置为 10 时，它将返回最后 10 个区块的信息。当数字较小时，该请求可以正常工作。

但是，后端可能没有对「limit」参数设置上限。当 CertiK 技术团队将「limit」参数设置为 9999999 并发送请求时，请求在被处理很久之后回复了「504 gateway time-out」错误。在服务器处理以上请求的同时，其他 API 的响应时间显着增加。

9999999 也超过了该链中的区块总数。

假设是后端尝试获取区块链中每个区块的数据。如果攻击者发送了大量的高「limit」参数的请求，该服务器会无法对正常请求进行响应甚至可能直接崩溃。

嵌套的 GraphQL 查询

在调查过程中，CertiK 技术团队遇到了一些使用 GraphQL 的区块链资源。GraphQL 是一种用于 API 的查询语言。相比于典型的 REST API 使用多个请求来请求多个资源，GraphQL 以通过一次请求就获取应用所需的所有数据。GraphQL 的使用率很高，但是如果使用过程中没有部署相应的保护措施，很可能会存在安全隐患。

测试区块链浏览器时，CertiK 技术团队发现了其中一个浏览器使用了 GraphQL 接口，其定义的两个类型存在着相互包含的关系，这就允许用户构造一个非常复杂的的嵌套查询。

发送这样的嵌套查询可能会导致服务器上的 CPU 使用率大幅上升。一般情况下，几个这样的请求就能使 CPU 使用率提高到 100％以上，从而导致服务器无法响应正常用户的请求。

当服务器处理此类 Graphql 请求时的 CPU 使用率

下图的「dos_query」展示了嵌套 graphql 的例子：

这样恶意的 GraphQL 请求对服务器造成的影响取决于查询的复杂性和服务器的性能，服务器可能在花费很多时间之后最终能够成功响应查询，但也有可能由于 CPU 使用率过高，服务器直接崩溃。如果你想了解有关 GraphQL 安全性的更多信息，可以访问文章末尾的参考链接 [1]。

直接暴露的 Cosmos RPC API

https://fake.cosmos.api.com/txs?message.action=send&limit=100&tx.minheight=1

上面的 Cosmos API 从区块 1 开始搜索 100 笔发送出去的交易。截至目前，Cosmos 主网中已经有 2712445 个区块。在 CosmosHub 中暴露了 RPC API 节点里，我们找不到任何节点可以处理该请求。接受到此请求的服务器在一段时间后，将返回「502 Bad Gateway」错误，表明请求失败。

节点的 RPC 服务器如果在几秒钟内收到数百个上面描述的搜索请求，将会对所有的 API 请求返回以下错误。一些节点服务器可以错误中自行恢复，而另一些则需要被重启。

为了使读者更好地理解上述问题并演示其效果，CertiK 技术团队设置了一个完全同步的 Cosmos 全节点，并使用上面提到的查询攻击该节点：

https://fake.cosmos.api.com/txs?message.action=send&limit=100＆tx.minheight=1

Grafana CPU 使用率面板

该图可以分为三个阶段：

该图显示在 DoS 攻击下，服务器在短短几分钟内就崩溃了。由于服务器崩溃后无法使用 SSH 连接到服务器，操作员不得不重新启动服务器。

请求处理程序有缺陷

https://fake.sample.com/api/v1?feature=Always_time_out

CertiK 技术团队遇到了一个会不停加载，过了一会儿就显示超时的 API， 但是向服务器发送多个请求并不会影响其他 API 的响应时间。初步猜测是该特定 API 的处理方法不占用 CPU 或内存。由于此区块链浏览器不是开源的，因此无法获得有关 API 代码实现的相关信息，也无法根据其名称确定该 API 端点的用途。

尽管攻击此 API 不太可能使服务器崩溃，但攻击者可以通过发送这类「Always hang and time out」请求来占用所有网络连接，从而阻止其他用户访问此服务器上的 API。

举个例子，「sleep_to_handle_request」函数演示了一个请求可以消耗很少的 CPU 和内存，但是会加载很长时间并占用网络连接的情况。

与其他三个服务器完全崩溃，或需要很长时间才能恢复的案例相比，此案例中的服务器在攻击停止后立即恢复了。

DoS 攻击的影响

遇到 DoS 攻击时，易受攻击的服务器将无法响应正常的用户请求。一些服务器可以在攻击停止后立即或在一段时间后恢复到正常状态，而另一些服务器将完全崩溃并需要重新启动。

无法使用区块链浏览器会给用户带来很大的困扰。因为用户无法轻易的获取有关链上活动的信息。此外，在基于 Cosmos 的链上，如果节点遭受 DoS 攻击，不仅连接的区块链浏览器无法从该节点获取数据，用户也无法使用 API 执行诸如发送代币或将代币委托给验证者的操作。

建议

任何应用程序都存在被 DoS 攻击的威胁，世界上不存在一种解决方案可以完美的防范 DoS 攻击。但有些方法可以用来增加攻击成本从而使潜在的攻击者难以执行攻击操作，并降低区块链浏览器应用中的存在漏洞的概率。

在这里，CertiK 技术团队列出了一些建议，以最大程度地减少应用程序被攻击的机率：

速率限制

即使后端 API 在实现上足够安全，攻击者也可以通过向服务器发送大量请求来进行攻击。因此，API 在任何情况下都应该设置速率限制来暂时或永久屏蔽恶意 IP。

虽然速率限制并不能完全解决问题，但操作起来相对便捷，可以构成针对 DoS 攻击的第一道防线。

改良设计和实现

良好的程序设计和代码实现能在相同的硬件条件下表现出更好的性能，这种效果在与数据库搜索和数据处理相关的功能方面表现得更加突出。但是在考虑性能之前，首先要确保代码没有错误。

因此，在 API 部署到生产环境前编写单元测试上投入大量时间是非常值得的，以此来确保它们能够按预期工作。

输入验证和参数限制

不对用户提供的变量进行验证和限制，那么攻击者就可以滥用 API。

在确定代码能够按预期工作之后，下一步要做的是确保攻击者不能利用非常规的输入滥用 API。类似于获取 9999999 区块的数据或处理 1000 级循环的 GraphQL 查询的请求不应该被允许。

因此，所有用户输入均应被视为不可信的，服务器应在处理用户输入之前对其进行验证。

在上文提到的案例中，GraphQL API 可以设置最大层数限度以有效防御循环查询的 DoS 攻击，而块数据获取 API 则可以将最大块数限制为像 50 这样的合理数值。

开发人员可以根据代码实现和程序设计，总结出最合适当前程序的的输入验证和限制的方案。

不要暴露节点 RPC

并非所有 API 的代码实现都在开发人员的控制之下。

比如，开发人员并不推荐去改 Cosmos RPC API 的代码。Cosmos SDK 中某些搜索查询的性能不是很好，那么该怎么办？

解决方案之一：围绕 Cosmos RPC API 创建一层包装 API，并创建一个存储区块链数据的数据库，该数据库从节点同步区块链数据。外层的包装 API 向公众公开，并接收和处理用户请求，随后再将请求传递到 Cosmos RPC 或在后端数据库中搜索数据。添加外层 API 有效地防止了用户直接与节点 RPC API 进行交互。数据库可以防止节点被搜索查询请求所淹没，并且开发人员可以按照他们所希望的方式优化数据库。

在 Cosmos 论坛上，用户「kwunyeung」也提出了一种解决方案：使用 HTTP 代理（例如 Nginx 或 Caddy）来保护 RPC 端口。总的来说想表达的观点是一致的：RPC 端口不能直接向公众公开，同时还要采取保护措施。

符合建议的硬件要求

即使部署了上述所有防御机制，用户还是需要注意运行 API 服务器或例如 Tendermint(详见参考链接 [2]) 这样的稳定节点对硬件的最低要求。如果服务器在处理来自普通用户访问网站所产生请求就有困难的时候，那么管理员需要考虑升级硬件了。

总结

DoS 攻击可能会使诸如区块链浏览器之类的应用程序陷入崩溃，这对大部分企业来说可以称得上是致命的威胁。

参考链接：

1. https://www.apollographql.com/blog/securing-your-graphql-api-from-malicious-queries-16130a324a6b/

2. https://github.com/tendermint/tendermint/blob/master/docs/tendermint-core/running-in-production.md#hardware/

来源链接：mp.weixin.qq.com

—-

编译者/作者：CertiK

玩币族申明：玩币族作为开放的资讯翻译/分享平台，所提供的所有资讯仅代表作者个人观点，与玩币族平台立场无关，且不构成任何投资理财建议。文章版权归原作者所有。