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

实战有效的Web时序攻击技术剖析

news 来源：原创 2025/9/20 16:14:48

倾听低语：实际有效的Web时序攻击 | PortSwigger研究

James Kettle
研究总监
@albinowax

发布时间：2024年8月7日 18:10 UTC
更新时间：2024年11月18日 08:32 UTC

网站中充满了急于泄露其内部秘密的时序预言机。是时候开始倾听它们了。
在本文中，我将释放新颖的攻击概念，以诱出服务器秘密，包括掩蔽的错误配置、盲数据结构注入、通往禁止区域的隐藏路由以及大量不可见的攻击面。

这不是理论威胁；每种技术都将在不同目标上的多个真实案例研究中得到说明。前所未有的进步使这些攻击既准确又高效；在十秒内，您现在可以可靠地检测到亚毫秒级的差异，无需事先配置或“实验室条件”。换句话说，我将分享您可以实际使用的时序攻击。

为了帮助您，我将为您配备一套经过实战测试的开源工具，支持免提自动利用和自定义攻击脚本。我还将分享一个小型CTF，以帮助您磨练新技能。

想进一步深入？我将通过分享在数千个网站上测试无数概念而 refined 的方法论，帮助您将自己的攻击想法从理论转化为现实。我们忽视这种无处不在且极其强大的侧信道太久了。

本研究论文伴随Black Hat USA和DEF CON的演讲：

您还可以以打印友好的PDF格式阅读此白皮书。

大纲

背景
制作随处可用的时序攻击
回答难题
使时序攻击“本地化”
使时序攻击可行
隐藏的攻击面
发现过载
最难的问题
证明概念
服务器端注入
- 盲SQL注入
- 盲JSON注入
- 盲服务器端参数污染
反向代理错误配置
- 范围SSRF
- 防火墙绕过
- 隐藏目的地
- 前端规则绕过
- 前端冒充
研究路线图
防御
要点

背景

Web时序攻击因两件事而臭名昭著：做出大承诺和未能兑现。例子通常是理论性的，即使一种技术被称为“实用”，每个人都知道一旦您尝试在实验室环境之外应用它，它就会停止工作。

这种声誉可能是我们忽略了一个巨大机会的原因。

我首次研究时序攻击的结果坚定地属于“理论”桶。对于我的第二次尝试，我首先回顾了我在野外成功应用的攻击，以及我读到的其他攻击：

从上到下，这些是：

跨站搜索
用户名枚举
潜在竞争条件的探测
实验室验证的攻击
理论攻击，如果它实际工作，那将绝对惊人...

在寻找野外有效的新技术时，我专注于两个类别之间的巨大鸿沟：

时序攻击研究通常专注于单个目标，但这限制了其真实世界价值。我想要可以应用于任意实时目标的技术。为确保我的新攻击概念符合此标准，我在30,000个实时网站的测试平台上验证了它们。基于bbscope和Rapid7的Project Sonar DNS数据库，测试平台是一个20 GB的Burp Suite项目文件，包含每个已知有漏洞赏金计划的网站。

在这项研究之前，我个人利用的最小时间间隙是30,000μs。现在，是200μs。这是通过时序攻击准确性的大幅进步实现的，并实现了多个强大的新技术。

三种关键攻击技术在对各种实时系统提供有价值发现方面脱颖而出：发现隐藏攻击面、服务器端注入漏洞和错误配置的反向代理。在本文中，我将深入探讨每一种。

制作随处可用的时序攻击

所有三种技术现在都在Param Miner中可用，所以，如果您愿意，您可以停止阅读并立即尝试它们。这项研究的真正价值在于理解它不止于此；这些只是可能性的样本。时序攻击几乎可以带您到任何地方，但要掌握这种潜力，我们需要从头开始。

让我们仔细看看现实世界时序攻击生死攸关的关键因素，以及如何克服它们。在本节中，我将展示如何使时序攻击“本地化”、可移植和可行。

回答难题

