以太坊短地址漏洞，智能合约安全史上的经典警示
在区块链安全领域，智能合约漏洞往往因微小疏忽引发连锁反应，而以太坊“短地址漏洞”正是其中的典型代表，这一漏洞虽非底层协议缺陷，却因开发者对ABI（应用程序二进制接口）的误解，曾导致多个项目遭受重大损失,成为智能合约安全教育的经典案例。
漏洞根源：ABI编码的“隐式填充”机制
以太坊智能合约的函数调用中，参数需通过ABI进行编码，对于地址类型（address）和固定长度字节类型（bytes32），ABI要求其长度严格固定：地址为20字节，bytes32为32字节，当开发者未对用户输入的地址长度进行校验时，若用户提供短于20字节的地址（如“0x123”），ABI会自动在末尾填充零字节至20字节，而填充后的地址会与原始输入完全不同。
更关键的是，短地址会导致参数长度计算错误，若函数调用本应接收地址（20字节）和金额（uint256，32字节），共52字节，但用户输入18字节地址（未填充）+32字节金额，实际总长50字节，ABI会错误地将后32字节的金额解析为地址，而将剩余的18字节+14字节的填充位解析为金额，导致金额参数被截断,引发意想不到的资金转移。
攻击场景：从“无心之失”到“恶意盗取”
短地址漏洞的攻击常发生在用户交互环节，假设某合约的transfer(address to, uint256 amount)函数中，开发者未校验to的长度，攻击者可构造一个18字节的“伪地址”（如0x123...，末尾无填充），调用时传入0x123...+10000000000000000000000000000000（金额），由于ABI自动填充，to会被解析为0x123...000000000000（20字节），而金额参数因长度不足，实际被解析为0x10000000000000000000000000000000（远超用户预期），导致合约向攻击者地址转移巨额资金。
2018年，去中心化交易所Bancor曾因该漏洞损失约23.9万美元；同年，多个DeFi项目也因类似问题遭攻击,暴露出开发层面对ABI机制理解不足的普遍问题。
防护措施：从“校验”到“设计”的全面加固
防范短地址漏洞需从开发与交互双端入手：
- 严格参数校验：在合约函数中，使用
require(to.length == 20, "Invalid address length")等语句明确校验地址长度，阻止非20字节地址通过。 - 使用类型化库函数：借助OpenZeppelin等安全库中的地址校验函数，避免手动处理ABI编码细节。
- 前端输入拦截：在用户界面层限制地址输入长度，或通过正则表达式强制地址格式（如以“0x”开头，42字符）。
- 安全审计与测试：通过工具（如Slither、MythX）扫描合约中的长度校验缺失,并在测试网中模拟短地址输入场景。
短地址漏洞虽技术原理简单，却深刻揭示了区块链安全“细节决定成败”的特性，它提醒开发者：智能合约安全不仅依赖底层协议的健壮性，更需对ABI、编码机制等基础规范有精准理解，在DeFi与智能合约应用日益复杂的今天，唯有将安全意识融入编码全流程，才能避免因“小疏忽”酿成“大灾难”。
