Ist es möglich, dass eine Firewall 'Accept-Encoding' ändert? Obwohl es in Fiddler in Ordnung zu sein scheint

Question

Ich habe eine Regel auf APACHE für HTTP-Komprimierung hinzugefügt. Die Regel ist sicherlich in Ordnung, aber Fiddler zeigt an, dass die Antwort nicht komprimiert ist. (Ich habe curl für localhost getestet, die Antwort ist komprimiert)

Ich vermute, dass eine Firewall den Accept-Encoding im Anforderungsheader in etwas anderes ändert. Obwohl Fiddler anzeigt, dass der Anforderungsheader Accept-Encoding enthält.

Ich meine, wenn Fiddler sagt, dass dein Accept-Encoding so ist, aber in Wirklichkeit nicht. Ich möchte nur sicherstellen, bevor ich mich an den Firewall-Anbieter wende.

Und.. das ist nur aus Neugier, was hat Accept-Encoding mit Sicherheit zu tun?

Answer 1

Einige Firewalls und Sicherheitssoftware können einen ausgehenden ACCEPT-ENCODING-Header verändern oder entfernen, um zu verhindern, dass der Server die HTTP-Kompression verwendet, um die Antwort zu komprimieren. Firewalls/Sicherheitssoftware bevorzugen es manchmal, Antworten nicht vor dem Scannen zu dekomprimieren (entweder weil sie nicht wissen, wie man dekomprimiert oder weil die Dekomprimierung CPU-Zeit in Anspruch nimmt).

Fiddler zeigt Ihnen die HTTP-Header, bevor sie Ihren Computer verlassen haben und somit bevor sie von einer Firewall oder einem Upstream-Gateway verändert wurden.

Sie können leicht die ausgehenden Header Ihrer HTTP-Anfrage sehen; besuchen Sie https://bayden.com/echo2.aspx und https://bayden.com/echo2.aspx, um die Header zu sehen, die vom Client gesendet wurden. Beachten Sie, dass HTTPS-Anfrage-Header intakt sein könnten, auch wenn die HTTP-Anfrage-Header verändert sind, da Vermittler normalerweise den HTTPS-Verkehr nicht beeinträchtigen können.