Streaming-Unterstützung für die Anforderungsverarbeitung

Die Citrix Web App Firewall verwendet jetzt das anforderungsseitige Streaming, was zu einer erheblichen Leistungssteigerung führt. Anstatt die gesamte Anforderung vor der Verarbeitung zu puffern, betrachtet die Web App Firewall nun die eingehenden Daten Feld für Feld, um die Eingabe jedes Feldes auf konfigurierte Sicherheitsüberprüfungsverletzungen (SQL, XSS, Feldkonsistenz, Feldformate usw.) zu überprüfen. Sobald die Verarbeitung der Daten für ein Feld abgeschlossen ist, wird es an das Backend weitergeleitet, während die Auswertung für die übrigen Felder fortgesetzt wird. Dies verbessert die Verarbeitungszeit insbesondere bei der Bearbeitung großer Beiträge, bei denen die Formulare eine große Anzahl von Feldern haben.

Hinweis:

Citrix Web App Firewall unterstützt eine maximale Postgröße von 20 MB ohne Streaming. Für eine bessere Ressourcennutzung empfiehlt Citrix, die Streaming-Option für Nutzlasten größer als 20 MB zu aktivieren. Außerdem muss der Back-End-Server die aufgeteilten Anforderungen akzeptieren, wenn Streaming aktiviert ist.

Obwohl der Streaming-Prozess für die Benutzer transparent ist, sind aufgrund der folgenden Änderungen kleinere Konfigurationsanpassungen erforderlich:

RegEx Pattern Match: RegEx-Musterübereinstimmung ist jetzt für zusammenhängende Zeichenfolgen auf 4K beschränkt.

Feldnamenübereinstimmung: Die Learning Engine der Web App Firewall kann nur die ersten 128 Byte des Namens für das Lernen unterscheiden. Wenn ein Formular mehrere Felder mit Namen enthält, die identische Zeichenfolgenübereinstimmung für die ersten 128 Bytes haben, kann die Lern-Engine möglicherweise nicht zwischen ihnen unterscheiden. In ähnlicher Weise kann die implementierte Relaxationsregel versehentlich alle diese Felder entspannen.

Das Entfernen von Leerzeichen, prozentualer Decodierung, Unicode-Decodierung und Zeichensatzkonvertierung, die während der Kanonisierung durchgeführt wird, wird vor der Sicherheitskontrolle durchgeführt. Die 128-Byte-Grenze gilt für die kanonische Darstellung des Feldnamens im UTF-8-Zeichenformat. Die ASCII-Zeichen sind 1 Byte, aber die UTF-8-Darstellung der Zeichen in einigen internationalen Sprachen kann zwischen 1-4 Byte liegen. Wenn jedes Zeichen im Namen 4 Bytes benötigt, wenn es in UTF-8-Format konvertiert wird, können nur die ersten 32 Zeichen im Namen durch die gelernte Regel für eine solche Sprache unterschieden werden.

Feldkonsistenzprüfung: Wenn das Feld Konsistenzprüfung aktiviert ist, werden jetzt alle Formulare in der Sitzung basierend auf dem Tag as_fid gespeichert, das von der Web App Firewall eingefügt wird, ohne dass die action_url berücksichtigt wird.

  • Obligatorische Formularkennzeichnung für Formularfeldkonsistenz: Wenn die Feldkonsistenzprüfung aktiviert ist, muss auch das Formular-Tag aktiviert werden. Der Feldkonsistenzschutz funktioniert möglicherweise nicht, wenn die Formularkennzeichnung deaktiviert ist.
  • Sitzungslose Formularfeldkonsistenz: Die Web App Firewall führt nicht mehr die Konvertierung von Formularen GET in POST -Konsistenz von Formularen durch, wenn der Parameter Sitzungslose Feldkonsistenz aktiviert ist. Das Formular-Tag ist auch für sitzungslose Feldkonsistenz erforderlich.
  • Manipulation von as_fid: Wenn ein Formular nach der Manipulation as_fid gesendet wird, löst es nun eine Feldkonsistenzverletzung aus, selbst wenn kein anderes Feld manipuliert wurde. Bei Nicht-Streaming-Anforderungen war dies zulässig, da die Formulare mit der in der Sitzung gespeicherten action_url validiert werden konnten.

