The four most famous international exchanges:

Binance INTL	OKX INTL	Gate.io INTL	Huobi INTL
China Line　APP DL	China Line　APP DL	China Line　APP DL	China Line　APP DL

Note: The above exchange logo is the official website registration link, and the text is the APP download link.

説到瀏覽器，大家腦海裏蹦出來的一定是「百度一下，你就知道」......這些家喻户曉甚至大爺都説的上來的瀏覽器，是互聯網的代言人，更是互聯網的入口，但是如果説有誰和互聯網是勾肩搭背的關係，那就是現今如日中天的區塊鏈技術了。

互聯網改變生活，區塊鏈技術改變互聯網。那麼毫無疑問，作為互聯網的入口，瀏覽器必然也與區塊鏈技術脱不開關係。由此誕生的區塊鏈瀏覽器，作為大家耳熟能詳的落地產品，更是為區塊鏈用户帶來了相當程度的便利。

區塊鏈瀏覽器

區塊鏈瀏覽器是區塊鏈的搜尋引擎，用户可使用此工具搜索區塊鏈上的特定信息。

舉個例子，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缺少數量限制



以上請求以「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



上面的Cosmos API從區塊1開始搜索100筆發送出去的交易。截至目前，Cosmos主網中已經有2712445個區塊。在CosmosHub中暴露了RPC
API節點裏，我們找不到任何節點可以處理該請求。接受到此請求的伺服器在一段時間後，將返回「502 Bad Gateway」錯誤，表明請求失敗。

節點的RPC伺服器如果在幾秒鐘內收到數百個上面描述的搜索請求，將會對所有的API請求返回以下錯誤。一些節點伺服器可以錯誤中自行恢復，而另一些則需要被重啓。

為了使讀者更好地理解上述問題並演示其效果，CertiK技術團隊設置了一個完全同步的Cosmos全節點，並使用上面提到的查詢攻擊該節點：「
= 100&tx.minheight = 1」。

Grafana CPU使用率面板

該圖可以分為三個階段：

節點已啓動並正在運行，系統的CPU使用率為35%

節點面臨DoS攻擊，系統CPU使用率達到97%

節點崩潰，無法將新數據提供給Grafana

該圖顯示在DoS攻擊下，伺服器在短短幾分鐘內就崩潰了。由於伺服器崩潰後無法使用SSH連接到伺服器，操作員不得不重新啓動伺服器。

4.請求處理程序有缺陷



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攻擊可能會使諸如區塊鏈瀏覽器之類的應用程式陷入崩潰，這對大部分企業來説可以稱得上是致命的威脅。