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

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

编译：代码卫士

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

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

6、 Web 缓存欺骗

该漏洞探索的是 web 缓存功能配置的漏洞。有时当 web 缓存仅根据其扩展决定是否缓存页面时，攻击者久可滥用该功能在应用程序上查看敏感信息。

按照缓存最佳实践，缓存的文件通常是公开的、静态的且不包含任何敏感信息如样式表、JavaScript 文件和公开镜像。另一方面，包含敏感或用户特定信息如账户或钱包详情的文件并未缓存。

要检测文件是否缓存，可观察响应标头。例如，如果该应用程序使用了 Varnish 缓存，则由反向代理缓存的任意文件将在响应中包含 Age 标头，而该响应的值则说明距离文件上次缓存过去的时长。

由于敏感文件从未缓存，因此profile.php这样的敏感文件会在响应中返回 Age:0。然而，公开的 JavaScript 文件如 test.js 可能具有更大的 Age 值。

路径混淆

路径混淆指的是构建如下 URL：

根据服务器的技术和配置不同，很有可能该 URL 的nonexistent.js 部分被忽视而响应包含 profile.php 的内容，同时浏览器中的URL 仍然是：

如之前所述，缓存被配置为保存扩展为 .css、.js、.png 等的文件。因此，当我们请求像之前提到的URL时，该缓存最后将看到 .js 缓存并不管URL的内容如何都将保存该响应。

为进行测试，我们所需要做的就是构建如下 URL：www.example.com/profile.php/nonexistent.js  并确保响应中包含用户的资料数据。

一旦受害者在浏览器中加载该URL，则其敏感数据将被缓存，攻击者仅通过加载同样的URL即可查看（仅在受害者导航至该URL时才能）。

相关论文；https://sajjadium.github.io/files/usenixsec2020wcd_paper.pdf

7、Web 缓存投毒

缓存服务器使用缓存密钥来判断响应是否已经存在于由用户提出的请求的缓存中。最常见的情况是，这些缓存密钥取自 Host 标头以及 HTTP 请求中的请求行。

在这个逻辑下，如果两个请求拥有相同的请求行和 Host 标头，则缓存服务器不考虑其它标头的情况会分配相同的响应。

缓存投毒的目标是在缓存服务器上缓存一个有害的响应，而缓存的方法是如果用户恰巧请求被投毒的端点，则会得到有害响应。

从缓存的立场来看，请求一般具有两种输入类型：

作为攻击者，我们需要将payload 注入unkeyed 输入中，以便被缓存服务器忽略但仍然会被存储在响应中。

为了在请求中找到unkeyed 标头，我们可使用 BurpSuite 上的 Param Miner 扩展并使用选项“猜测标头“。

具有和攻击者相同 keyed 输入的用户将收到由该攻击者存储的恶意响应。

查找缓存投毒漏洞需要通过如下步骤：

8、 h2c Smuggling

这种攻击利用代理的行为，同时升级HTTP/1.1 和h2c 的连接。利用的结果将使我们绕过代理背后应用程序的访问控制。

相关文章：https://labs.bishopfox.com/tech-blog/h2c-smuggling-request-smuggling-via-http/2-cleartext-h2c

h2c 是什么？

h2 表示的是按照TLS使用时的HTTP/2。而h2c 指的是按照明文TCP连接使用时的HTTP/2。

要升级已有的和h2c 的HTTP/1.1 连接，我们使用由HTTP/1.1 协议提供的Upgrade 标头，并以值：Upgrade:h2c 发送。

当客户端发送标头为 Upgrade:h2c 的 HTTP/1.1 请求时，服务器会以状态码 101 Switching Protocols 响应。

和 Upgrade 标头一起，该客户端还需要发送 HTTP2-Settings 和 Connection 标头。这就是升级 h2c 连接时的简单请求的样子：

HTTP2-Settings 标头的值时Base64 编码的字符串，包含HTTP/2 连接参数。

