Open Redirect漏洞的本质是用户可控的重定向目标未校验：当应用通过next、redirect_uri等参数接收外部输入并直接用于跳转，且未用urlparse()解析校验scheme和netloc时，攻击者可构造//evil.com等恶意地址实施钓鱼。
Open Redirect漏洞的本质是啥？
它不是你代码里写了redirect()就自动中招，而是当用户能控制重定向目标（比如通过next、return_url等参数），且后端没做校验时，攻击者就能把用户引向钓鱼页或恶意站点。典型错误是直接拼接用户输入：return redirect(request.args.get('next'))。
- 重定向目标必须来自可信来源，不能无条件信任
next、url、redirect_uri等参数 - 即使参数看起来是“/login”或“/dashboard”，也要防相对路径绕过（如
//evil.com或/\x00javascript:alert(1)） -
urlparse()解析后必须检查scheme为空或为''，且netloc为空——否则就是外部地址
如何安全地白名单校验重定向地址？
最稳妥的做法是只允许站内路径（不带协议和域名），再用urlparse()剥离并验证。
from urllib.parse import urlparse
<p>def is_safe_redirect_url(url, allowed_hosts={'localhost:5000', 'myapp.com'}):
if not url:
return False
parsed = urlparse(url)</p><h1>允许空scheme + 空netloc → 表示是相对路径，如 '/profile' 或 '../admin'</h1><pre class="brush:php;toolbar:false;">if not parsed.scheme and not parsed.netloc:
return True
# 若有 netloc，必须在白名单内，且 scheme 必须是 http/https
if parsed.scheme in ('http', 'https') and parsed.netloc in allowed_hosts:
return True
return False
-
allowed_hosts必须显式列出生产环境的域名（不含www.或http://前缀） - 不要用
url.startswith('/')判断——它拦不住//attacker.com（双斜杠会触发协议相对URL） - Django 用户别依赖
is_safe_url()默认行为：它默认只校验ALLOWED_HOSTS，但若settings.SECURE_SSL_REDIRECT=True且请求是 HTTP，可能漏判
Flask 和 FastAPI 的常见修复写法
Flask 中别直接用request.args.get('next')，改用封装函数：
立即学习“Python免费学习笔记（深入）”；
from flask import request, redirect, url_for
<p>next_url = request.args.get('next', '')
if is_safe_redirect_url(next_url):
return redirect(next_url)
return redirect(url_for('index'))
FastAPI 更需注意：Query 参数默认不校验，RedirectResponse 会原样跳转：
from fastapi import Query, Response
from starlette.responses import RedirectResponse
<p>@app.get("/login")
def login(next: str = Query("")):
if is_safe_redirect_url(next):
return RedirectResponse(next, status_code=303)
return RedirectResponse("/home", status_code=303)
- FastAPI 的
RedirectResponse不会自动 URL decode，所以%2F%2E%2E%2Fevil这种编码要先urllib.parse.unquote()再校验 - Flask 的
url_for()生成的链接天然安全，但别把它和用户输入混在一起拼接
为什么用正则匹配域名反而更危险？
有人写re.match(r'^/.*$', url)或url.startswith('/') and '//' not in url，这都不可靠：
-
/\njavascript:alert(1)在某些浏览器仍可执行（换行符绕过） -
///evil.com会被urlparse()识别为 netloc，但正则可能漏掉 - 白名单必须基于解析后的
parsed.netloc，不是字符串前缀匹配
真正关键的防线只有两条：一是用urlparse()拆解，二是严格比对 netloc 是否在预设集合里。其他所有“看起来像站内”的启发式判断，都会在边界 case 上崩掉。
