Warum erfordert Modsecurity Inhaltslänge in POST-Anforderungen?

Ich habe einen RESTful-Webdienst, der eine POST-Anforderung an eine Ressource ohne Entitätstext akzeptiert, z. B. eine leere POST-Anforderung. Die Standard-Modsecurity-Konfiguration erfordert, dass alle POST-Anforderungen eine Inhaltslänge haben:

# Require Content-Length to be provided with every POST request
SecFilterSelective REQUEST_METHOD "^POST$" chain
SecFilterSelective HTTP_Content-Length "^$"

Die Modsecurity-Konsole meldet dies als PROTOCOL_VIOLATION / EVASION. Ich sehe dies jedoch nicht als wahr an, wenn ich den HTTP / 1.1-RFC lese . Ein Server darf Content-Length benötigen (entweder 400 oder 411), aber ich sehe nichts, was besagt, dass sich ein Server so verhalten muss (oder eine Empfehlung, dass er sollte).

Dies hängt möglicherweise vom Browser ab, aber Flash-Clients, die POST-Anforderungen ohne Entitätskörper stellen, senden keinen Anforderungsheader. Curl auch nicht, wenn Sie 'Curl -XPOST ...' machen. Aus diesen Gründen und weil ich glaube, dass die Modsecurity-Regel eine Fehlinterpretation der HTTP-Spezifikation darstellt, erwäge ich, die Anforderung für einen Content-Length-Header für POST-Anforderungen in unserer Konfiguration aufzuheben.

Weiß jemand, ob es einen bestimmten Exploit gab, für den diese Regel erstellt wurde? Zahlreiche Google-Suchanfragen und ich habe nur Hinweise darauf gefunden, dass dies Teil der Standard-Modsecurity-Konfiguration ist.

Zunächst sollten Sie wissen, dass Sie eine veraltete Version von ModSecurity (Zweig 1.x) ausführen. Wenn Sie Apache 2.0.x ausführen, sollten Sie ein Upgrade auf ModSecurity 2.x durchführen. Wenn Sie noch Apache 1.3.x ausführen, haben Sie leider keine Wahl, da ModSecurity 2.x nicht damit funktioniert. ModSecurity 1.x selbst ist nicht als anfällig bekannt, aber seine Regel-Engine ist für die heutigen Anforderungen zu unflexibel.

Wenn ich mich richtig erinnere, erforderte ModSecurity 1.x POST-Anforderungen, um die Inhaltslänge anzugeben, nur weil es keine Chunk-Anforderungskörper unterstützte (die alternative Methode zum Senden von Anforderungskörpern, bei der die Gesamtlänge bis zum Ende nicht bekannt ist). Chunked Request Body waren damals unglaublich selten (wir sprechen von den Jahren 2003, 2004) und sind immer noch selten (obwohl einige mobile Geräte sie verwenden).

In ModSecurity 2.x gibt es keine derartigen Einschränkungen.

Wenn Sie diese Regel entfernen, erstellen Sie ein großes Loch, durch das sich jemand unentdeckt in einen Angriff schleichen kann. Andererseits kann ich argumentieren, dass es bei der Ausführung von ModSecurity 1.x andere Möglichkeiten gibt, dasselbe zu tun. Alternativ können Sie die Regel anpassen, um Anforderungen abzulehnen, für die der Header für die Übertragungscodierungsanforderung festgelegt ist. Damit sollten Sie sicher sein.

Offenlegung: Ich habe ModSecurity geschrieben.

Ich glaube, dass die Anforderung Teil der xml-rpc-Spezifikation und nicht der http-Spezifikation ist. Wenn Sie nicht nach xml-rpc sind, würde ich denken, dass es in Ordnung wäre, dies wegzulassen.

Ich weiß nicht viel über die Gründe für die allgemeine Aufnahme in mod_security, es sei denn, es war ursprünglich dazu da, einen esoterischen Pufferüberlauf zu verhindern.