CertiK: How do blockchain explorers prevent DoS attacks?
TechFlow Selected TechFlow Selected
CertiK: How do blockchain explorers prevent DoS attacks?
A blockchain explorer is a search engine for the blockchain, allowing users to search for specific information on the blockchain using this tool.
Navigating Web3 tides with focused insightsWhen it comes to web browsers, what immediately comes to mind are slogans like "Just search with Baidu" and "Start surfing the internet with Sogou."
These household names—so well-known even older generations can recite them—are not just ambassadors of the internet but also its primary gateways.
But if any technology is walking hand-in-hand with the internet today, it's undoubtedly blockchain technology, now at the peak of its popularity.
The internet transformed life; blockchain technology is transforming the internet. Undoubtedly, as a gateway to the internet, browsers must inevitably be intertwined with blockchain technology. Born from this convergence, blockchain explorers have become familiar real-world applications, offering significant convenience to blockchain users.
How Secure Are Blockchain Explorers?
A blockchain explorer acts as a search engine for the blockchain, allowing users to search for specific information on the blockchain.
For example, Etherscan is an Ethereum blockchain explorer. Through Etherscan, users can easily retrieve information about blocks, addresses, transactions, and other activities on the Ethereum network. In essence, a blockchain explorer functions more like an official blockchain query website.
Given that most blockchain applications today face security threats, how secure are blockchain explorers?
Blockchain explorer applications have relatively few attack vectors. The reasons are:
They do not involve authentication or authorization, so no private information is leaked;
The widespread use of web frameworks (such as Vue and React) reduces the likelihood of XSS (cross-site scripting vulnerabilities);
Does this mean blockchain explorers cannot be attacked?
Or does it mean being attacked doesn't matter?
The answer is: No
Classification of Blockchain Explorer Attack Types
Let’s first look at the types of attacks blockchain explorers might face.
Since most features in blockchain explorers involve searching data from backend databases or directly querying data from blockchain nodes, when discussing search functionality, two potential vulnerabilities typically come to mind:
SQL injection;
DoS (Denial-of-service attacks);
However, during their investigation of different explorers, the CertiK technical team found only one case of SQL injection, while over 50% of blockchain explorers faced the risk of DoS attacks.
What Is a DoS Attack?
Here’s an easy-to-understand analogy: An old man with a white beard sees a clown大叔’s fried chicken shop becoming increasingly popular, so he hires a few hooligans to cause trouble. They stand at the ordering counter, asking endless irrelevant questions and making various demands. Overwhelmed, the staff spends two hours trying to take the order without knowing what the hooligans actually want. Hungry customers grow impatient and leave one by one. It gets worse—if the shop employees already have short tempers, external conflicts could escalate into a full-blown brawl, leaving the store in chaos...
DoS: Short for Denial of Service. Attacks causing DoS are known as DoS attacks, typically aimed at preventing systems from providing services to legitimate users.
In servers, there's a reality: clients can send HTTP requests effortlessly, but servers may expend substantial resources processing and responding to these requests. Application-layer DoS attacks exploit precisely this imbalance.
Generally, DoS attacks resemble such scenarios—the outcome depends on which side possesses more resources. However, if backend code has vulnerabilities, a single request could crash the server.
This article will share some DoS attack cases, their impacts, and recommendations for protecting applications.
Case Analysis of DoS Attacks
There are various ways to launch DoS attacks against servers. Typically, attackers aim to:
Exhaust all CPU and memory resources;
Consume all network connections;
Below are case analyses of servers vulnerable to DoS attacks, some due to coding errors, others due to misconfigurations:
1. Resource Access API Lacking Quantity Limits
https://fake.sample.com/api/v1/blocks?limit=10
This request retrieves block information indicated by the "limit" parameter. When the limit is set to 10, it returns information about the last 10 blocks. With small numbers, this request works normally.
However, the backend may not impose an upper limit on the "limit" parameter. When the CertiK technical team set the "limit" parameter to 9999999 and sent the request, the server responded after a long delay with a "504 Gateway Timeout" error. While processing this request, response times for other APIs significantly increased.
Moreover, 9999999 exceeds the total number of blocks in the chain.
Assuming the backend attempts to retrieve data for every block in the blockchain, if an attacker sends numerous high-"limit" requests, the server could fail to respond to legitimate requests or even crash completely.
2. Nested GraphQL Queries
During investigations, the CertiK technical team encountered several blockchain resources using GraphQL. GraphQL is a query language for APIs. Unlike typical REST APIs requiring multiple requests to fetch multiple resources, GraphQL allows retrieving all needed application data in a single request. Its usage is high, but without proper protective measures, it can pose security risks.
While testing a blockchain explorer, the CertiK technical team discovered one using a GraphQL interface where two defined types mutually contained each other, enabling users to construct highly complex nested queries.
Sending such nested queries may drastically increase CPU usage on the server. Typically, just a few such requests can push CPU usage above 100%, rendering the server unable to respond to legitimate user requests.
CPU usage on the server when processing such GraphQL requests
The figure below shows an example of a nested GraphQL query named "dos_query":
The impact of such malicious GraphQL requests on the server depends on query complexity and server performance. The server might eventually respond successfully after extensive computation, or excessive CPU usage could cause it to crash outright. For more information on GraphQL security, visit reference link 1 at the end of the article.
3. Directly Exposed Cosmos RPC API
https://fake.cosmos.api.com/txs?message.action=send&limit=100&tx.minheight=1
The above Cosmos API searches for 100 outgoing transactions starting from block 1. As of now, there are already 2,712,445 blocks on the Cosmos mainnet. Among exposed RPC API nodes in CosmosHub, we couldn't find any capable of handling this request. Servers receiving this request return a "502 Bad Gateway" error after a delay, indicating request failure.
If a node's RPC server receives hundreds of such search requests per second, it will return the following error to all API requests. Some node servers can recover automatically from such errors, while others require manual restarts.
To help readers better understand the issue and demonstrate its effect, the CertiK technical team set up a fully synchronized Cosmos full node and used the aforementioned query to attack it: "https://fake.cosmos.api.com/txs?message.action=send&limit=100&tx.minheight=1".
Grafana CPU Usage Panel
The graph can be divided into three phases:
The node starts and runs normally, with system CPU usage at 35%
The node faces a DoS attack, with system CPU usage reaching 97%
The node crashes, failing to provide new data to Grafana
The graph shows the server crashing within minutes under a DoS attack. Since SSH connection becomes impossible after the server crashes, operators must manually restart it.
4. Flawed Request Handler
https://fake.sample.com/api/v1?feature=Always_time_out
The CertiK technical team encountered an API that kept loading and eventually timed out. However, sending multiple requests to this API did not affect response times of other APIs. It was initially suspected that the specific API handler did not consume CPU or memory. Since this blockchain explorer was not open-source, no information about the API's code implementation or its purpose based on its name could be obtained.
Although attacking this API is unlikely to crash the server, attackers could occupy all network connections by sending repeated "Always hang and time out" requests, thereby blocking other users from accessing APIs on this server.
For example, the "sleep_to_handle_request" function demonstrates how a request consumes minimal CPU and memory yet loads for a long time, occupying network connections.
Compared to the previous three cases where servers either completely crashed or took a long time to recover, this server recovered immediately once the attack stopped.
Impact of DoS Attacks
When subjected to a DoS attack, vulnerable servers become unable to respond to legitimate user requests. Some servers can immediately or gradually return to normal after the attack stops, while others completely crash and require restarting.
Inaccessibility of blockchain explorers causes significant inconvenience to users who rely on them to obtain information about on-chain activities. Additionally, on Cosmos-based chains, if a node suffers a DoS attack, not only can connected blockchain explorers not retrieve data from that node, but users also cannot use APIs to perform operations such as sending tokens or delegating tokens to validators.
Recommendations
All applications face the threat of DoS attacks, and no perfect solution exists to entirely prevent them. However, certain methods can increase the cost of attacks, making it harder for potential attackers to execute them, thus reducing the likelihood of vulnerabilities in blockchain explorer applications.
Here, the CertiK technical team provides several recommendations to minimize the probability of application attacks:
1. Rate Limiting
Even if backend APIs are securely implemented, attackers can still overwhelm servers with massive requests. Therefore, APIs should always implement rate limiting to temporarily or permanently block malicious IPs under any circumstances.
While rate limiting alone cannot solve the problem completely, it is relatively simple to implement and serves as the first line of defense against DoS attacks.
2. Improved Design and Implementation
Good program design and code implementation deliver better performance under identical hardware conditions, particularly evident in database searches and data processing functionalities. However, before considering performance, ensuring code correctness is paramount.
Therefore, investing significant time in writing unit tests before deploying APIs to production environments is highly worthwhile to ensure they function as expected.
3. Input Validation and Parameter Limitation
Without validating and limiting user-provided variables, attackers can abuse APIs.
Once code functionality is confirmed, the next step is ensuring attackers cannot exploit unconventional inputs to abuse APIs. Requests attempting to retrieve data for 9,999,999 blocks or process GraphQL queries with 1,000-level nesting should not be permitted.
Thus, all user inputs should be treated as untrusted, and servers must validate them before processing.
In the earlier mentioned cases, GraphQL APIs can set maximum depth limits to effectively defend against cyclic query DoS attacks, while block data retrieval APIs can cap the maximum block count at a reasonable value like 50.
Developers can devise the most suitable input validation and limitation strategies based on code implementation and program design.
4. Do Not Expose Node RPC
Not all API code implementations are under developers' control.
For instance, modifying Cosmos RPC API code is not recommended. Performance of certain search queries in the Cosmos SDK isn't optimal—what then?
One solution: Create a wrapper API layer around the Cosmos RPC API and establish a database storing blockchain data synchronized from the node. The outer wrapper API is publicly exposed, receiving and processing user requests before forwarding them to the Cosmos RPC or searching data within the backend database. Adding an outer API effectively prevents direct interaction between users and node RPC APIs. The database prevents nodes from being overwhelmed by search queries, and developers can optimize the database as desired.
On the Cosmos forum, user "kwunyeung" also proposed a solution: Using an HTTP proxy (e.g., Nginx or Caddy) to protect RPC ports. Overall, the consensus is clear: RPC ports should not be directly exposed to the public and must be protected.
5. Meet Recommended Hardware Requirements
Even with all the above defenses deployed, users must pay attention to minimum hardware requirements for running API servers or stable nodes like Tendermint (see reference link 2). If the server struggles to handle requests generated by regular user traffic, administrators should consider upgrading hardware.
Conclusion
DoS attacks can potentially crash applications like blockchain explorers, posing a fatal threat to most enterprises.
The professional security team at CertiK has extensive experience and specialized expertise in application vulnerability assessments, code audits across various languages such as Solidity, Rust, and Go, and security maintenance for platforms including Ethereum, Cosmos, and Substrate.
For comprehensive security audits of blockchain-related businesses—including blockchain explorers, wallets, exchanges, smart contracts, and even underlying blockchain protocol implementations—CertiK offers years of practical defensive experience and cutting-edge formal verification technologies, making us your most trusted security expert.
Appendix
Below is a sample script to test whether a Cosmos node is vulnerable to DoS attacks. By modifying the "url" variable, different applications can be tested.
Do not run this on unauthorized applications.
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()
References:
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
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
