重定向漏洞本质是未校验用户可控输入（如next、redirect_to参数）就直接用于location头或前端跳转，导致开放重定向。关键风险点：登录跳转、oauth回调等场景中，攻击者可构造/login?next=https://evil.com诱使用户跳转钓鱼站；防御须严格白名单校验url，禁用协议切换与跨域跳转，优先使用框架内部路由函数而非原始url拼接。
直接说结论：重定向漏洞不是“重定向本身有问题”，而是你把用户可控的输入（比如 next、redirect_to、return_url 参数）未经校验就拼进 Location 响应头或前端跳转逻辑里——这等于给攻击者开了个任意跳转后门。
为什么 redirect() 或 response.headers['Location'] = user_input 会出事
常见于登录成功后跳转、OAuth回调、表单提交后返回等场景。如果后端代码类似这样：
from flask import Flask, request, redirect
app = Flask(__name__)
<p>@app.route('/login', methods=['POST'])
def login():</p><h1>... 验证逻辑</h1><pre class="brush:python;toolbar:false;">next_url = request.args.get('next', '/')
return redirect(next_url) # ⚠️ 危险！
攻击者只要访问 /login?next=https://evil.com/phish，用户登录后就会被带到钓鱼站。浏览器完全信任这个 Location，且不会提示任何异常。
关键点在于：redirect() 函数本身安全，但它的输入来源不可信。Flask 的 redirect()、Django 的 HttpResponseRedirect、甚至手动设 Location 头，都面临同样风险。
- 不校验时，攻击者可构造开放重定向（Open Redirect），用于钓鱼、绕过 CSRF 保护、提升恶意链接可信度
- 某些框架（如旧版 Django）默认允许相对路径和协议绝对路径，
//evil.com或javascript:alert(1)也能通过 - 前端用
window.location.href = url跳转同理，只要url来自 URL 参数或 API 响应，就需校验
校验 URL 合法性的 3 种可靠方式
核心原则：只允许跳转到本域内路径，或预定义白名单中的可信外部域名（如 OAuth 提供商）。禁止协议切换、跨域、空协议、JS 伪协议。
推荐按优先级使用以下方法之一：
-
用
urlparse拆解 + 白名单比对（最通用）：
检查netloc是否为空（即相对路径），且scheme是''或http/https；再用urljoin归一化后判断是否属于允许范围 -
用
flask.url_for()或django.urls.reverse()构造跳转（最安全）：
完全避开原始 URL 字符串，只接受内部 endpoint 名称和参数，框架自动保证路径合法 -
严格正则匹配（慎用）：
例如^/[\w\-./]*$只允许可见字符的路径，但容易漏掉国际化路径或特殊路由，不推荐作为唯一手段
示例（Flask 场景）：
from urllib.parse import urlparse, urljoin from flask import request, url_for, redirect <p>def is_safe_redirect_url(target): if not target: return False parsed = urlparse(target)</p><h1>只允许相对路径或同域绝对路径</h1><pre class="brush:python;toolbar:false;">return not parsed.netloc or parsed.netloc == request.host
@app.route('/login', methods=['POST']) def login(): next_url = request.args.get('next') if not is_safe_redirect_url(next_url): next_url = url_for('index') # fallback return redirect(next_url)
容易踩的坑：看似校验了，其实没拦住
这些写法在真实项目中高频出错，务必避开：
-
if next_url.startswith('/'):→ 攻击者用//evil.com绕过（双斜杠会被浏览器识别为协议相对 URL） -
if 'http' not in next_url:→javascript:alert(1)、data:text/html,...全部放行 -
if next_url.startswith(request.url_root):→request.url_root可能被X-Forwarded-Host伪造，未校验 header 时不可信 - 只校验一次、不处理重定向链 → 如果你跳转到一个中间页，而它又跳到恶意站，那你的校验毫无意义
特别注意：如果你的应用部署在反向代理后（如 Nginx），request.host 和 request.url_root 可能不准确，应优先从 Host 请求头 + 白名单域名列表做比对，而非依赖动态生成值。
复杂点在于前后端协同与第三方集成
单纯后端校验还不够。比如：
- 前端 Vue/React 路由用
router.push(userInput)，必须同步做路径白名单检查（不能只靠后端） - OAuth 回调地址（
redirect_uri）必须在注册应用时预设，且服务端比对必须严格等于注册值（不允许子路径通配） - 某些 CMS 或低代码平台允许用户配置“登录后跳转页”，这种字段入库前就要走 URL 校验逻辑，而不是等到渲染时才查
最易被忽略的是：**所有跳转入口都要覆盖，包括错误页、登出页、密码重置页、甚至 404 页面里的“返回首页”链接**——只要 URL 来源含用户控制成分，就得过一遍校验逻辑。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