Signaturen: Die Signaturen haben nun folgende Spezifikationen:

  • Standort: Es ist jetzt zwingend erforderlich, dass die Position für jedes Muster angegeben werden muss. Alle Muster in der Regel MÜSSEN ein Tag <Location> haben.

  • Schnelle Übereinstimmung: Alle Signaturregeln müssen ein schnelles Übereinstimmungsmuster aufweisen. Wenn es kein Schnellübereinstimmungsmuster gibt, wird versucht, wenn möglich eines auszuwählen. Fast Match muss eine Literalzeichenfolge sein, aber einige PCRE’s können für die schnelle Übereinstimmung verwendet werden, wenn sie eine brauchbare Literalzeichenfolge enthalten.

  • Veraltete Speicherorte: Folgende Speicherorte werden in Signaturregeln nicht mehr unterstützt.

    • HTTP_ANY
    • HTTP_RAW_COOKIE
    • HTTP_RAW_HEADER
    • HTTP_RAW_RESP_HEADER
    • HTTP_RAW_SET_COOKIE

XSS/SQL-Transformation: Rohdaten werden für die Transformation verwendet, da die SQL-Sonderzeichen (einfaches Anführungszeichen (‘), umgekehrter Schrägstrich () und Semikolon (;) <) and (>) und XSS-Tags (()) in allen Sprachen gleich sind und keine Kanonisierung von Daten erfordern. Alle Darstellungen dieser Zeichen, wie HTML-Entitätskodierung, Prozentkodierung oder ASCII, werden für den Transformationsvorgang ausgewertet.

Die Web App Firewall prüft nicht mehr sowohl den Attributnamen als auch den Wert für den XSS-Transformationsvorgang. Jetzt werden nur XSS-Attributnamen transformiert, wenn Streaming aktiviert ist.

Verarbeitung von XSS-Tags: Als Teil der Streaming-Änderungen in Version 10.5.e wurde die Verarbeitung der Web App Firewall der Cross-Site Scripting Tags geändert. In früheren Versionen wurde das Vorhandensein einer offenen Klammer (<), or close bracket (>) oder sowohl offener als auch geschlossener Klammern (<>) als siteübergreifende Skriptverletzung gekennzeichnet. Das Verhalten hat sich ab 10.5.e Build geändert. Das Vorhandensein nur des offenen Klammerzeichens (<) oder nur des Klammerzeichens (>) wird nicht mehr als Angriff betrachtet. Es ist, wenn ein offenes Klammerzeichen (<) is followed by a close bracket character (>), der Cross-Site-Skripting-Angriff markiert wird. Beide Zeichen müssen in der richtigen Reihenfolge (< followed by >) vorhanden sein, um Cross-Site-Skriptverstoß auszulösen.

Hinweis:

Änderung im SQL-Verletzungsprotokoll Nachricht: Im Rahmen der Streaming-Änderungen in 10.5.e ab, verarbeiten wir jetzt die Eingabedaten in Blöcken. RegEx Pattern-Matching ist jetzt für zusammenhängende Zeichenfolgen auf 4K beschränkt. Mit dieser Änderung können die SQL-Verstoßprotokollmeldungen andere Informationen im Vergleich zu früheren Builds enthalten. Das Schlüsselwort und das Sonderzeichen in der Eingabe könnten durch eine große Anzahl von Bytes getrennt werden. Wir behalten nun den Überblick über die SQL-Schlüsselwörter und spezielle Zeichenfolgen bei der Verarbeitung der Daten, anstatt den gesamten Eingabewert zu puffern. Zusätzlich zum Feldnamen enthält die Protokollnachricht nun das SQL-Schlüsselwort oder das SQL-Sonderzeichen oder sowohl das SQL-Schlüsselwort als auch das SQL-Sonderzeichen, wie durch die konfigurierte Einstellung bestimmt. Der Rest der Eingabe ist nicht mehr in der Protokollmeldung enthalten, wie im folgenden Beispiel gezeigt:

Beispiel:

Wenn die Web App Firewall die SQL-Verletzung erkennt, wird in 10.5 möglicherweise die gesamte Eingabezeichenfolge in die Protokollmeldung aufgenommen, wie unten dargestellt:

SQL-Schlüsselwortüberprüfung für Feld text=”Wählen Sie einen Namen aus testbed1;\(;\)”.*<blocked>

