0

我有一个使用 spring saml 和 Modsecurity 的基于 Java-Servlet 的 Web 应用程序。

对于其中一个 GET 请求（URL - /saml/login），响应是返回为 text/html 的 HTML 页面（我可以在浏览器网络工具中读取 html 文件）以及 Content-Length 标头。这是 Modsecurity 被禁用的时候。

当我在应用程序中启用 ModSecurity 时，将返回相同的响应，并带有标头 Transfer-encoding: chunked。这次 html 响应由于分块而被编码。例如<html显示为10<60h104t116m109l108。我不确定浏览器是否应该对此进行解码，但这破坏了我的应用程序的流程。由于响应以编码形式显示在浏览器上。

我尝试在 ModSecurity 中注释掉规则，以找出导致响应被分块但没有成功的原因。由于另一个开发人员实现了 ModSecurity，此时我不确定如何通过更改 ModSecurity 来解决这个问题。

因此，我想尝试在 Java 代码或浏览器中解码响应。如果 Html 文件渲染正常，后续的请求就会开始工作。

编辑1：

web.xml 中的 ModsecurityFilter 配置：

<filter>
        <filter-name>ModSecurityFilter</filter-name>
        <filter-class>org.modsecurity.ModSecurityFilter</filter-class>
        <init-param>
            <param-name>conf</param-name>
            <param-value>/opt/ModSecurityFilter/modsecurity.conf</param-value>
        </init-param>
        <init-param>
            <param-name>libxml2</param-name>
            <param-value>/usr/lib/x86_64-linux-gnu/libxml2.so.2</param-value>
        </init-param>
        <init-param>
            <param-name>libpcre</param-name>
            <param-value>/lib/x86_64-linux-gnu/libpcre.so.3</param-value>
        </init-param>
        <init-param>
            <param-name>libaprutil-1</param-name>
            <param-value>/usr/lib/x86_64-linux-gnu/libaprutil-1.so.0</param-value>
        </init-param>

        <init-param>
            <param-name>libapr-1</param-name>
            <param-value>/usr/lib/x86_64-linux-gnu/libapr-1.so.0</param-value>
        </init-param>

        <init-param>
            <param-name>libModSecurityJNI</param-name>
            <param-value>/opt/ModSecurityFilter/java/.libs/libModSecurityJNI.so</param-value>
        </init-param>
</filter>
<filter-mapping>
        <filter-name>ModSecurityFilter</filter-name>
        <url-pattern>/*</url-pattern>
</filter-mapping>
4

1 回答 1

0

看来您正在发回 ASCII 代码以及文本。以前从未见过，也不知道为什么 ModSecurity 会这样做。Transfer-Encoding: chunked 是一个标准的 HTTP 响应，服务器和客户端都应该能够处理这个，它不应该改变发回的格式。

看起来您正在使用一些旧的和较旧的 ModSecurity for Java，如下所述：https ://www.trustwave.com/Resources/SpiderLabs-Blog/ModSecurity-for-Java---BETA-Testers-Needed/

我不知道这存在并且它已经超过 4 年没有得到维护，所以说实话不确定它有多稳定。

您可以尝试在上面的页面上添加评论，或者在 ModSecurity 用户邮件列表中寻求帮助：https ://sourceforge.net/projects/mod-security/lists/mod-security-users

另一件可能值得尝试的事情是通过更改 modsecurity.conf 文件中的这一行来关闭响应正文处理：

SecResponseBodyAccess On

对此：

SecResponseBodyAccess Off

然后重启Tomcat。这应该在没有 ModSecurity 处理它们的情况下将响应传回。

响应主体通常用于信息泄漏，例如，详细的调试日志，以及应用程序内部工作的潜在细节不会发送回客户端。然而，虽然这很有用，但像 ModSecurity 这样的 WAF 主要是为了防止入站攻击。处理响应主体也会对性能产生影响，因为请求通常很小，因此更容易处理，而响应可能非常大（完整的 HTML 页面）。因此，我认为关闭此功能不会造成太大损失，甚至可能会获得保护。

于 2017-07-12T12:35:53.693 回答