很容易假设所有Web时序攻击都是漏洞利用，但这是一个错误，因为它限制了您对潜在应用的思考。在其核心，Web时序攻击仅仅是关于回答难题——那些通过观察服务器响应无法回答的问题。

我通过尝试基于时序的密码重置漏洞利用开始了这项研究。它进行得很糟糕，但很好地说明了理论与现实之间的差距。许多网站通过在其数据库中存储秘密令牌并在链接中发送令牌到用户的注册电子邮件地址来实现密码重置。当用户点击链接时，网站将用户提供的令牌与数据库中的令牌进行比较。

在底层，字符串比较通常一次比较一个字符，直到它们完成字符串或遇到不匹配的字符对。这意味着匹配的字符越多，比较所需的时间越长：

在此插图中，我们使用两个HTTP请求来问“数据库是否包含以d7e开头的密码重置令牌？”服务器需要一秒钟来比较每个字符，因此通过比较响应时间，攻击者可以告诉令牌以“d7e”而不是“d7f”开头。

不幸的是，比较每个字符的实际时间大约在5纳秒或0.000000005秒的范围内。祝你好运利用那一点。

噪声与信号

每个时序攻击的成功归结为两个竞争的变量——信号和噪声。信号指的是您想要检测的时序差异的大小，噪声指的是影响响应时序的所有其他因素。如果信号相对于背景噪声太安静，您将听不到它：

对于实际有效的攻击，您需要最大化信号并最小化噪声。本节的其余部分专注于如何做到这一点。

请注意，此方程不包括“测量次数”。您可以尝试通过重复测量来抵消噪声，但这种方法扩展性差。一旦噪声严重超过信号，您将很快需要数十亿次测量，导致攻击耗时如此之长，目标可能在完成之前被停用。

您可以将噪声分为两部分——网络噪声（抖动）和服务器噪声（内部抖动）：

网络抖动是延迟的变化——数据包到达目标系统并返回所需的时间。它是远程时序攻击的经典克星。当有人看到针对本地系统的时序攻击演示并说“那在远程系统上永远行不通”时，他们基本上是在说网络抖动将使攻击不可能。五年前，这可能是真的。

使时序攻击“本地化”

在2020年，Timeless Timing Attacks表明您可以使用HTTP/2完全从测量中消除网络抖动。您可以将两个HTTP/2请求放入单个TCP数据包中，确保它们同时到达服务器。然后您可以查看响应到达的顺序，推断哪个在服务器上处理时间更长：

这一单一发现消除了最大的噪声源，并改变了可检测内容的边界。只是有一个小问题。

粘性请求顺序问题

在HTTP/2层，两个请求完全并发，但底层的TLS数据是流，所以一个请求仍然是“第一个”，即一个将在另一个之前完全解密。如果您尝试此技术，您会注意到网站显示出显著偏向先回答第一个请求。这种偏向可能源于多个因素，包括解密第二个请求所需的时间和资源可用性。不幸的是，这可能掩盖您试图检测的延迟：

作者注意到这个问题，并通过添加虚拟参数来减慢第一个请求的解析来处理它，试图重新同步执行。

使时序攻击可移植

实验室环境以比真实目标噪声少而闻名，但还有第二个更微妙的问题。专注于单个目标通常会产生需要大量调整才能应用于其他任何地方的目标特定技术。这使得它们对于任何有截止日期的人来说价值显著降低。

不幸的是，虚拟参数填充是此问题的一个例子——其有效性取决于目标如何实现参数解析，以及系统在那一刻有多少处理容量可用。由于备用处理容量受其他系统影响，参数填充实际上可能最终增加噪声水平。我在一个实验室系统上观察到需要不同数量的参数，相隔十分钟。

我们真正需要的是解决粘性请求顺序问题的方法，不需要每目标配置。单数据包攻击，我去年为竞争条件发现开发，为此提供了一个良好的起点。单数据包攻击 fragmentation 请求以减少“关键数据包”的大小——完成请求并启动执行的数据包。

