但是，后端可能没有对“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请求返回以下错误。一些节点服务器可以错误中自行恢复，而另一些则需要被重启。 (责任编辑：admin)