Apache Tomcat Csrf 令牌泄露漏洞

跨站点请求伪造 (CSRF) 是一种攻击类型，当恶意网站、电子邮件、博客、即时消息或程序导致用户的 Web 浏览器在用户当前所在的受信任站点上执行不需要的操作时，就会发生这种攻击认证。

1.简介

远程 Apache Tomcat Web 服务器受到 Manager 和 Host Manager 应用程序的索引页面中的信息泄露漏洞的影响。未经身份验证的远程攻击者可以利用此漏洞在请求 /manager/ 或 /host-manager/ 时发出重定向期间获取有效的跨站点请求伪造 (XSRF) 令牌。攻击者可以利用此令牌构建 XSRF 攻击。

2. XSRF 解释

远程用户可以绕过目标系统上的安全控制。远程用户可以获得有关目标系统的潜在敏感信息。远程用户可以劫持目标用户的会话。

由于对 Web 应用程序根的未经身份验证的请求而发出重定向时，管理器和主机管理器应用程序的索引页面包含一个有效的 CSRF 令牌。如果攻击者可以访问 Manager 或 Host Manager 应用程序（通常这些应用程序只能由内部用户访问，而不是暴露在 Internet 中），则攻击者可以使用此令牌来构建 CSRF 攻击。

2.1 易受攻击的系统

• 7.0.67 之前的 Apache Tomcat 7.x。
• 8.0.31 之前的 Apache Tomcat 8.x。
• 9.0.0.M2 之前的 Apache Tomcat 9.x

2.2 免疫系统

• 7.0.67 之后的 Apache Tomcat 7.x
• 8.0.31 之后的 Apache Tomcat 8.x
• 9.0.0.M2 之后的 Apache Tomcat 9.x

3. 一个例子

1. 系统管理员连接到 Tomcat 管理器应用程序。
2. 管理员将 Tomcat 管理器留在打开的选项卡中，并在打开了 Tomcat 管理器会话的同一浏览器中浏览 Web。
3. 浏览网页时，其中一个网站含有恶意代码，可诱使浏览器向 Tomcat 管理器发出请求。
4. Tomcat Manager 的管理员会话尚未过期，
5. Tomcat 授予恶意代码访问请求。

为此，攻击者必须知道 Tomcat 管理器应用程序的完整 URL。

4. CSRF 的影响

成功的 CSRF 漏洞利用的影响因每个受害者的权限而异。当针对普通用户时，成功的 CSRF 攻击可能会危及最终用户数据及其相关功能。
如果目标最终用户是管理员帐户，则 CSRF 攻击可能会危及整个 Web 应用程序。在 Tomcat 的特殊情况下，成功的 CSRF 攻击会危及整个 Tomcat 实例，因为管理器可以管理在这些 Tomcat 实例中运行的所有应用程序。

5. 自动化 CSRF 防御的一般建议

5.1 使用标准头验证同源

此检查有两个步骤：

确定请求的来源（来源来源）。
确定请求的来源（目标来源）。

这两个步骤都依赖于检查 HTTP 请求标头值。尽管使用 JavaScript 从浏览器中欺骗任何标头通常很简单，但在 CSRF 攻击期间，通常不可能在受害者的浏览器中这样做。
更重要的是，对于推荐的同源检查，JavaScript 无法设置许多 HTTP 请求标头，因为它们位于“禁止”标头列表中。只有浏览器本身才能为这些标头设置值，使它们更值得信赖，因为即使是 XSS 漏洞也不能用来修改它们。

这里推荐的 Source Origin 检查依赖于其中三个受保护的标头：Origin、Referer 和 Host，这使得它本身就成为一个非常强大的 CSRF 防御。

识别源头

5.1.1 检查源头

如果存在 Origin 标头，请验证其值是否与目标源相匹配。引入了 Origin HTTP 标头标准作为防御 CSRF 和其他跨域攻击的方法。与 Referer 不同，Origin 标头将出现在源自 HTTPS URL 的 HTTP 请求中。如果存在 Origin 标头，则应检查它以确保它与目标原点匹配。

