私有缓存如何导致大规模账户劫持——渗透测试案例
在许多情况下，轻微漏洞在网络安全威胁的广阔海洋中可能看起来微不足道。它们通常被标记为低严重性，因此被开发人员忽视，他们认为利用这些漏洞的条件太复杂而无法满足。然而，在本文中，我们将挑战这一假设，并向您展示如何将几个“轻微”漏洞串联起来，导致大规模账户劫持。
让我们先解释一些技术术语：
漏洞链：可以将其视为多米诺骨牌效应。多个连接的漏洞可以累积成一个严重的漏洞。一个典型的例子是反射型跨站脚本（XSS）攻击。单独来看，它通常被认为是中等严重性。然而，当与没有适当安全标志的cookie结合时，它可以升级为账户劫持。
缓存机制：开发人员使用此机制将数据存储得“更接近”用户，从而防止他们直接从数据库加载数据。这种机制节省了大量资源，特别是当数千用户同时活跃时。缓存可以单独设置或在用户之间共享。
应用程序功能：这些是为增强用户体验而添加到应用程序中的功能。例如，当您在搜索引擎中键入一个单词时，它会为下一个单词提供建议，例如“最有趣的…”、“最迷人的…”等等。
那么，测试的应用程序出了什么问题？为什么大规模账户劫持是一个真实场景？
在应用程序审计期间，我们的测试方法之一涉及识别应用程序参数并监控它们在应用程序环境中的行为。想象一个名为SEARCH的参数。自然地，我们会检查此参数是否容易受到SQL注入、XSS、服务器端请求伪造（SSRF）、服务器端模板注入（SSTI）等攻击。我们从一个基本的反射值检查开始。
审计员向服务器发送SEARCH参数的TEST值。
请求：
|
|
响应：
|
|
如果应用程序在响应体中返回TEST值，这对审计员来说是重要信息（在黑盒测试中，审计员不知道应用程序处理哪些参数——我们正在学习应用程序如何工作，黑客在真实攻击场景中会如何行为）。现在是测试更高级负载的时候了，例如：
|
|
让我们看看应用程序的行为。
请求：
|
|
响应：
|
|
一切似乎都正常。SEARCH参数似乎被清理了，因此审计员转向另一个参数。然而，故事发生了意想不到的转折。如果重复完全相同的请求会发生什么？
重复相同负载的请求。
请求：
|
|
响应：
|
|
为什么应用程序会这样行为，如果第一次响应正确清理，但第二次允许任意JavaScript代码执行？这是由于损坏的缓存机制。在测试的应用程序中，缓存机制为每个用户单独工作，使得不可能为所有用户污染缓存。那么这如何被利用呢？
示例1 – 窃取敏感用户cookie： 要窃取敏感用户数据如会话cookie，必须满足两个条件。首先，应用程序中必须存在XSS（跨站脚本）漏洞，其次，cookie标志不能设置为HttpOnly。在测试的应用程序中，这两个条件都没有满足，因为应用程序参数被清理了，并且cookie设置了适当的标志。但有两件事出了问题。缓存机制允许绕过清理，如果至少发送两个相同的请求到应用程序，不幸的是，响应体包含一个带有会话cookie的对象。
示例2 – 窃取许多用户的敏感cookie： 在示例1中，有必要针对潜在受害者并说服他们点击链接两次或访问恶意网站。如今，对这种类型攻击的意识非常普遍，因此欺骗某人进入这种场景可能具有挑战性。应用程序还有一个功能，在搜索引擎中建议短语。通过用恶意建议污染搜索引擎，可能实现大规模XSS执行，导致大规模账户劫持。
两个独立的问题，缓存机制允许绕过清理和响应体包含带有会话cookie的对象，累积成一个严重的问题。应用程序还有一个功能，在搜索引擎中建议短语。通过用恶意建议污染搜索引擎，可能实现大规模XSS执行，导致大规模账户劫持。
总之，不要低估轻微漏洞至关重要。当结合时，它们可以升级为严重的安全威胁。本文强调了考虑所有可能漏洞的重要性，无论它们单独看起来多么微不足道。预防、彻底测试和主动缓解策略对于保护您的应用程序及其用户至关重要。
作者：Mateusz Kowalczyk 标签：缓存, 黑客, 漏洞, XSS