开放重定向高危点包括：1. meta refresh 标签 content 属性拼接用户输入；2. JavaScript 中 window.location 直接赋值 URL 参数；3. 表单 action 和 a 标签 href 动态渲染未校验。
检查 meta refresh 标签是否动态拼接用户输入
HTML 中的 <meta http-equiv="refresh"> 是开放重定向的高发位置。只要它的 content 属性里包含未经校验的参数值，就可能被利用。
常见危险写法示例：<meta http-equiv="refresh" content="0; url=<%= request.getParameter("next") %>"> 或 <meta http-equiv="refresh" content="1;url=${param.redirect}">。
实操建议：
- 用浏览器开发者工具查看页面源码，搜索
<meta+refresh+url= - 抓包后修改参数（如
next=https://evil.com），观察是否跳转到外部域名 - 注意 URL 编码绕过：尝试传
%2f%2fexample.com（双斜杠）或https:%2f%2fevil.com（协议混淆） - 某些服务端会过滤
http://，但放行//example.com—— 这是相对协议写法，浏览器仍会按当前协议加载
审计 JavaScript 中 window.location 的赋值逻辑
前端直接用 window.location.href、window.location.replace() 或 window.location.assign() 接收 URL 参数，是最典型的 DOM 型开放重定向场景。
立即学习“前端免费学习笔记（深入）”；
常见风险模式：
-
const url = new URLSearchParams(location.search).get('redirect');→window.location.href = url; location.href = getQueryParam('to') || '/home';- 从
location.hash或document.referrer提取并跳转
实操建议：
- 在开发者工具的
Sources面板全局搜索location.href =、.replace(、.assign(、document.location - 关注所有从
location.search、location.hash、URLSearchParams获取的变量 - 测试时手动改参，比如把
?redirect=/admin改成?redirect=//evil.com或?redirect=javascript:alert(1)（后者可能触发 XSS） - 注意前端路由框架（如 Vue Router）的
router.push()若接收用户输入且未校验，也可能被绕过
识别表单 action 和 a 标签 href 的动态渲染
虽然不如前两者常见，但 <form action="..."> 和 <a href="..."> 若由服务端模板或前端 JS 动态生成，且目标地址来自用户参数，同样构成开放重定向入口。
典型线索：
-
<form action="${param.target}">（JSP/Thymeleaf） <a href="">- React/Vue 组件中
:href="queryParams.next"未做白名单校验
实操建议：
- 查看页面 HTML 源码，定位所有
action=和href=值含${、、<code>v-bind:、{{等模板语法的位置 - 构造参数使输出变成
href="//evil.com"或action="https://evil.com/stolen" - 特别留意“分享”“跳转到原页面”“返回上一页”等按钮，这类功能常依赖
Referer或returnUrl参数 - 如果
href值最终是javascript:void(0)或#，说明做了基础防护；若直接拼接用户输入，则风险极高
绕过常见过滤时优先试双斜杠和协议剥离
很多站点对 http:// 或 https:// 做了简单字符串匹配过滤，但忽略了 URL 解析器的兼容行为。浏览器对 //evil.com、\evil.com、http:/evil.com 等写法仍会当作合法 URL 处理。
实操建议：
- 先试最简绕过：
?url=//evil.com、?url=\evil.com、?url=//evil.com - 再试协议混淆：
?url=https:%2fevil.com、?url=http:%5c%5cevil.com - 若过滤了
@，可试http://good.com@evil.com（部分旧服务端解析会取 @ 前部分，但浏览器跳转取 @ 后） - 避免盲目 fuzz：先确认目标是否真在用该参数跳转，再针对性绕过；否则大量无效请求易触发 WAF 或日志告警
// 是协议相对写法；又比如前端做了域名白名单，但没用 URL 构造函数解析，导致 https://trusted.com#//evil.com 被误判为合法。动手前，先看它到底怎么解析 URL。 
