Web笔记 | URL跳转漏洞（开放重定向）

URL跳转漏洞（也叫--开放重定向 Open Redirection），出现在应用程序未对传入的跳转URL变量进行校验的时候，会导致用户被诱导跳转到恶意网站，或与XSS、SSRF、CSRF漏洞进行组合利用，绕过站点的安全防护。

URL 形如：https://example.com/login?return=https://PotentiallyEvil.com/

后端代码形如 (Java) ：response.sendRedirect(request.getParameter("url"))

*可以理解为，要访问的网址本身设计了从 URL 的参数中跳转到另一个地址，如果这个跳转的参数可以为用户构造的参数值，那么会存在钓鱼的风险。当用户在已登录的状态下访问该链接时，可以绕过 Referrer 字段对 CSRF token 的校验（跳转时请求的 Referrer 携带当前站点信息），组合实现对 CSRF 漏洞的利用。

📍漏洞危害与影响

钓鱼、隐藏反射XSS Payload（因为URL的前部分是信任站点）；
结合实现CSRF漏洞的利用，绕过对安全策略对Referrer的校验；
敏感信息泄露：根据Referrer Policy和URL所携带的参数，跳转后携带的Referrer信息可能会导致信息泄露。

有可能泄露的敏感信息类型示例（从 URL、Referrer 中泄露）：

CSRF Token：如果Token放在URL中（GET请求），或通过Referrer传递；
OAuth2.0的授权码如果在URL中，且跳转目标不受控，可通过Referrer劫持授权码；
Authorization Token：Bearer Token或JWT如果放在URL参数中（如?token=xxx），会在Referrer中暴露；
URL 中出现的个人身份信息、地理位置/经纬度信息；

📍漏洞存在的场景、功能点

用户注册、登录、统一身份认证；
用户转发、分享、评论、收藏内容；
通过单击链接的方式返回上一页的位置；
站内单击其他网址链接时发生的跳转；

📍 **漏洞修复：**通过白名单的方式设置跳转域名或者 IP

其他防御建议

服务端 ：对跳转 URL 进行严格的白名单校验，禁止携带内网 IP 或javascript: 协议；
客户端 ：不要将不可信数据直接赋值给 window.location，使用 URL 构造函数进行解析和白名单匹配；
OAuth ：严格校验 redirect_uri 的完整性，并强制使用 state 参数防御 CSRF。

验证与绕过技巧

状态码302的响应包

验证思路： 观察哪些功能需要进行跳转，并关注任何涉及跳转操作的URL，常见的参数值有 return、redirect、redirect_to、redirect_url、url、jump、goto、target、link、callback、link、domain、checkout_url 等，输入任意URL地址看是否可以任意跳转

绕过技巧：https://portswigger.net/web-security/ssrf/url-validation-bypass-cheat-sheet

组合利用：csrf, ssrf, xss

思路：

在什么场景下进行组合利用

如何进行组合利用

1. 与CSRF的组合：窃取凭证

场景 A：绕过 CSRF 的 Referrer 校验
场景 B：劫持 OAuth 2.0 /SSO 的 redirect_uri 获取授权码

A. 站点在防御CSRF的时候，会校验 Referrer 头是否为本域。如果网站存在 Open Redirection，会被当做"跳板"。

构造示例：将构造的表单放在存在URL跳转漏洞（开放重定向）页面路径下，https://trusted-site.com/redirect?url=https://evil.com/callback，由于 Referrer 头通常只包含域名和路径，不包含参数。
效果：此时，发起 CSRF 请求时，Referrer 的值为 https://trusted-site.com/redirect，属于同源。服务端校验通过。

B. 在 OAuth 流程中，redirect_uri 参数用于指定登录成功后的回调地址 。如果该参数存在 Open Redirect，且缺乏 state 参数的严格校验（或存在 CSRF），会导致登录的授权码authorization_code 被劫持。

构造示例：https://victim.com/oauth/login?client_id=xxx\&redirect_uri=https://evil.com/callback
效果：通过对 evil.com 站点的配置，可以使用户继续跳转回信任站点，从 evil.com 的日志中截获授权码，从而劫持用户帐号。

2. 与SSRF的组合：突破限制策略

站点为了防止 SSRF 时会采取策略，只允许请求白名单内的域名。此时，如果白名单内的某个域名存在 URL 跳转漏洞，则可以通过构造的请求绕过 SSRF 防护。

构造示例： https://victim.com/service?url=https://whitelisted.com/redirect?url=http://10.0.0.1/latest/meta-data/
构造效果： SSRF 功能先请求白名单域名，白名单域名返回 302 跳转到内网敏感地址，实现 SSRF 的绕过。

3. 与XSS的组合：绕过XSS的过滤

一些 WAF 或网站在过滤 XSS 时，只检测请求参数中是否包含 <script> 或 alert等关键字，但忽略了 Location 跳转。如果网站存在一个基于 window.location 的跳转漏洞，可以利用跳转执行 XSS。

参考引用

$1$ 《Web漏洞解析与攻防实战》

$2$ OWASP Cheat Sheet Series: https://cheatsheetseries.owasp.org/cheatsheets/Unvalidated_Redirects_and_Forwards_Cheat_Sheet.html

$3$ URL validation bypass cheat sheet *****（绕过技巧）:

https://portswigger.net/web-security/ssrf/url-validation-bypass-cheat-sheet

$4$ https://cloud.tencent.com/developer/article/2183251 （基础实例）

$5$ https://cloud.tencent.com/developer/article/1516344 （进阶实例）

附：白盒代码审计参考

https://cheatsheetseries.owasp.org/cheatsheets/Unvalidated_Redirects_and_Forwards_Cheat_Sheet.html

附：基于 DOM 的 URL 跳转

参考自：

《Web漏洞解析与攻防实战》，P213

https://portswigger.net/web-security/dom-based/open-redirection

类似于反射型 XSS 和 DOM 型 XSS 的区别，URL 跳转漏洞也有服务器端跳转 和 DOM 前端跳转。DOM 类型的前端跳转不经过服务器。用户发送的跳转参数并未到达服务器，而是被前端的 JS 所解析，解析后引发跳转。

基于 DOM 的 URL 跳转漏洞挖掘需要关注网页前端 JS 代码中的关键字：

location
location.host
location.hostname
location.href
location.pathname
location.search
location.protocol
location.assign()
location.replace()
open()
element.srcdoc
XMLHttpRequest.open()
XMLHttpRequest.send()
jQuery.ajax()
$.ajax()