在某些情况下，Origin 标头不存在，其中一种情况是遵循 302 重定向跨域。在这种情况下，重定向请求中不包含源，因为这可能被视为您不想发送到其他源的敏感信息。但是由于我们建议拒绝没有 Origin 和 Referer 标头的请求，这没关系，因为没有 Origin 标头的原因是因为它是跨域重定向。

5.1.2 检查Referer Header

如果 Origin 标头不存在，请验证 Referer 标头中的主机名与目标源匹配。检查Referer是在嵌入式网络设备上防止CSRF的常用方法，因为它不需要任何每个用户的状态。当内存不足或服务器端状态不存在时，这使得Referer 成为预防CSRF 的有用方法。这种缓解 CSRF 的方法也常用于未经身份验证的请求，例如在建立会话状态之前发出的请求，该会话状态需要跟踪同步令牌。

在这两种情况下，只要确保目标原点检查是强的。例如，如果您的网站是“site.com”，请确保“site.com.attacker.com”没有通过您的来源检查（即，匹配来源之后的尾随 / 以确保您与整个起源）。

当 Origin 和 Referer 标头都不存在时该怎么办？

如果这些标头都不存在，这应该是非常罕见的，您可以接受或阻止请求。我们建议阻止，特别是如果您不使用随机 CSRF 令牌作为您的第二次检查。您可能希望在这种情况发生一段时间后记录下来，如果您基本上从未看到它，请开始阻止此类请求。

5.2 识别目标原点

您可能认为确定目标原点很容易，但通常并非如此。第一个想法是简单地从请求中的 URL 中获取目标来源（即，它的主机名和端口号）。但是，应用程序服务器经常位于一个或多个代理之后，并且原始 URL 与应用程序服务器实际接收的 URL 不同。如果您的应用程序服务器由其用户直接访问，那么在 URL 中使用源就可以了，一切就绪。

在代理后确定目标来源

如果您使用代理，则需要考虑多种选择：

• 配置您的应用程序以简单地了解其目标来源
• 使用 Host 标头值
• 使用 X-Forwarded-Host 标头值

它是您的应用程序，因此您可以清楚地找出它的目标来源并在某些服务器配置条目中设置该值。这将是最安全的方法，因为它定义了服务器端，因此是受信任的值。但是，如果您的应用程序部署在许多不同的地方，例如，开发、测试、QA、生产和可能的多个生产实例，这可能会导致维护问题。为每种情况设置正确的值可能很困难，但如果你能做到，那就太好了。

如果您更喜欢应用程序自行解决问题，因此不必为每个部署的实例进行不同的配置，我们建议使用 Host 系列标头。Host 标头的目的是包含请求的目标来源。但是，如果您的应用服务器位于代理后面，则 Host 标头值很可能被代理更改为代理后面 URL 的目标源，这与原始 URL 不同。此修改后的 Host 标头来源与原始 Origin 或 Referer 标头中的源来源不匹配。

但是，还有另一个名为 X-Forwarded-Host 的标头，其目的是包含代理收到的原始 Host 标头值。大多数代理将在 X-Forwarded-Host 标头中传递原始 Host 标头值。因此，该标头值很可能是您需要与 Origin 或 Referer 标头中的源源进行比较的目标源值。
验证两个原点匹配

一旦您确定了源来源（来自 Origin 或Referer 标头），并且您已经确定了目标来源，但是您选择这样做，那么您可以简单地比较这两个值，如果它们与您不匹配知道你有一个跨域请求。

6.解决方案

最好的解决方案是迁移到安全的 Tomcat 版本。Tomcat Manager 可以通过使用令牌来保护自己免受这些类型的攻击。从身份验证请求开始，浏览器会收到一个特殊令牌，必须在下一个请求中提供该令牌。每个后续响应都会为以下请求提供一个新令牌。在这种情况下，当攻击者发送请求时，虽然它会到达服务器，但它不会包含正确的令牌，因此服务器会拒绝请求并阻止攻击。

作为管理员，当您完成已验证会话的工作时，只需关闭浏览器或注销应用程序，这样就不会存在可被利用的已验证会话。