为了使读者更好地领略上述问题并演示其结果，CertiK 技能团队配置了一个完全同步的 Cosmos 全节点，并利用上面提到的查询进攻该节点：
原文标题：《区块链欣赏器可以逃离 DoS 的九阴白骨爪吗？》 DoS 进攻大概会使诸如区块链欣赏器之类的应用措施陷入瓦解，这对大部门企业来说可以称得上是致命的威胁。 区块链欣赏器是区块链的搜索引擎，用户可利用此东西搜索区块链上的特定信息。 说到欣赏器，各人脑海里蹦出来的必然是「百度一下，你就知道」、「上网从搜狗开始」...... 互联网改变糊口，区块链技能改变互联网。那么毫无疑问，作为互联网的进口，欣赏器一定也与区块链技能脱不开干系。由此降生的区块链欣赏器，作为各人耳熟能详的落地产物，更是为区块链用户带来了相当水平的便利。 纵然后端 API 在实现上足够安详，进攻者也可以通过向处事器发送大量请求来举办进攻。因此，API 在任何环境下都应该配置速率限制来临时或永久屏蔽恶意 IP。 那么在如今大部门区块链应用都面对安详威胁的场景下，区块链欣赏器的安详性又如何呢？ DoS 进攻的影响 下面临一些可被 DoS 进攻的处事器举办案例阐明，个中一些是由于代码实现错误引起的，而另一些是由于设置错误而引起的： 测试区块链欣赏器时，CertiK 技能团队发明白个中一个欣赏器利用了 GraphQL 接口，其界说的两个范例存在着彼此包括的干系，这就答允用户结构一个很是巨大的的嵌套查询。 在上文提到的案例中，GraphQL API 可以配置最大层数限度以有效防止轮回查询的 DoS 进攻，而块数据获取 API 则可以将最大块数限制为像 50 这样的公道数值。 请求处理惩罚措施有缺陷 输入验证和参数限制 直接袒露的 Cosmos RPC API 先来看看区块链欣赏器大概会受到什么范例的进攻。 该图可以分为三个阶段： 这代表着区块链欣赏器不会受到进攻吗？照旧说，被进攻了也没事？ 发送这样的嵌套查询大概会导致处事器上的 CPU 利用率大幅上升。一般环境下，几个这样的请求就能使 CPU 利用率提高到 100％以上，从而导致处事器无法响应正常用户的请求。 参考链接： DoS 进攻案例阐明 因此，在 API 陈设到出产情况前编写单位测试上投入大量时间长短常值得的，以此来确保它们可以或许按预期事情。 https://fake.cosmos.api.com/txs?message.action=send&limit=100&tx.minheight=1 CertiK 技能团队碰着了一个会不断加载，过了一会儿就显示超时的 API， 可是向处事器发送多个请求并不会影响其他 API 的响应时间。劈头揣摩是该特定 API 的处理惩罚要领不占用 CPU 或内存。由于此区块链欣赏器不是开源的，因此无法得到有关 API 代码实现的相关信息，也无法按照其名称确定该 API 端点的用途。 不要袒露节点 RPC 9999999 也高出了该链中的区块总数。 一般来说，DoS 攻防雷同于就像是这样的进程，最终功效取决于谁拥有更多的资源。可是，假如后端代码实现有裂痕，单个请求就足以让处事器瓦解了。 在确定代码可以或许按预期事情之后，下一步要做的是确保进攻者不能操作非通例的输入滥用 API。雷同于获取 9999999 区块的数据或处理惩罚 1000 级轮回的 GraphQL 查询的请求不该该被答允。 高出 50% 的区块链欣赏器面对着被 DoS 进攻的危险，可以采纳法子增加进攻本钱并低落区块链欣赏器应用中存在裂痕的概率。 资源会见 API 缺少数量限制 固然速率限制并不能完全办理问题，但操纵起来相对便捷，可以组成针对 DoS 进攻的第一道防地。 DoS 进攻是什么 好比，开拓人员并不推荐去改 Cosmos RPC API 的代码。Cosmos SDK 中某些搜索查询的机能不是很好，那么该怎么办？ 然而，在考查差异的欣赏器时，CertiK 技能团队仅发明一例 SQL 注入 , 别的高出 50%的区块链欣赏器面对着被 DoS 进攻的危险。 举个通俗易懂的例子，某白胡子爷爷眼看某小丑大叔店的炸鸡越卖越好，因此找了几个地痞去搞工作。他们站在点餐台前，顾阁下而言他，提出了各类问题和需求，伙计焦头烂额，点了两个小时的餐也不知道地痞到底想要什么，饥肠辘辘的客人等不下去纷纷离店了。这还不足，假如小丑大叔店内部原来伙计性情就欠好，一旦被外部抵牾激化，直接上演全武行，店肆一片散乱 .................. 谜底是：No DoS：Denial of Service 的简称，既拒绝处事，，造成 DoS 的进攻行为被称为 DoS 进攻，往往是被用来阻止系统向正当用户提供处事。 以上请求以「limit」参数中指示的数量获取区块信息。当限制配置为 10 时，它将返回最后 10 个区块的信息。当数字较小时，该请求可以正常事情。 精采的措施设计和代码实现能在沟通的硬件条件下表示出更好的机能，这种结果在与数据库搜索和数据处理惩罚相关的成果方面表示得越发突出。可是在思量机能之前，首先要确保代码没有错误。 举个例子，「sleep_to_handle_request」函数演示了一个请求可以耗损很少的 CPU 和内存，可是会加载很长时间并占用网络毗连的环境。 Grafana CPU 利用率面板 因为区块链欣赏器中的大大都成果都涉及从后端数据库中搜索数据，或直接从区块链节点中查询数据。而当提到搜索查询成果时，各人一般会想到两个大概存在的裂痕： 无法利用区块链欣赏器会给用户带来很大的困扰。因为用户无法等闲的获取有关链上勾当的信息。另外，在基于 Cosmos 的链上，假如节点蒙受 DoS 进攻，不只毗连的区块链欣赏器无法从该节点获取数据，用户也无法利用 API 执行诸如发送代币或将代币委托给验证者的操纵。 郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。
