如何理解上传Word文件形成存储型XSS路径

如何理解上传Word文件形成存储型XSS路径，相信很多没有经验的人对此束手无策，为此本文总结了问题出现的原因和解决方法，通过这篇文章希望你能解决这个问题。

在渗透测试过程中，每当看到目标测试网站存在上传功能时，总会激起我的好奇心。如果能够走运的话，若目标网站服务器是PHP或ASP架构，而且上传功能没作后缀过滤，这样就能导致可以直接上传反弹脚本形成控制。如果这招行不通，我会尝试上传一个HTML页面去触发我自己设置的客户端javascript脚本形成XSS攻击。我就分享一个上传docx文件形成存储型XSS漏洞的实例。

测试上传功能

刚好在某次Web测试工作中，我发现目标网站上传功能中，用一个未授权用户即可上传自己的文件，该上传功能中允许用户上传.docx文件：当把这种.docx文件上传之后，它还能被下载。通过比较发现，上传成功的文件uploaded.docx和服务器上其对应的可下载文件downloaded.docx之间存在着一些不同，也就是说，文件上传成功之后，在提供下载之前，服务器会对这个上传文件进行一些处理操作，之后，再提供下载。

用来上传的文件必须是一个有效的.docx文件，那基于浏览器的解析显示来说，它可能会把它转换为html格式来显示，那我能不能把它后缀作个更改呢？所以我先来试试在POST请求中把.docx后缀更改为.html看看：

当这个.html文件上传之后，向服务器请求这个文件后，服务器会把其Content-Type头默认为text/html，这样的话，浏览器会把这个文件解析为HTML执行：

插入XSS Payload

这样，我就想到了把XSS Payload捆绑到一个像下图这样的.docx压缩文件中去。由于这是.docx经直接把后缀更改为.zip的压缩格式文件包样例，我需要确定在上传或Web解析过程中某些不会被转储更改的区域，最后，我发现了这种docx变zip压缩格式包中的某些文件路径会保持原样，像下图这样，我把其中的Settings.xml文件名加上了一长串字母好待区分。之后，再把这个zip格式后缀还原为docx格式，用UItraEdit查看hex代码，再在保持原样的区域中覆盖掉一些字节，插入我自己设置的JavaScript XSS代码：

上传时，服务器能正常接收这个经过构造的.docx文件，在HTTP POST过程中，我把它的后缀更改为.html后缀进行了最终上传：向服务器请求这个文件时，它能被服务器解析为HTML文件，其中包含了完整的之前插入的XSS Payload代码：当然浏览器解析之后，也能成功执行其中插入的XSS Payload：为了对这种XSS攻击进行混淆隐蔽，攻击者可以在其中加入一个包含URI统一资源标识符的隐藏iframe框架，能对受害者产生迷惑效果，像下图这样：

防护措施

这样的效果对于开发者来说应该采取以下手段来进行限制。

文件上传之前，在服务器端验证上传文件格式是否为.doc或.docx有效格式；

严格限制Content-Type头，对Content-Type头或特定后缀格式更改过的上传文件须保持与上传文件相同的Content-Type头信息；

控制文件下载时的其它操作情况，添加响应标头:"Content-Disposition: attachment"，以防止在浏览器中内嵌显示文件；

过滤掉所有包含HTML标签的上传，因为docx可经压缩篡改其中包含的HTML文件。

看完上述内容，你们掌握如何理解上传Word文件形成存储型XSS路径的方法了吗？如果还想学到更多技能或想了解更多相关内容，欢迎关注行业资讯频道，感谢各位的阅读！