Übertragung Codierung: Chunked verursacht Probleme für HTML-Antwort (mit ModSecurity)

Ich habe eine Java-Servlet-basierte Web-Anwendung mit Spring Saml und ModSecurity.Übertragung Codierung: Chunked verursacht Probleme für HTML-Antwort (mit ModSecurity)

Bei einer der GET-Anfragen (URL -/saml/login) ist die Antwort eine HTML-Seite, die als text/html zurückgegeben wird (ich kann die HTML-Datei in den Browser-Netzwerkwerkzeugen lesen). Dies ist der Fall, wenn ModSecurity deaktiviert ist.

Wenn ich ModSecurity in der App aktivieren, wird die gleiche Antwort mit dem Header Transfer-encoding: chunked zurückgegeben. Dieses Mal ist die HTML-Antwort aufgrund von Chunking verschlüsselt. ZB <html wird als 10<60h104t116m109l108 angezeigt. Ich bin mir nicht sicher, ob der Browser dies decodieren soll, aber das ist der Fluss meiner Anwendung. Da die Antwort im verschlüsselten Format auf dem Browser angezeigt wird.

Ich habe versucht, Regeln in ModSecurity auskommentieren, um herauszufinden, was die Antwort ohne Erfolg chunked verursacht. Da ein anderer Entwickler ModSecurity implementiert hat, bin ich mir nicht sicher, wie ich das lösen könnte, indem ich ModSecurity ändere.

Also ich möchte versuchen, die Antwort in Java-Code oder im Browser zu entschlüsseln. Wenn die HTML-Datei normal gerendert wird, beginnen die nachfolgenden Anforderungen zu arbeiten.

EDIT 1:

ModsecurityFilter Konfiguration in der web.xml:

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

Quelle

2017-07-12 adarsh hegde

Noch nie davon gehört. Welchen Webserver benutzen Sie mit ModSecurity (Apache? Nginx? IIS?), welche Plattform (Linux? Windows?) und welche Version von ModSecurity? –

Ich benutze einen Apache Tomcat V8 Webserver und ein Ubuntu OS mit ModSecurity Version 2.7. –

ModSecurity wird auf Tomcat nicht unterstützt, also betreiben Sie Apache davor? Können Sie versuchen, "SecDisableBackendCompression On" einzustellen und sehen, ob das hilft? –

Es scheint, die Sie senden die ASCII-Codes sowie den Text zurück. Habe das noch nie gesehen und weiß nicht, warum ModSecurity das machen würde. Transfer-Encoding: Chunked ist eine Standard-HTTP-Antwort und sowohl der Server als auch der Client sollten in der Lage sein, dies zu handhaben, und es sollte das Format dessen, was zurückgesendet wird, nicht ändern.

Sieht man einen wenig gebraucht und älteren ModSecurity für Java verwenden, wie hier beschrieben: https://www.trustwave.com/Resources/SpiderLabs-Blog/ModSecurity-for-Java---BETA-Testers-Needed/

ich nicht bewusst war dies existierte und es in mehr als 4 Jahren so nicht sicher, wie stabil es ist nicht gepflegt wurde um ehrlich zu sein.

Sie könnten versuchen, einen Kommentar auf dem oberen Seite hinzufügen oder für Hilfe auf der ModSecurity Benutzer-Mailingliste zu fragen: https://sourceforge.net/projects/mod-security/lists/mod-security-users

Eine andere Sache, die würde ich lohnen könnte versuchen, indem Sie diese Zeile Antwort Körperverarbeitung Abschalten in Datei Ihre modsecurity.conf:

SecResponseBodyAccess On

dazu:

SecResponseBodyAccess Off

Und dann Tomcat neu starten. Dies sollte Antworten zurückgeben, ohne dass ModSecurity sie verarbeitet.

Antwort-Körper werden normalerweise für Informationsverlust verwendet, also zum Beispiel ein ausführliches Debug-Protokoll, mit möglichen Details der inneren Arbeit der Anwendung werden nicht zurück an den Client gesendet. Obwohl dies nützlich ist, schützt eine WAF wie ModSecurity vor eingehenden Angriffen. Die Verarbeitung von Antworthauptteilen wirkt sich auch auf die Leistung aus, da Anforderungen normalerweise klein sind und daher einfacher zu verarbeiten sind, während Antworten sehr groß sein können (vollständige HTML-Seiten). Deshalb glaube ich nicht, dass du zu viel verlierst, indem du diese abschaltest und vielleicht sogar mehr Schutz bekommst.

Quelle

2017-07-12 12:35:53

BazzaDP: Vielen Dank für die ausführliche Antwort. Ich schätze es! Ich hatte diese Option ausprobiert (SecResponseBodyAccess Aus), aber es hat nicht für mich funktioniert. Gibt es eine Möglichkeit, ModSecurity für eine bestimmte URL-Anforderung oder einen bestimmten Antwortheader zu deaktivieren? Wenn ja, können Sie bitte auf die erforderliche Konfiguration hinweisen. –

Woher hast du die option() Syntax? Erkenne das nicht. Sehen Sie hier, wie Sie Regeln schreiben, um ModSecurity zu deaktivieren: https://stackoverflow.com/questions/42829492/how-to-add-mod-security-exception/42832490#42832490 –

Auch nach dem Umkehren der Regeln auf globaler Ebene Ich kann dieses Problem nicht beheben. Ich denke, das Problem liegt am ModSecurity-Filter oder an einer der Bibliotheken in der ModSecurity-Abhängigkeit. –

Übertragung Codierung: Chunked verursacht Probleme für HTML-Antwort (mit ModSecurity)

Antwort

Verwandte Themen