転送エンコーディング：HTMLレスポンスに問題が発生しました（Modsecurityを使用）

Question

私はspring-samlとModsecurityを使用したJava-ServletベースのWebアプリケーションを持っています。

GETリクエスト（URL -/saml/login）の1つとして、Content-Lengthヘッダーと共にtext/html（ブラウザネットワークツールでhtmlファイルを読むことができます）として返されるHTMLページです。これは、Modsecurityが無効になっているときです。

私がアプリケーションでModSecurityを有効にすると、同じ応答がヘッダTransfer-encoding：chunkedで返されます。今回は、チャンクによってhtmlレスポンスがエンコードされます。たとえば<htmlは10<60h104t116m109l108と表示されます。私はブラウザがこれをデコードしているはずですが、これが私のアプリケーションの流れを壊しているのかどうかはわかりません。レスポンスはブラウザにエンコードされた形式で表示されます。

私はModSecurityのルールをコメントアウトして、どのレスポンスが成功してチャンクされているのかを調べてみました。別の開発者がModSecurityを実装して以来、ModSecurityをどのように変更すればこの問題を解決できるのかよく分かりません。

私はJavaコードまたはブラウザで応答をデコードしようとします。 Htmlファイルが正常にレンダリングされると、後続の要求が機能し始めます。

EDIT 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> 

Answer 1

あなたがASCIIコードだけでなく、テキストを返送されて表示されます。これまでModSecurityがこれを行う理由は分かりませんでした。 Transfer-Encoding：chunkedは標準的なHTTPレスポンスであり、サーバーとクライアントの両方がこれを処理できる必要があり、返されるものの形式を変更してはいけません。

あなたはここに詳述されているJavaのために少し使用され、古いModSecurityはを使用しているルックス：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ページ）一方で、レスポンスボディの処理は、リクエストが通常は小さく、処理が容易なため、パフォーマンスに影響を与えます。したがって、私はあなたがこれをオフにすることによってあまりにも多くを失うとは思っていませんし、保護を得ることさえあります。