它通过在前几个数据包中发送大部分请求来工作，然后使用一个微小的最终数据包完成请求并触发执行。在此图中，最终关键数据包用黑色勾勒：

不幸的是，这引入了不同的陷阱——一些服务器一旦获得标头就开始处理HTTP请求，而不等待正文。要修复那一点，我们需要说服我们的OS网络堆栈将标头帧合并到单个数据包中，以便无论服务器开始处理哪个阶段，两个请求都同时处理：

您可能想知道为什么我选择将请求拆分为仅两个关键数据包，而不是每个HTTP标头一个数据包。那确实理想，但不幸的是HTTP/2 RFC禁止交错来自单独请求的标头帧，所以它不太可能工作。

实现这种双数据包同步结果非常容易——只需添加一个额外的ping帧！这种无害的牺牲数据包确保操作系统合并后续的标头帧。

禁用 TCP_NODELAY
发送一个ping帧
对于每个无正文的请求：
- 发送标头
- 保留一个空数据帧
对于每个有正文的请求：
- 发送标头和除最终字节外的正文
- 保留一个包含最终字节的数据帧
等待100ms
发送一个ping帧
发送最终帧

我们一发现这种改进的技术，就将其集成到Burp Suite的内置单数据包攻击中，所以您可能已经从中受益！我目前正在与开源实现h2spacex的开发人员合作，以将其也纳入其中。

使时序攻击可行

随着网络噪声的出局，我们的下一个目标是服务器噪声。不要低估服务器噪声。它源于众多来源，包括目标服务器上的负载、与之交互的其他系统、在同一物理硬件上运行的其他虚拟系统，以及可能数据中心附近的天气。服务器噪声是我没有对增强单数据包攻击可以检测到什么时间延迟做出任何声称的原因——任何这样的声称都是如此目标特定，以至于实际上毫无意义。

要最小化服务器噪声，采取最短的代码路径 possible，并充分利用性能特性，如缓存、对象重用和连接重用。坚定的攻击者还可能使用DoS技术（如CPDoS和资源消耗）减少来自其他用户的噪声。

要最大化信号，专注于慢代码路径，并通过使用随机输入避免服务器端缓存、尽可能访问慢资源以及乘以工作负载来使其更慢。例如，此请求使用多个具有固定前缀的标头来尝试扩大由服务器寻找以“X-U”开头的标头引起的延迟：

GET / HTTP/1.1  
X-Uaa: a  
X-Ubb: a  
X-Ucc: a  
{256}

现代Web技术，如ORM和GraphQL，也特别适合延迟扩展技术。记住DoS攻击只是一个非常容易的时序攻击，并适应经典技术，如ReDoS、批处理和递归XML实体。

隐藏的攻击面

漏洞经常潜伏在废弃和被遗忘的功能中，被开发人员和安全测试人员 alike 忽视。因此，漏洞发现旅程通常从检测隐藏参数、cookie或HTTP标头开始。

在其核心，发现这些隐藏输入涉及猜测潜在参数名称并观察它们是否改变响应。不改变响应的参数可能保持未被检测，以及任何相关的漏洞。对于我的第一次批量时序攻击，我决定修复这一点。

方便的是，我是Param Miner的核心开发人员——可能是第一个用于批量参数发现的工具。Param Miner使用“字数”、“状态”和“行数”等属性比较响应。对于这项研究，我简单地将“响应时间”添加为额外属性，增加了重复计数，并开始扫描。

我可以让Param Miner使用单数据包攻击进行这些测量，但这将涉及 significant 重构，并且在研究未经验证的概念时，我采取 every possible 捷径以避免浪费时间，所以我没有麻烦。

相反，我只是测量从请求的最后一个字节到响应的第一个字节的时间，并比较两组30次时序测量的下四分位数，看它们是否 distinct（指示有效参数）或重叠。下四分位数是这种比较的理想选择，因为它反映了噪声最少的测量。

发现过载

