Go net.LookupIP解析八进制格式IP为何存在不一致表现

问题背景 #

SSRF漏洞防护场景下，通常需要拦截服务端发起的指向本地IP的请求。测试过程中发现Go标准库net.LookupIP对八进制（Base 8）格式IP地址的解析逻辑，与操作系统ping命令、Chrome浏览器的解析表现存在明显差异，容易导致防护规则被绕过。

复现测试 #

测试代码 #

// Go 代码测试
net.LookupIP("0177.0.0.01")  // 解析失败
net.LookupIP("0266.075.0310.07") // 解析成功，返回IP 182.61.200.7

# Shell 环境ping测试
ping 0177.0.0.01  // 解析成功，对应127.0.0.1
ping 0266.075.0310.07 // 解析成功，对应182.61.200.7

Chrome浏览器地址栏输入八进制格式HTTP地址访问时，解析逻辑与ping命令完全一致。

实测结果 #

• net.LookupIP解析0177.0.0.01时未做八进制解码，直接返回解析失败
• net.LookupIP解析0266.075.0310.07时可正常完成八进制解码，得到正确IP182.61.200.7
• Shell环境下两个八进制IP均可正常解析，其中0177.0.0.01对应本地回环地址127.0.0.1
• Chrome浏览器对八进制格式IP的解析逻辑与ping命令完全一致

根因说明 #

net.LookupIP传入IP字符串时不会发起DNS请求，会直接调用内部IP解析逻辑处理，其对带前导0的IPv4地址解析规则和主流系统实现存在本质差异：

1. Go的解析逻辑
   • 解析点分格式IPv4时，首先按纯十进制规则逐段解析，校验每段数值是否在0-255区间内
   • 如果所有段按十进制解析均为合法值，只要任意段带有前导0，Go会直接判定该IP为存在解析歧义的非法格式，返回解析错误——这就是0177.0.0.01解析失败的原因：该字符串每段按十进制计算为177、0、0、1，全部落在0-255区间，但前后两段带前导0，Go直接拒绝解析
   • 如果存在任意一段按十进制解析超出0-255区间，Go会切换到兼容模式，将所有段统一按八进制规则重新解析计算——这就是0266.075.0310.07解析成功的原因：第一段0266按十进制计算为266，超出单段最大值255，触发八进制解析逻辑，最终计算得到正确IP182.61.200.7
2. ping/Chrome等系统/应用的解析逻辑
   这类实现遵循传统libc inet_aton的解析规则：只要IP段以0开头，无论段值是否在十进制合法区间内，一律按八进制解析。因此0177.0.0.01会被直接解析为127.0.0.1，不存在解析失败的情况。

防护提示 #

这种解析差异是SSRF防护的典型绕过点：如果仅依赖net.LookupIP的返回结果做IP校验，攻击者可以构造类似0177.0.0.01的八进制格式本地IP，此时net.LookupIP解析失败，校验逻辑会误判为非本地IP放行请求，但后续操作系统/HTTP客户端实际发起请求时会将其解析为本地回环地址，最终造成SSRF漏洞。做IP校验时需要提前统一处理IP格式，手动剥离前导0、转换多进制IP为标准十进制点分格式后再做判断，不要依赖标准库的默认解析逻辑。

内容的提问来源于stack exchange，提问作者bulue-go