分布式拒绝服务攻击了解一下

随着经济技术的不断发展，计算机安全技术越来越受到冲击，拒绝服务攻击已成为网络机安全最大的威胁之一，由于它的破坏性极大，因此成为网络黑客经常采用的攻击手段。该文主要分析了拒绝服务攻击的基本原理以及怎样能够更好的加以防范。

上篇讲了分布式拒绝服务漏洞的前两个攻击，今天，我们就来讲他的第三个攻击——不可更改的管理器缺陷。

攻击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这类错误中学习，我们可以防止自己在错误的道路上越走越远。