HTTP/2 文档指出，h2c 升级仅允许在明文连接上显示，而 HTTP2-Settings 标头不应转发。cURL、BurpSuite 和其它 HTTP/2 客户端因此不允许按照 TLS 协议升级。然而，定制化客户端可用于测试该漏洞。

漏洞

当 app 使用代理时，升级至h2c 的情况如下：

使用代理升级至 h2c 的问题产生，原因是客户端和服务器之间建立 h2c 连接后，代理不再监控二者之间的通信内容。它意味着可通过直接请求h2c连接上受限端点的方法绕过该使用代理的应用程序执行的任何访问控制。例如，如果某款应用程序限制低权限用户（攻击者）访问 /payment 端点，则攻击者可建立 h2c 连接并成功访问 /payment 端点。

9、次级子域名接管

当某种配置不当类型可使用户控制域名时，就会发生子域名接管问题。比如，当使用AWS S3 服务托管网站且S3实例在没有删除 DNS 记录的情况下被终止时就会发生这种情况。一旦子域名处于这种状况，攻击者就能够设置和此前被终止的S3存储桶一样名称的S3存储桶，控制托管在该域名上的内容（并捕获HTTP访问日志）。由于易受攻击的组织机构仍然有指向该 S3 存储桶的 DNS 记录，因此攻击者就能够在由它们拥有的子域名上托管任意内容。

当被接管的域名被主域名以某种方式引用时，就会发生次级子域名接管情况。例如，我们的目标是 example.com。该域名托管的网站加载了一个外部脚本如<script src="https://assets.dodgycdn.com"></script>。

在这种情况下，如果 assets.dodgycdn.com 易受子域名接管影响，则我们称之为 “example.com 上的次级子域名接管“。查找子域名接管的多数人不检查次级子域名接管问题，因为它需要实时额外的步骤。流程如下：

1、通过HTTP爬取页面

2、提取指向其它域名（脚本来源、图像来源等）的任意引用

3、检查子域名接管的所有结果

影响

次级子域名可能会以不同的方式造成重大安全影响：

10、postMessage 漏洞

浏览器的同源策略限制来源不同的两个窗口或框架相互通信。然而，有时web 应用需要嵌入来源不同的内联框架或打开来源不同的新窗口，如在应用程序上嵌入第三方通讯录。

在这种情况下，由于父（主应用程序）和子窗口的来源不同，同源策略不允许它们相互通信，除非通过使用 JavaScript 的 postMessage()函数，而该函数允许在两个窗口之间发送信息。

如果 postMessage() 未安全实现，则可导致多种漏洞问题，使得攻击者能够向窗口发送任意消息或者从窗口接收敏感数据。如下是这两种情况下的易受攻击代码。

发送者来源未验证

在理想情况下，安全的子窗口应该具有 if 语句，用来验证消息发送者匹配可信来源：

然而，如果未执行该验证，则会给受攻击者控制的应用程序留下向子窗口发送恶意数据如 XSS payload 的空间。

从父窗口向子窗口发送消息的一个例子是，app 打开通讯录表单的新窗口并在子窗口预先填充用户的个人信息。如果该实现易受攻击，则作为猎手的目标就是通过向包含通讯录表单的子窗口发送恶意消息。

目标来源未指定

postMessage() 甚至允许从子窗口将消息发回给父窗口。在这种场景下，如果子窗口将通配符 (*) 指定为消息目的地的来源，则攻击者将能够捕获由子窗口发送的敏感数据：

从子窗口向父窗口发送消息的例子是当 app 打开新的登录窗口并成功登录后，将会话数据发送给父窗口。

如果该实现易受攻击，则作为猎手的目标就是托管攻击者网站，从之前提到的登录页面中窃取用户的会话数据。

记得在鲜有人知的地方找漏洞

不管你是漏洞猎手还是安全践行者，都要查找 OWASP Top 10 漏洞以外的常被错过的 web 漏洞。如果你在看其他人不关注的地方，那么你就可能挖到金砖。