在30,000个实时站点的测试平台上运行时间增强的Param Miner产生了大量隐藏参数，包括一些非常奇怪的参数。

一个亮点是一个Web服务器，对包含神秘HTTP标头“commonconfig”的请求响应时间延长5ms，除非标头值是有效的JSON：

标头	响应时间
foo: x	HTTP/1.1 200 OK 50ms
commonconfig: x	HTTP/1.1 200 OK 55ms
commonconfig: {}	HTTP/1.1 200 OK 50ms

另一个发现是在一个拒绝响应任何请求的Web服务器上——它总是重置连接。这种极其防御的行为不足以阻止我的扫描发现它支持某个HTTP标头，因为该标头使其花费 significantly 更长的时间来重置连接！有趣，但不是非常有用。

标头	响应时间
foo: x	--连接重置-- 30ms
authorization: x	--连接重置-- 50ms

一个频繁的发现 much more 实用：

请求	响应时间
GET /?id=random HTTP/1.1	200 OK 310ms
GET /?foo=random HTTP/1.1	200 OK 22ms

这对响应告诉我们两件有价值的事情。首先，该站点仅将特定参数如“id”包含在缓存键中，因此它高度暴露于基于参数的缓存中毒攻击。第二，我们知道“id”参数被键控，并且这种配置通常是站点范围的。这意味着使用时间分析，Param Miner检测到了一个适用于不同页面的参数！

最难的问题

当我尝试这个概念时，我 anticipated 两个问题。首先，我预计许多技术会完全失败。第二，我怀疑我遇到的任何有效结果都会隐藏在大量误报中。

最大的挑战来自 neither。是时序攻击太强大。它们可以检测到如此之多，以至于 incredibly 容易误解您检测到的内容。它们 incredibly 擅长检测“某物”，但那个某物不一定是您试图检测的。完美地说明了这一点。这种参数检测乍一看像RCE，然后结果是完全不同的东西（但仍然有用）。

此视频显示最初看起来像潜在的远程代码执行漏洞，因为“exec”参数导致可见的响应延迟。这种延迟结果是一个WAF对更可疑请求进行额外处理的指标。然后我们看到当参数重复时延迟叠加，除非请求正文超过某个大小阈值。最终这导致发现完整的WAF绕过。这种绕过发现对我来说 completely 意外，但此后已被其他人发现，并现在在nowafpls工具中实现。它仍然是时间分析如何揭示目标控制流洞察的一个美丽演示。

那是简单的情况之一——有时您可能永远无法完全理解您检测到的内容。轻装携带您的假设，并尽可能从不同角度测试它们。

证明概念

为避免被错误假设误导，我决定专注于提供明确安全影响的特定参数，无需任何耗时的手动调查，并有直接的方式收集额外的确证证据。

通过HTTP标头的IP地址欺骗完美满足了这些要求。这是一个相对常见的错误配置，并直接启用各种漏洞利用，包括速率限制绕过、伪造日志，甚至在某些情况下的访问控制绕过。通过将IP地址放在欺骗的前端标头中，您有效地冒充前端。我们将在后面更深入地探讨前端冒充攻击。

方便的是，如果您将域放在欺骗标头中，易受攻击的服务器通常会执行带内DNS查找来解析它，导致 easily 可检测的延迟。这是一个典型的检测：

标头	时间
Random-header: xyz.example.com	65ms
True-Client-IP: xyz.example.com	70ms
True-Client-IP: xyz.example.com	65ms

第一个响应快速返回，因为它不触发DNS查找。第二个响应触发对xyz.example.com的DNS查找，所以它更慢，第三个响应更快到达，因为DNS响应已被缓存：

我们将在后面重新讨论DNS缓存。总共，扫描IP地址欺骗揭示了：

375个易受攻击的域
其中206个还导致DNS回显
217个 visibly 缓存了结果

这可能让您想知道大约170个没有导致DNS回显的易受攻击域——它们是误报吗？这是一个例子：

