区块链浏览器如何防止被DoS攻击？

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

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

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

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

 

区块链浏览器安全性如何

 

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

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

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

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

• 不涉及身份验证或授权，因此不会泄漏任何私人信息；
• Web框架（如Vue和React）的广泛使用使得XSS（跨站点脚本漏洞）的发生可能性降低；

 

这代表着区块链浏览器不会受到攻击吗？

还是说，被攻击了也没事？

答案是：No

 

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

 

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

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

• SQL注入；
• DoS（Denial-of-service拒绝服务攻击）；

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

 

DoS攻击是什么

 

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

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

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

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

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

 

DoS攻击案例分析

 

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

• 消耗所有CPU和内存资源；
• 占用所有的网络链接；

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

1. 资源访问API缺少数量限制

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

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

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

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

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

2. 嵌套的GraphQL查询

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

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

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

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

下图的“dos_query”展示了嵌套graphql的例子：

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

3. 直接暴露的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使用率面板

该图可以分为三个阶段：

1. 节点已启动并正在运行，系统的CPU使用率为35％
2. 节点面临DoS攻击，系统CPU使用率达到97％
3. 节点崩溃，无法将新数据提供给Grafana

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

4.请求处理程序有缺陷

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技术团队列出了一些建议，以最大程度地减少应用程序被攻击的机率：

1.速率限制

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

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

2.改良设计和实现

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

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

3.输入验证和参数限制

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

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

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

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

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

4.不要暴露节点RPC

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

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

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

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

5.符合建议的硬件要求

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

 

总结

 

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

 

附录

 

这是一个示例脚本，用于测试Cosmos节点是否容易受到DOS攻击。通过修改“url”变量可以测试不同的应用程序。

请不要对未经许可的应用程序运行。

import requests
import threading  
import urllib3  
urllib3.disable_warnings(urllib3.exceptions.InsecureRequestWarning)  
#Modify the url  
url ="https://fake.cosmos.api/txs?message.action=send&limit=100&tx.minheight=1"
def dos_thread():  
    while(1):  
        response = requests.request("GET", url, verify=False)  
        print(response.text.encode('utf8'))  
if __name__ == "__main__":  
    for i in range(300):  
        t = threading.Thread(target=dos_thread)  
       t.start()

参考链接：

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