In 11.0 protokollieren wir nur den Feldnamen, das Schlüsselwort und das Sonderzeichen (falls zutreffend) in der Protokollmeldung, wie unten gezeigt:

SQL-Schlüsselwortüberprüfung für Feldtext="select(;)" <blocked> fehlgeschlagen Diese Änderung gilt für Anforderungen, die application/x-www-form-urlencoded, multipart/form-dataoder text/x-gwt-rpcInhaltstypen enthalten. Protokollmeldungen, die während der Verarbeitung von JSON- oder XML-Nutzlasten generiert werden, sind von dieser Änderung nicht betroffen.

RAW POST Body: Die Sicherheitskontrollen werden immer auf RAW POST Body durchgeführt.

Formular-ID: Die Web App Firewall eingefügte as_fid -Tag, ein berechneter Hash des Formulars, ist für die Benutzersitzung nicht mehr eindeutig. Es hat nun einen identischen Wert für ein bestimmtes Formular unabhängig vom Benutzer oder der Sitzung.

Charset: Wenn eine Anforderung keinen Zeichensatz hat, wird der im Anwendungsprofil angegebene Standard-Zeichensatz verwendet, wenn die Anforderung verarbeitet wird.

Zähler:

Zähler mit dem Präfix se_ und appfwreq_ werden hinzugefügt, um die Streaming-Engine bzw. die Streaming-Engine der Web App Firewall zu verfolgen.

nsconsmg -d statswt0 -g se_err_

nsconsmg -d statswt0 -g se_tot_

nsconsmg -d statswt0 -g se_cur_

nsconsmg -d statswt0 -g appfwreq_err_

nsconsmg -d statswt0 -g appfwreq_tot_

nsconsmg -d statswt0 -g appfwreq_cur_

_err Zähler: Geben Sie das seltene Ereignis an, das erfolgreich sein sollte, aber aufgrund eines Speicherzuordnungsproblems oder einer anderen Ressourcenknappheit fehlgeschlagen sein sollte.

_tot-Zähler: stetig zunehmende Zähler.

_cur-Leistungsindikatoren: Leistungsindikatoren, die aktuelle Werte angeben, die sich aufgrund der Verwendung aus aktuellen Transaktionen ständig ändern.

Tipps:

  • Die Sicherheitsprüfungen der Web App Firewall sollten genau wie zuvor funktionieren.
  • Für die Abwicklung der Sicherheitskontrollen gibt es keine festgelegte Reihenfolge.
  • Die Verarbeitung der Antwortseite wird nicht beeinträchtigt und bleibt unverändert.
  • Streaming wird nicht aktiviert, wenn CVPN verwendet wird.

Wichtig

Berechnung der Cookie-Länge: In Release 10.5.e (in einigen Interimbuilds mit Erweiterungen vor 59.13xx.e Build) sowie in der Version 11.0 (in Builds vor 65.x) wurde die Verarbeitung des Cookie-Headers von Web App Firewall geändert. In diesen Versionen wird jedes Cookie einzeln ausgewertet, und wenn die Länge eines im Cookie-Header empfangenen Cookies die konfigurierte BufferOverflowMaxCookieLength überschreitet, wird die Pufferüberlaufverletzung ausgelöst. Infolge dieser Änderung können Anfragen, die in 10.5 und früheren Versionen blockiert wurden, zulässig sein, da die Länge des gesamten Cookie-Headers nicht für die Bestimmung der Cookie-Länge berechnet wird . In einigen Situationen kann die gesamte Cookie-Größe, die an den Server weitergeleitet wird, größer sein als der akzeptierte Wert, und der Server reagiert möglicherweise mit 400 Bad Request.

**Beachten Sie, dass diese Änderung rückgängig gemacht wurde. Das Verhalten in den 10.5.e ->59.13xx.e und den nachfolgenden 10.5.e Erweiterungsbuilds sowie in 11.0 Release 65.x und nachfolgenden Builds ähnelt nun dem der Nicht-Erweiterungs-Builds von Release 10.5. Der gesamte rohe Cookie-Header wird nun bei der Berechnung der Länge des Cookies berücksichtigt. Umgebende Leerzeichen und Semikolon (;) Zeichen, die die Name-Wert-Paare trennen, werden ebenfalls bei der Bestimmung der Cookie-Länge berücksichtigt. **

Streaming-Unterstützung für die Anforderungsverarbeitung