[i=s] 本帖最后由 one-921 于 2025-7-25 00:44 编辑 [/i]
URL 跳转漏洞详解
1. 前言
URL 跳转漏洞（又称 URL 重定向漏洞）是 Web 应用中常见的安全问题，指服务器对用户传入的跳转链接参数缺乏严格校验与限制，导致攻击者可构造恶意地址，诱导用户跳转到非预期网站。
从技术角度看，URL 跳转依赖 HTTP 重定向机制（301/302 状态码）：
· 301 重定向：适用于域名或网址永久弃用场景，将请求永久导向新地址；
· 302 重定向：适用于临时跳转场景，请求会暂时导向新地址。
当服务器对重定向的目标地址校验不严时，就可能被攻击者利用。例如，若百度存在此类漏洞，攻击者可构造链接**https://www.baidu.com?url=https://**恶意网站.com，用户因注意到开头的正规域名而放松警惕，点击后会被跳转至恶意网站，若该网站为钓鱼页面，可能导致用户信息泄露或财产损失。
漏洞评级：低危
奖金：30 - 200元
2. 漏洞产生原因
URL 跳转漏洞的核心原因是服务器对用户可控的跳转参数校验不足，具体可分为以下几类：
· 参数过滤不严格：开发时未对用户传入的跳转地址（如url redirect等参数）进行格式校验，允许包含任意域名或特殊字符（如**@**）。
· 缺乏白名单限制：未设定允许跳转的可信域名列表（如仅允许跳转至自身域名或合作方域名），导致攻击者可指定任意外部域名。
· 依赖用户可控参数跳转：在登录认证、分享收藏等场景中，直接使用用户传入的参数作为跳转目标，未经过二次验证。
· 特殊字符处理不当：对**@** **//**等可改变 URL 解析逻辑的字符未过滤，攻击者可通过构造形式绕过基础校验。
3. 漏洞的危害
URL 跳转漏洞虽评级多为低危，但被利用时可能造成严重后果，主要包括：
· 钓鱼攻击：攻击者构造以正规网站为前缀的恶意链接（如**https://**银行官网.com?url=钓鱼网站.com），用户易误认为是正规链接，跳转后可能被诱导输入账号密码等敏感信息。
· 恶意软件传播：用户被跳转至包含恶意程序的网站，可能在不知情的情况下下载病毒、木马，导致设备被控制或数据被窃取。
· 信息泄露：若跳转前需用户完成认证（如登录后跳转），攻击者可能通过跳转记录获取用户的登录状态、访问轨迹等敏感信息。
· 损害网站信誉：用户因信任正规网站而点击恶意链接，跳转后遭遇欺诈，会降低对原网站的信任度，影响品牌形象。
4.针对 URL 漏洞的测试技巧
4.1 聚焦核心业务场景
URL 跳转漏洞多存在于用户交互频繁的场景，手工测试时需重点关注：
· 认证相关流程：登录（login）、注册（register）、第三方授权（oauth）、密码重置（reset）、注销（logout）页面，此类场景常通过redirect returnUrl等参数控制跳转目标。
· 内容交互功能：分享（share）、收藏（favorite）、评论（comment）、点赞（like）后，可能通过url jump参数跳转回原页面。
· 外部链接跳转：站内 “友情链接”“合作网站”“帮助中心” 等模块，可能通过link target参数跳转至外部域名，需确认是否限制跳转范围。
4.2 关键词定位跳转参数
通过 URL、页面源码或请求包搜索以下关键词，快速识别潜在跳转参数：
· 常见跳转参数名：redirect url redirectUrl callback return_url toUrl jump goto link target from next。
· 前端跳转函数：window.location location.href window.open location.replace（在页面源码中搜索，可能发现隐藏的跳转逻辑）。
· 后端重定向响应头：Location（抓包时若响应头包含此字段，且值与请求参数相关，需重点测试）。
4.3 分析 URL 结构与参数变化
· 记录页面跳转前后的 URL 变化，例如：
o 登录前：https://example.com/login?redirect=/user
o 登录后：https://example.com/user
可判断redirect参数控制登录后的跳转目标，需测试能否修改为外部域名。
· 对 URL 中的参数进行 “增删改” 测试：
o 原 URL：https://example.com/page → 尝试添加参数：https://example.com/page?redirect=https://test.com，观察是否触发跳转。
o 原参数：?return=/home → 修改为**?return=https://test.com**，观察是否被拦截。
5. 漏洞利用前准备
作为渗透工程师，在利用 URL 跳转漏洞前需完成以下准备工作，确保攻击链路可通：
· 信息收集：
o 识别目标网站中可能涉及跳转的参数，常见参数包括：redirect url redirectUrl callback return_url toUrl jump goto link等，可通过抓包分析（如 Burp Suite 拦截请求）、查看页面源码（搜索location.href window.open等跳转关键词）或利用搜索引擎（如 Google Hacking 语法**site:**目标域名 inurl:redirect）获取。
o 定位漏洞发生点：聚焦用户交互频繁的场景（登录、分享、支付、第三方授权等），记录所有包含跳转参数的 URL。
· 规则探测：
o 初步测试：直接传入外部域名（如**?url=https://test.com**），观察是否跳转成功，判断是否存在基础过滤。
o 绕过测试：若直接跳转被拦截，尝试使用特殊字符（@ #）、IP 地址（如1.1.1.1代替test.com）、短链接（如https://t.cn/xxx）、编码（URL 编码、Unicode 编码）等方式绕过，记录有效绕过方法。
6. 漏洞利用场景 + 实操绕过案例
6.1 OAuth 第三方登录场景及绕过案例
场景说明：许多网站支持微信、QQ、微博等第三方登录（基于 OAuth 协议），用户授权后会通过redirect_uri参数跳转回原网站。若该参数未校验，攻击者可构造恶意跳转地址。
基础案例：
· 目标：某电商网站https://shop.example.com，支持微信登录，登录链接为https://shop.example.com/oauth/wechat?redirect_uri=https://shop.example.com/user（正常跳转至用户中心）。
· 漏洞测试：构造https://shop.example.com/oauth/wechat?redirect_uri=https://fake-shop.com，若成功跳转至恶意网站，则存在漏洞。
**绕过案例（协议头过滤绕过）**：
· 防御规则：服务器过滤包含http://或https://的redirect_uri参数。
· 绕过思路：利用浏览器对 URL 的解析特性，省略协议头，直接使用**//**（双斜杠）表示相对协议（继承当前页面的 HTTP/HTTPS 协议）。
· 构造 Payload：https://shop.example.com/oauth/wechat?redirect_uri=//fake-shop.com。
· 原理：浏览器会将**//fake-shop.com解析为https://fake-shop.com**（因原页面为 HTTPS），从而绕过对**https://**的过滤。
6.2 密码重置跳转场景及绕过案例
场景说明：用户忘记密码时，网站会发送重置链接至邮箱，重置成功后通常通过returnUrl参数跳转至登录页。若参数可控，可诱导用户跳转至恶意站点。
基础案例：
· 目标：某邮箱服务https://mail.test.com，密码重置链接为**https://mail.test.com/reset?token=xxx&returnUrl=https://mail.test.com/login**。
· 漏洞测试：构造**https://mail.test.com/reset?token=xxx&returnUrl=https://fake-mail.com**，若跳转成功则存在漏洞。
**绕过案例（域名白名单绕过）**：
· 防御规则：服务器仅允许returnUrl包含mail.test.com（白名单校验）。
· 绕过思路：利用**@符号改变 URL 解析逻辑，@前的内容会被视为 “用户名”，实际跳转至@**后的域名。
· 构造 Payload：**https://mail.test.com/reset?token=xxx&returnUrl=https://mail.test.com@fake-mail.com**。
· 原理：浏览器解析时会忽略**@前的mail.test.com**，实际访问fake-mail.com，但参数中仍包含mail.test.com，可绕过白名单校验。
· 结果：成功跳转至fake-mail.com。
6.3 支付完成跳转场景及绕过案例
场景说明：用户在电商平台支付成功后，系统会通过jump参数跳转至 “支付成功页” 或订单详情页。若参数未限制，可跳转至钓鱼网站。
基础案例：
· 目标：某支付平台https://pay.example.com，支付成功后跳转链接为https://pay.example.com/success?jump=https://shop.example.com/order。
· 漏洞测试：构造https://pay.example.com/success?jump=https://refund-fake.com，若跳转成功则存在漏洞。
**绕过案例（**IP **地址绕过）**：
· 防御规则：服务器过滤包含外部域名的jump参数（如检测到refund-fake.com则拦截）。
· 绕过思路：将恶意域名转换为 IP 地址（如refund-fake.com的 IP 为1.2.3.4），避免直接出现域名。
· 构造 Payload：https://pay.example.com/success?jump=https://1.2.3.4。
· 原理：服务器可能未对 IP 地址进行限制，仅过滤域名关键词，使用 IP 可绕过检测。
· 结果：成功跳转至1.2.3.4（即refund-fake.com）。
6.4 站内功能跳转场景及绕过案例
场景说明：部分网站提供 “返回上一页”“查看外部链接” 等功能，通过go target等参数指定跳转地址，若未校验，可被利用。
基础案例：
· 目标：某论坛https://bbs.test.com，帖子详情页有 “查看来源” 按钮，链接为https://bbs.test.com/link?go=https://news.test.com/article/123。
· 漏洞测试：构造https://bbs.test.com/link?go=https://malware.com/download，若跳转成功则存在漏洞。
**绕过案例（编码绕过）**：
· 防御规则：服务器对go参数中的malware.com进行关键词过滤，直接拦截包含该字符串的请求。
· 绕过思路：对恶意域名进行 URL 编码（如malware.com编码为**%6D%61%6C%77%61%72%65%2E%63%6F%6D**），绕过关键词匹配。
· 构造 Payload：https://bbs.test.com/link?go=https://%6D%61%6C%77%61%72%65%2E%63%6F%6D/download。
· 原理：服务器若未对参数进行解码后校验，仅通过原始字符串匹配，编码后的内容可绕过过滤，浏览器会自动解码并跳转。
· 结果：成功跳转至malware.com/download。
6.5 用户注销跳转场景及绕过案例
场景说明：用户注销账号时，部分网站会通过redirect参数指定注销后的跳转页面（如首页或登录页），若参数可控，可被利用。
基础案例：
· 目标：某社交平台https://social.example.com，注销链接为https://social.example.com/logout?redirect=https://social.example.com/login。
· 漏洞测试：构造https://social.example.com/logout?redirect=https://fake-social.com，若跳转成功则存在漏洞。
**绕过案例（路径欺骗绕过）**：
· 防御规则：服务器限制redirect参数必须以**/开头（仅允许站内相对路径，如/login**）。
· 绕过思路：利用**../**（路径遍历符）构造跨站路径，结合可信域名的子域名或目录跳转。
· 构造 Payload：https://social.example.com/logout?redirect=/../fake-social.com（假设social.example.com与fake-social.com在同一服务器，或服务器未严格校验路径）。
· 原理：部分服务器会将**/../fake-social.com解析为fake-social.com**，若服务器对路径处理不当，可绕过 “相对路径” 限制。
· 结果：成功跳转至fake-social.com。
6.6 多参数协作绕过案例
场景说明：部分网站的跳转逻辑依赖多个参数（如domain和path）拼接生成目标地址，若单个参数校验严格但组合校验缺失，可被利用。
基础案例：
· 目标：某云服务平台https://cloud.example.com，跳转链接为**https://cloud.example.com/redirect?domain=cloud.example.com&path=/console**（拼接后为**https://cloud.example.com/console**）。
· 漏洞测试：若单独修改domain为malicious.com会被拦截，但可尝试组合参数绕过。
**绕过案例（参数拼接绕过）**：
· 防御规则：domain参数仅允许cloud.example.com，但path参数未限制特殊字符。
· 绕过思路：在path参数中插入**@符号，拼接恶意域名，覆盖domain**的作用。
· 构造 Payload：**https://cloud.example.com/redirect?domain=cloud.example.com&path=@malicious.com/attack**。
· 原理：拼接后的地址为https://cloud.example.com@malicious.com/attack，浏览器解析时实际跳转至malicious.com/attack，domain参数的合法值可绕过初步校验。
· 结果：成功跳转至malicious.com/attack。
7.常见误区解读
· 误区 1：误判https://bbs.yijincc.com@www.hacker.com为漏洞。
直接在浏览器输入该链接并跳转，不能证明原网站存在漏洞 —— 此链接本质是直接访问www.hacker.com，与原网站无关，需通过原网站的参数（如**?url=xxx**）跳转才可能构成漏洞。
· 误区 2：跳转至大厂域名即判定为漏洞。
许多网站会将百度、腾讯等大厂域名加入 “可信白名单”（如合作方），跳转至这些域名可能是正常业务，需测试跳转至不知名域名（如个人博客、新注册域名）验证是否可控。
· 误区 3：一次测试失败即判定无漏洞。
部分网站对跳转参数的过滤存在缺陷（如仅过滤http://，未过滤https://；或仅校验域名前缀），需尝试多种绕过方式（如 IP 地址、短链接、编码）后再下结论。
详细实战
