白帽黑客大赛——小姐姐应援团 - mitDarkMomo/Team_D GitHub Wiki

小姐姐应援团

能联系上的主力名单：

学号	姓名
1	郭斌
10	周国宝
31	肖毅
33	徐翼
38	王智才

阵型分配

5人作为主力：肖毅、智才、周国宝、徐翼、郭斌。

位置：

攻击：2+1
机动：1
防守+记录：1

攻击：智才、周国宝、徐翼

防守+记录：肖毅

机动：郭斌

目标合约地址

0x997f5d2A4865D48873E4D4130A791C801D209E12

漏洞分析及对策

Solidity 安全：已知攻击方法和常见防御模式综合列表

重入漏洞：即 re-entry，课程中已讲
算法上下溢出：使用固定大小的变量来存储超出变量数据类型范围的数字（或数据）时，会发生数据上溢/下溢。
- 危害：若一个数值变量用于控制程序的执行流程，可通过溢出攻击将其重置为任意想要的值
- 方式：对于uint a，若有function传入参数uint value与a进行交互，则value: 2^256 - a会导致判断/赋值a: 0
- 对策：使用SafeMath
不期而至的Ether：有两种方式可以将Ether强制发送给合约，而无需使用payable函数或执行合约中的任何代码
- 危害：若使用this.balance来进行程序中流程的控制，会受到影响
- 方式：selfdestruct(address)从合约地址中删除所有字节码，并将所有存储在那里的Ether发送到参数指定的地址。
- 对策：合约逻辑避免依赖于this.balance，创建自定义变量跟踪已知的Ether存储量
Delegatecall：类似call，也是标准消息调用，但在目标地址中的代码会在调用合约的环境下运行，也就是说，保持 msg.sender和msg.value不变。
- 危害：没完全看懂，反正就是很危险
- 方式：
- 对策：作为一般的经验法则，在使用时DELEGATECALL 时要特别注意库合约和调用合约的可能调用上下文，并且尽可能使用关键字library构建无状态库。
默认可见性（Visibility）
- 危害：函数的可见性默认是public。因此，不指定任何可见性的函数就可以由用户在外部调用。
- 对策：总是指定合约中所有功能的可见性、即便这些函数的可见性本就有意设计成public
随机数误区：一个常见的误区是使用未来的块变量，如区块哈希值，时间戳，区块高低或是Gas上限
- 危害：这些变量都是由挖矿的矿工控制的，因此并不是真正随机的。例如，考虑一个轮盘赌智能合约。
- 对策：随机性的来源只能在区块链之外
外部合约引用
- 危害：如果用户可以更改合约库，则可以以一些非显而易见的方式来掩盖恶意行为者的意图
- 方式：
- 对策：使用new关键字来创建合约
```
constructor（）{
    encryptionLibrary =  new  Rot13Encryption（）;
}
```
拒绝服务（DOS）
- 方式：
  1. 通过外部操纵数组循环：使执行for循环所需的gas超过块gas极限
  2. 依赖owner的特定权限才能使合约进入下一个状态，如果owner丢失私钥则会令合约锁死
  3. 基于外部调用的进展状态
- 对策：
  1. 可以被外部用户人为操纵的数据结构不应该用来循环
  2. 使用一个时间段require(msg.sender == owner || now > unlockTime)
  3. 类似于2.
构造函数名字错误
- 危害：构造函数的行为将与普通函数类似，任何人都可以调用
- 对策：0.4.22之前要详细检查构造函数与合约是否一致（大小写）；0.4.22之后使用constructor关键字
浮点和精度：solidity没有浮点数
- 危害：需要更高的精度时，会变得棘手。
- 对策：计算首先进行乘法，然后再进行除法
Tx.Origin身份验证：tx.origin遍历整个调用栈并返回最初发送调用（或事务）的帐户的地址
- 危害：可能会诱使用户对易受攻击的合约执行身份验证操作
- 方式：诱使合约A的owner向攻击合约进行转账，通过回调函数使得合约A以为调用者是owner（因为最初的转账是由owner发起）
- 对策：require(tx.origin == msg.sender)，杜绝存在中间合约的可能