引言：“虽然你无法治愈自己，但你会被一具尸体和一个愿望所取代。”- 《庄子逍遥游》
古时候，有一位杰出的领袖，名叫唐尧。
他所在地区的人们安居乐业，但当他听说隐士许由很有才华时，他萌生了把自己的领导权交给许由的想法。但许由拒绝了，说：“鹪鹩在深林筑巢，但只有一个分支。”
在这一点上，后人也用“越权”一词来表达越权的意思。
“覆盖其他”
智能合同的实施中存在访问权限。如果权限设置不合理，很容易造成智能合约被攻击，甚至造成巨大的经济损失。
成都安联安全实验室在智能合约安全方面有着丰富的经验和积累。然而，随着对区块链技术的日益重视，智能合约的数量越来越多，智能合约被攻击的事件也越来越多。这也让我们感觉到“让区块链更安全”的企业使命是多么重要，但单靠我们自己很难对抗所有的威胁。
接下来将结合智能合约的CTF靶场ethernaut积累自己的安全经验，通过技术连载向广大智能合约开发者普及如何在开发过程中实现更安全的代码。
现在说回退，ethernaut范围第一题，代码功能“越级”事件。
越权漏洞是指在智能合约中，不能成功调用某个函数的用户，由于该函数的可见性设置不合理或没有对该函数进行有效验证，而直接或绕过验证调用该函数。
此漏洞可以单独利用，也可以与其他漏洞结合使用。利用方法简单，漏洞的影响取决于漏洞的功能，可能对契约造成毁灭性的打击。
漏洞原理详细分析
2.1合同中的“否”和“否”
“怎么理解丠“还有”丠“在合同里？我们先来看一个合同代码，如下图所示：
图1
这个合同代码来自Fallback，以太网范围的第一个问题。针对靶场存在的问题，解决问题的思路是通过调用回调函数payable public触发owner=msg.sender这样合同的所有者就成了呼叫者。
题目很简单。只要您使用此合同发起交易并满足要求，就可以触发回退功能。
通常，在对约定调用中，如果没有其他函数匹配给定的函数标识符或者没有提供附加数据，那么将执行回退函数。一般是转入以太坊的默认操作。因此，开发智能合约时，一般不需要将owner=msg.sender写入回退函数。
如下图所示：
图2
但是在这里调用了不该由用户调用的owner=msg.sender，导致权限控制不当，造成越权。于是，接下来的故事就发生在“季”和“秋”之间。
2.2相关安全事件
2.2.1 Bancor合同事件
2020年6月18日，Bancor网络(0x5f 58058 c 0 EC 971492166763 c8 c 22632 b 583 f 667 f)被曝存在漏洞。
该漏洞是由于契约中存在一个公共的safeTransferFrom方法造成的，因此攻击者可以直接调用该方法将Bancor网络契约授权的令牌转移到任何帐户。
它关于转账和授权的三个功能都是公开的，任何用户都可以调用。这一事件涉及超过50W美元。
详细代码如下图所示：
图3
“奸臣”的权力是公共安全转移的手段，没有得到“国王”的许可，直接剥夺了“国家”的“财权”。
幸运的是，Bancor网络团队和白帽首先发现了这个问题，并转移了资金。后续修复了漏洞，避免了损失。
详细分析见(https://mp.weixin.qq.com/s/vN1bNLqdvr8JEqq9QI0X1Q)。
同样的事情也发生在另一份合同中。接下来介绍一下6月底的VETH合约漏洞事件。
2.2.2 VETH项目的VETH
2020年6月30日，VETH项目曝光。在这个事件中，“越俎代庖”的主角是契约中changeExcluded函数的外部修饰符。
外部修饰符允许任何人调用changeExcluded函数来绕过transferF。
rom函数内部的授权转账额度检查，将合约的VETH代币盗走。此次事件，攻击者利用此漏洞盗走919299个VETH后大量抛售，导致VETH代币价值瞬间流失。
详细见（https://mp.weixin.qq.com/s/plbSmpMfvIk_A457GoUaQA）涉及到的合约代码如下图所示：
图4
通过以上两个案例，相信大家已经意识到了合约中“越俎代庖”事件的严重影响，那么如何在合约代码编写的过程中有效的区分“俎”与“庖”呢？
2.3“俎”、“庖”信息大揭秘
针对越权事件，首先需要合约开发人员了解函数可见性。
函数的可见性，一共有external、public、internal和private四种：
-External
外部函数作为合约接口的一部分，意味着我们可以从其他合约和交易中调用。一个外部函数 f 不能从内部调用（即 f 不起作用，但 this.f() 可以）。当收到大量数据的时候，外部函数有时候会更有效率，因为数据不会从calldata复制到内存.
-Public
public 函数是合约接口的一部分，可以在内部或通过消息调用。对于 public 状态变量， 会自动生成一个 getter 函数（见下面）。
-Internal
这些函数和状态变量只能是内部访问（即从当前合约内部或从它派生的合约访问），不使用 this 调用。
-Private
private 函数和状态变量仅在当前定义它们的合约中使用，并且不能被派生合约使用。
开发人员在构造一个函数时，应当遵循这些可见性进行开发，要明确哪些函数是可以由用户调用的“俎”，而哪些又是合约中不能任意替代的“庖”，以最小原则进行分配。
比如一个函数safeTransfer在设计时是用于转账操作的，用户可以通过调用此函数，转账此合约发行的代币。我们使用public和external都可以满足需求，但就安全的角度，我们应当使用external，避免合约内对此函数进行调用，造成不可预期的风险。
如存在有一个safeTransferFrom函数，用户可以通过授权给此合约其他代币，将其他代币转移到一个指定地址的，当_token等于合约本身时，就会以合约本身的身份调用sadeTransfer函数，即而将合约内的钱转到其他地址。
图5
然而只是遵循函数可见性是远远不够的，函数的可见性，只是区分了合约内部、继承合约和外部这三个界限，远远不能满足我们的需求。
想要达到较为完善的权限管理，我们应当引入“角色”的概念，如：管理员、普通用户、特权用户等。在合约中存储这些角色的地址，通过判断地址或标志变量来进行权限的控制。
如下图所示：
图6
通过修饰器对这些不同的“角色”进行管理，如使用onlyOwner修饰器，限制特定的地址才可调用此函数。对应“角色”的权限管理。使用修饰器的方式，可以更加清晰的判断出是否存在纰漏。
成都链安安全团队依据多年合约审计和链上分析安全经验给出以下几点建议：
1、遵循权限最小化开发原则，在设计函数时应当就规划好可见性。
2、建立角色机制，使用修饰器对各函数进行权限管理，避免纰漏。
3、上线前一定找专业机构做好代码审计，正所谓“一人一个脑，做事没商讨；十人十个脑，办法一大套”。