标头	时间
Random-header: x.psres.net	170ms
True-Client-IP: x.psres.net	90ms
True-Client-IP: 1.1.1.1	170ms

您认为这里发生了什么？

这是一个线索——在您的登录历史中，网站指定了登录IP地址和位置：

时间	浏览器	IP	位置
5分钟前	Chrome in Windows	1.1.1.1	Cloudflare

我认为这个系统正在将欺骗的IP地址传递到库中，该库在将其传递给第三方地理查找服务之前验证格式。提供无效IP地址如“x.psres.net”导致异常，并阻止慢速IP查找发生：

所以，我们获得了一种新的参数发现技术，证明了时序攻击可以在野外大规模工作，并且还发现了重要的东西：触发错误的输入可以 shortcut 大代码路径，并导致 significantly 更快的响应。换句话说，时序攻击 exceptionally 擅长检测异常。

服务器端注入

触发和发现异常是从SQLi到OS命令注入的服务器端注入漏洞测试的基础部分。这使得时序分析成为服务器端注入检测的完美匹配。

我试图通过将“时间”添加为响应属性到Backslash Powered Scanner来复制我在Param Miner中的成功，但这失败了。没有单数据包攻击，我只能检测主要的时间差异，而这些主要来自WAF而不是真实漏洞。此外，工具的复杂性使其难以适应以克服挑战。

对于我的第二次尝试，我重用了Param Miner的一些代码来构建一个更简单的测试，使用单数据包攻击。我每个探测发出最多50个请求对，并记录每对的响应顺序。如果响应顺序至少80%偏向一个有效负载，我将其报告为有效发现。

完全盲SQLi

第一个发现是一个完全盲SQL注入，用经典的有效负载对检测到：

请求	响应时间
GET /api/alert?mic=' {}	162ms
GET /api/alert?mic='' {}	170ms

不幸的是，当我报告时，结果是一个重复。回想起来，我应该看到这一点——您可以使用众所周知的“||sleep(5)||”有效负载 easily 检测相同的漏洞。高级时序分析根本不需要检测您可以注入sleep语句的漏洞。同样，时序对于查找代码注入并不 great，因为您通常可以通过使用OAST技术更好地找到那些。

对于强大的漏洞，如命令注入、SQLi和代码注入，基于时序的检测只有在您有WAF或过滤阻止经典检测技术时才真正有用。让我们看其他地方。

盲JSON注入

时序在寻找注入底层时发挥作用；允许操作数据结构和格式但停止 short 完全代码执行的漏洞。这包括注入到格式如JSON、XML、CSV以及服务器端查询参数和HTTP标头中。许多这些错误很少被谈论，因为它们很难检测。

它们也很难利用，但有时您可以将时序信息与可见特征结合，以获得对幕后发生的事情的额外洞察。例如，我发现一个目标，其中无效的JSON转义序列使响应返回快200us（0.2ms）：

参数	响应时间
key=a"bb	"error": { "message": "Invalid Key: a"bb"} 24.3ms
key=a"\bb	"error": { "message": "Invalid Key: a"\bb"} 24.1ms

您认为服务器端发生了什么？

响应格式中有一个线索——我们注入的无效语法没有改变响应中的格式。我期望JSON格式化程序在运行无效语法时失败，或至少返回 visibly 不同的输出。

此外，冗长的输入在响应中被编辑：

参数	响应时间
key=aaa…a"bbb	"error": { "message": "Invalid Key: ****bbb"} 24.3ms

此特性提供了第二个线索：当我们的无效JSON序列被编辑时，时序差异消失了！ together，这强烈表明延迟是由于解析发送给我们的响应的组件发生的。我的最佳猜测是它是某种错误记录系统。我从0.2ms的时间差中弄清楚这一点相当高兴，但没有明确的利用路径，我决定继续前进。

盲服务器端参数污染

我最多产的探测是针对盲服务器端参数污染。这通过比较保留URI字符如?和#与非保留字符如!的响应时间来工作。

