分散式拒絕服務攻擊了解一下

隨著經濟技術的不斷發展，計算機安全技術越來越受到衝擊，拒絕服務攻擊已成為網路機安全最大的威脅之一，由於它的破壞性極大，因此成為網路黑客經常採用的攻擊手段。該文主要分析了拒絕服務攻擊的基本原理以及怎樣能夠更好的加以防範。

上篇講了分散式拒絕服務漏洞的前兩個攻擊，今天，我們就來講他的第三個攻擊——不可更改的管理器缺陷。

攻擊3- 不可更改的管理器缺陷

什麼使得智能合約這麼特別？他們是不可更改的。什麼造就了智能合約的噩夢？他們是不可更改的。現在，很遺憾的結論是，當在寫智能合約時，很多時候會出現錯誤。在激活合約之前，對整體的函數，參數和合約結構進行審核，是非常必要的。

如果在以太坊歷史上，有智能合約是因為整體架構出問題，而最終失敗的，毫無疑問就是Rubixi。Rubixi是另一個旁氏遊戲，其中玩家需要發送以太幣到合約中，並且可以獲得更多的以太幣。但是，在Rubixi開發的過程中，擁有者隨意更改了合約名稱，但是並沒有檢車任何的不一致性。毋庸置疑，Rubixi遠不能稱為「成功」。

攻擊示例

由於Solidity v0.4.24演算法，合約的管理器功能是construct()。但是，在Rubixi合約創建的時候，管理器功能被以太坊虛擬機和合約共享了同個名字。Rubixi的問題在於當合約中部署了管理器的名稱為function DynamicPyramid() ，而不是function Rubixi(),，這就意味著Rubixi最初的名字叫「DynamicPyramid」。由於這個不一致性，合約在創建的時候，並沒有指定擁有者，所以城堡的鑰匙被搶走了。任何人都能夠定義他們自己為合約的擁有者，然後獲得參與者加入的合約費用。

代碼示例

如果我們把合約代碼的前幾行拿出來，你就會發現合約名稱和指定管理器函數的區別。

現在你應該明白了，攻擊者需要做的，就是創建合約的名字為function DynamicPyramid(), 然後獲得擁有權。然後，攻擊者可以調用function collectAllFees()，然後提現。雖然這個攻擊已經非常直接了，Rubixi是個很好的例子，告訴我們一定要徹底地檢查合約。

很幸運地是，Solidity語言已經更新了，以至於管理器功能被定義為constructor() ，而不是contractName()。我們可以從中學到的是，多次檢查我們的合約代碼，並且保證你在整個開發過程中，保持一致性。沒有什麼比部署一個無法改變的合約，但是發現其中有問題，更糟糕了。

從被DoS到交易系統異常，到項目被冰封直至被遺忘，但是只要我們銘記教訓，就能穩固地保持區塊鏈技術的發展。

旁氏遊戲或許已經是過去的事情，但是George Santayana曾經說過，「那些不能從歷史中學到教訓的人，還會重複錯誤。」通過從KotET, GovernMental和Rubixi這類錯誤中學習，我們可以防止自己在錯誤的道路上越走越遠。

曲速未來安全區提醒：旁氏遊戲或許已經是過去的事情，但是George Santayana曾經說過，「那些不能從歷史中學到教訓的人，還會重複錯誤。」通過從KotET, GovernMental和Rubixi這類錯誤中學習，我們可以防止自己在錯誤的道路上越走越遠。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！