私有缓存如何导致大规模账户劫持 - 渗透测试案例
在许多情况下，轻微漏洞在网络安全威胁的广阔海洋中可能看似微不足道。它们通常被标记为低严重性，因此被开发人员忽视，认为其利用条件过于复杂而难以实现。然而，在本文中，我们将挑战这一假设，向您展示如何将几个"轻微"漏洞串联起来可能导致大规模账户劫持。
让我们先解释一些技术术语：
漏洞链：可以将其视为多米诺骨牌效应。多个相互关联的漏洞可能最终形成一个严重的漏洞。一个典型的例子是反射型跨站脚本(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执行，从而导致大规模账户劫持。
总之，不要低估轻微漏洞至关重要。当它们结合在一起时，可能会升级为严重的安全威胁。本文强调了考虑所有可能漏洞的重要性，无论它们单独看起来多么微不足道。预防、彻底测试和主动缓解策略对于保护您的应用程序及其用户至关重要。