在某些情况下，发送编码的#使响应返回更快：

请求	响应时间
/path?objectId=57%23	Can't parse parameter 180ms
/path?objectId=57%21	Can't parse parameter 430ms

这可能是由于片段破坏了服务器端路径并从后端获得快速的静态响应，或应用程序的HTTP客户端 simply 拒绝发送包含原始#的HTTP请求。当然，关键不是假设延迟将如何落地——在其他目标上，编码的#使响应到达更慢。

服务器端参数污染是注入发现中最常见的类型， by a huge margin，所以我认为这是一个有前途的进一步研究领域。有关此攻击类的更多信息，请查看服务器端参数污染和Attacking Secondary Contexts in Web Applications。

错误替身

如我们所见，高精度时序 great 用于检测盲注入错误，但它们并不总是容易利用。在分析这些发现时，我经常获得对服务器端发生的事情的一些理解，但停滞 short 实际利用。此外，时序往往浮现我们不太熟悉利用的较不知名攻击类。

仅基于时序证据收集足够信息进行利用通常棘手且耗时。在常规非盲漏洞上测试每个想法通常涉及单个中继器请求，而对于许多这些，您可能面临30秒的Turbo Intruder攻击。

这里可以帮助的一件事是“错误替身”——目标错误类的非盲变体。Param Miner将报告这些，并且它们 great 用于在 less 挑战性的环境中学习如何解释和利用这些错误。

错误替身形成了这项研究中更广泛、 recurrent 主题的一部分。如果您忽略时序，您将错过，但如果您过于专注于时序，您也将错过。为了成功，使用 every available 信息通道。

反向代理错误配置

这项研究中最大的突破是当我意识到我可以使用时序来检测一种被广泛忽视的SSRF类型。

早在2017年，我研究了利用错误配置的反向代理进行SSRF并 gain 访问内部系统的技术。最常见的漏洞是服务器将请求路由到HTTP Host标头中指定的域。为了检测这些，我会向它们发送一个Host指向我控制的域的请求：

GET / HTTP/1.1  
Host: uniq-token.burpcollaborator.net

如果目标易受攻击，我会看到我的请求到达我在burpcollaborator.net的站点，由易受攻击的反向代理转发。之后，我会发送内部IP和主机名以掠夺其内部网络。这产生了一些 spectacular 发现，包括意外黑客攻击我的ISP放置以MITM其客户的系统。

范围SSRF

尽管成功，但这种检测技术有一个主要盲点——范围SSRF。

在我发布研究后，Google的某人问我是否在他们的系统中发现了任何漏洞，强烈暗示他们曾经易受攻击。不久之后，Ezequiel Pereira发布了$10k host header，其中他利用了一个属于Google的开放代理，我未能检测到。我的扫描方法失败，因为Google的代理配置为仅将请求路由到他们自己的系统，所以我的服务器从未收到DNS查找。

这是一个非常常见场景的提示，公司允许请求转发到任意子域：

Host标头	完全SSRF	范围SSRF
random.example.com	404 Not Found	404 Not Found
random.notexample.com	404 Not Found	403 Forbidden

我不认为这种类型的SSRF有 established 名称，所以我将称其为范围SSRF。这种限制可以通过内部DNS服务器、简单的主机名验证、阻止出站DNS的防火墙或紧密的侦听器配置来实现。结果总是相同的——您有一个影响接近完全SSRF的错误，但不能使用回显/OAST技术检测。

检测范围SSRF

要检测范围SSRF，我们需要回答“服务器是否尝试连接到指定的主机名？”时序完美适合此。考虑一个在www.example.com的服务器发出以下响应：

Host标头	响应时间
foo.example.com	404 Not Found 25ms
foo.bar.com	403 Forbidden 20ms

这两个响应显示它正在对Host标头进行某种验证，但没有足够的信息来告诉它是否是一个开放代理。如果您依赖响应内容，您将最终得到误报和漏报。

以下请求对是证明问题的原因——更快的第二个响应是DNS缓存的证据：

