url可能对网站造成威胁访问被阻断
上周三下午,网站威胁我正想从一条微信推文里点开某电商平台的造成商品页,浏览器却弹出一块红色警告:“url可能对网站造成威胁,访问访问被阻断”。被阻链接本身看着没问题,网站威胁域名也正常,造成但公司的访问安全网关硬是把它拦了下来。后来查日志才知道,被阻那条url里带了一串奇怪的网站威胁参数,末尾还跟着?造成redirect=../admin——典型的路径穿越试探。安全设备不傻,访问管你是被阻有意还是无意,先断了再说。网站威胁
这件事让我意识到,造成很多人对url的访问认知还停留在“网址”层面。可url能塞进去的东西远超想象。查询字符串、片段标识、甚至用户信息部分,都是攻击者爱用的藏污纳垢之地。比如http://example.com/login?next=javascript:alert(1),浏览器解析时可能把javascript:当作协议,点击后直接执行脚本。更隐蔽的还有unicode编码绕过,%2e%2e%2f看上去像乱码,解码后就是../,足够让服务器把敏感文件吐出来。
我见过一个真实的案例。某小型企业官网的留言板功能,用户提交内容后url会变成/feedback?msg=...。攻击者没写脚本,只填了一个超长url,里面塞了三千个%00空字节。服务器解析时内存溢出,直接502。运维查了半天,最后发现是url长度和特殊字符没做限制。这种攻击成本极低,一个curl命令就能发出去,但修复起来要改代码、加waf规则、重启服务,折腾一整天。
安全设备阻断这类url,逻辑其实很直接。它们维护一个规则库:出现../、%00、、onerror=这类模式,或者url长度超过阈值,或者参数值里包含base64编码的可疑载荷,一律先拦。误杀肯定有。我同事上次分享一个技术文档,链接里带?file=../../docs/readme.md,也被拦了。他骂骂咧咧地换成短链接才发出去。但站在网站运营方角度,宁可错杀一千,不能放过一个。毕竟一个成功的url注入,可能直接拖库。
普通用户能做什么?别乱点短链接,尤其是那种bit.ly/xxxx后面跟一串乱码的。短链接服务本身不检查目标url的安全性,攻击者可以把恶意地址包装得人畜无害。还有,看到浏览器地址栏里出现%2e%2e或者大量%符号,留个心眼。当然,最省事的办法是相信安全软件的判断——它说阻断,你就别硬闯。我那个被拦的电商链接,后来手动把?redirect=../admin删掉,页面正常打开了。你看,威胁往往就藏在url多出来的那几个字符里。
网站开发者更得注意。别以为前端做了校验就万事大吉。url里的参数到了后端,该转义转义,该白名单白名单。尤其是文件包含、页面跳转、数据库查询这几个场景,?page=../../etc/passwd这种老掉牙的招式至今还能打穿不少站点。我习惯在nginx里加一条规则:如果请求url里出现../或者%00,直接返回444。简单粗暴,但有效。代价是偶尔误伤正常请求,不过比起被拖库,这点误伤我认了。
说到底,url是一串字符,也是攻击面。安全设备阻断它,不是小题大做,而是见过了太多血泪教训。下次再看到红色警告页,别急着骂娘,先看看地址栏里有没有不该出现的东西。
