上周我在公司捅了个篓子——自己写的登录定登录模块差点成了钓鱼网站的帮凶。今天就跟大家唠唠这个惊险过程,功能攻击锅附以及怎么避免HTTP重定向攻击这个"隐形炸弹"。差点
事情发生在某个阳光明媚的周一,测试组的登录定小美突然冲进我们开发组:"你们的登录接口被劫持了!用户点完登录直接跳转到赌博网站!功能攻击锅附"
我当时的差点反应:"绝对不可能!我明明做了URL白名单验证..."
我们复现了问题场景:
用户访问 www.our-app.com/login?司背redirect=/profile输入正确账号密码页面跳转到...澳门首家线上赌场(!)我盯着浏览器的解决Network面板,发现请求里赫然有个302状态码:
复制HTTP/1.1 302 Found Location: https://malicious-site.com?登录定steal_cookie=123abc1.2.关键问题解析:起初我们以为用户访问的是正常路径/profile,但实际攻击发生时,源码下载功能攻击锅附redirect参数是差点经过精心伪装的:
图片
实际跳转地址变成:https://our-app.com//malicious-site.com浏览器自动解析为:https://malicious-site.com
为什么测试时没发现?我们在测试环境用的都是类似/profile的简单路径,完全没料到这些骚操作:
//外部网站 的司背路径拼接攻击@恶意域名 的特殊解析%编码 的绕过手法
图片
就像快递员送错包裹:
用户说:"送完这个去A地址"(带redirect参数)服务器说:"好的,下个包裹送到B地址"(返回302+Location)快递员(浏览器)无脑照做这是我最初写的危险代码(Java示例):
复制// 危险示范!请勿模仿! String redirectUrl = request.getParameter("redirect"); response.sendRedirect(redirectUrl);1.2.3.给redirect参数加"防伪码":
复制# 生成签名 sign = hashlib.sha256(redirect_path + SECRET_KEY).hexdigest() safe_url = f"{redirect_path}?sign={sign}" # 验证时 client_sign = request.GET.get(sign) server_sign = hashlib.sha256(redirect_path + SECRET_KEY).hexdigest() if client_sign != server_sign: abort(403)1.2.3.4.5.6.7.8.9.把绝对URL变成相对路径:
复制// 把 https://www.our-app.com/profile 转为 /profile function sanitizeRedirect(url) { return new URL(url).pathname; }1.2.3.4.这次事故让我明白:安全不是功能,而是底线。现在每次处理重定向时,我都会默念三遍:
"用户传参猛于虎,未经验证就是赌,白名单加签名锁,安全红线不能触。"
最后送大家一个自查清单:
• [ ] 所有redirect参数是否强制校验?
• [ ] 是否存在裸跳转(直接拼接URL)?
• [ ] 是否配置了CSP安全策略?
• [ ] 是否禁用非必要的HTTP方法?
• [ ] 是否定期进行渗透测试?
云服务器(责任编辑:IT科技类资讯)