Host标头	响应时间
abc.example.com	404 Not Found 25ms
abc.example.com	404 Not Found 20ms

一些DNS系统不缓存失败的DNS查找，但我为此找到了一个替代解决方案——发送过长的64八位字节DNS标签，导致DNS客户端拒绝发出查找和更快的响应：

Host标头	响应时间
aaa{62}.example.com	404 Not Found 25ms
aaa{63}.example.com	404 Not Found 20ms

筛选秘密路由

用这些技术扫描揭示了数百个易受攻击的反向代理，暴露了通往数万个域的替代路由——我 desperately 需要自动化。

当您找到一个开放反向代理时，第一步是尝试使用它访问 every possible 目的地。我编写代码自动编译目标子域列表，使用三个主要来源：

硬编码的通用子域单词列表
来自Rapid7的Project Sonar 'fdns'文件的已知子域列表。为了快速解析此58 GB文件以获取特定目标的子域，我使用'rev'反转每一行，然后按字母顺序排序，以便兄弟域彼此相邻。然后我运行老式unix 'look'实用程序进行二进制搜索。这比grep减少了99.999%的搜索时间。
在线子域服务columbus.elmasy.com， mostly 从证书透明度日志编译

我让Param Miner尝试访问每个主机两次——一次直接，一次通过代理——并报告任何两次访问尝试触发 significantly 不同响应的主机。在比较响应时，我专注于响应状态代码、标头名称和Location标头，因为这些是最高信号区域。这产生了许多发现， fall into 四个 broad 类别。

在Host标头中直接猜测主机名通常被称为“vhost暴力破解”，但反向代理利用 often 看起来 completely 不同，所以理解区别很重要。虚拟主机暴力破解仅提供对同一服务器上其他网站的访问。同时，反向代理将路由请求到不同系统，启用独特攻击，如前端规则绕过、前端冒充和漏洞利用链接机会。让我们深入探讨。

防火墙绕过

最简单的漏洞利用是您可以从外部看到目标但无法直接访问它。

在一个公司，sonarqube.redacted.com解析到一个公共IP地址，但尝试访问它触发来自防火墙的连接重置。我的探测已识别app.redacted.com作为反向代理，并使用它，我能够绕过防火墙并访问内部SonarQube实例。

入口点	Host标头	结果
sonarqube.redacted.com	sonarqube.redacted.com	--重置--
app.redacted.com	sonarqube.redacted.com	200 OK

防火墙绕过 - 不可见路由变体

有一个常见的变体，内部系统没有方便的公共DNS记录让您知道它存在：

有大量预生产、暂存和开发服务器暴露给任何应用此技术的人。如果您幸运，它们将启用调试或配置测试凭据，使它们成为软目标。这些系统甚至可能有真实目标数据，或从生产重用的密钥。

我发现的最有趣的目标是仍在积极开发的预启动系统。特别是，我发现了一个管理控制台， apparently-公共访问在一个非常酷的美国政府系统上，我很沮丧不能提供任何细节。我报告了问题，系统几个月后“上线”，但管理控制台无处可见。

前端规则绕过

一些目标 publicly 可访问，但位于前端服务器后面，强制执行 inconvenient 安全规则，阻止攻击或限制对有价值端点的访问。处理这些的经典方法是通过直接与后端交谈，但这通常由于防火墙而 impossible。

反向代理提供了一个引人注目的替代方案——绕过障碍：

在一个目标上，使用通过反向代理的替代路由将此：
变成此：

前端冒充攻击

最 spectacular 和 surprising 漏洞利用发生在前端和后端之间存在信任关系时。 common knowledge 您可以使用X-Forwarded-For等标头欺骗您的IP地址。 less appreciated 的是这是更广泛和更强大错误类的一部分。这种攻击类型没有 established 名称，所以我将称其为前端冒充攻击。

前端系统通常
更多精彩内容请关注我的个人公众号公众号（办公AI智能小助手）
公众号二维码