ADC

Streaming-Unterstützung für die Bearbeitung von Anfragen

Die NetScaler Web App Firewall unterstützt Streaming auf Anforderungsseite, um eine deutliche Leistungssteigerung zu erzielen Anstatt eine Anforderung zu puffern, untersucht die Appliance den eingehenden Datenverkehr auf Sicherheitsverletzungen wie SQL, Cross-Site Scripting, Feldkonsistenz und Feldformate. Wenn die Appliance die Verarbeitung der Daten für ein Feld abgeschlossen hat, wird die Anforderung an den Back-End-Server weitergeleitet, während die Appliance weiterhin andere Felder auswertet. Diese Datenverarbeitung verbessert die Verarbeitungszeit bei der Bearbeitung von Formularen erheblich.

Citrix empfiehlt, Streaming für Nutzlast-Inhalte mit mehr als 20 MB zu aktivieren. Außerdem muss der Back-End-Server die Chunked-Anforderungen akzeptieren, wenn das Streaming aktiviert ist.

Hinweis:

Die Aktion “Post-Body-Limit” ist immer auf “Blockieren” eingestellt und gilt sowohl für den Streaming- als auch für den Wenn der eingehende Datenverkehr größer als 20 MB ist, empfiehlt Citrix, den PostBodyLimit auf den erwarteten Wert zu konfigurieren.

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

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

Übereinstimmung mit Feldnamen: Das Lernmodul der Web App Firewall kann nur die ersten 128 Byte des Namens unterscheiden. Wenn ein Formular mehrere Felder mit Namen hat, die eine identische Zeichenfolgenübereinstimmung für die ersten 128 Byte aufweisen, unterscheidet die Lernmaschine sie nicht. In ähnlicher Weise kann die eingesetzte Entspannungsregel versehentlich alle diese Felder lockern.

Das Entfernen von Leerräumen, die prozentuale Dekodierung, die Unicode-Dekodierung und die Zeichensatzkonvertierung werden während der Kanonisierung durchgeführt, um eine Sicherheitsüberprüfung zu ermöglichen. Das 128-Byte-Limit gilt für die kanonische Darstellung des Feldnamens im UTF-8-Zeichenformat. Die ASCII-Zeichen sind 1 Byte lang, aber die UTF-8-Darstellung der Zeichen in einigen internationalen Sprachen kann von 1 Byte bis 4 Byte reichen. Wenn jedes Zeichen in einem Namen 4 Byte für die Konvertierung in das UTF-8-Format benötigt, können nur die ersten 32 Zeichen im Namen durch die gelernte Regel unterschieden werden.

Feldkonsistenzprüfung: Wenn Sie die Feldkonsistenz aktivieren, werden alle Formulare in der Sitzung basierend auf dem von der Web App Firewall eingefügten “as_fid” -Tag gespeichert, ohne die “action_url” zu berücksichtigen.

  • Obligatorisches Formulartagging für Konsistenz im Formularfeld: Wenn die Feldkonsistenzprüfung aktiviert ist, muss auch das Formulartag aktiviert sein Der Schutz vor Feldkonsistenz funktioniert möglicherweise nicht, wenn das Formulartagging ausgeschaltet ist.
  • Konsistenz von sitzungslosen Formularen: Die Web App Firewall führt die Konvertierung von Formularen nicht mehr von “GET” nach “POST” durch, wenn der Parameter für die Feldkonsistenz ohne Sitzung aktiviert ist. Das Formulartag ist auch für die Konsistenz von Feldern ohne Sitzung erforderlich.
  • Manipulation von as_fid: Wenn ein Formular nach der Manipulation von as_fid gesendet wird, wird eine Verletzung der Feldkonsistenz ausgelöst, selbst wenn kein Feld manipuliert wurde. Bei Nicht-Streaming-Anforderungen war dies zulässig, da die Formulare mithilfe der in der Sitzung gespeicherten “action_url” validiert werden können.

Signaturen: Die Signaturen haben jetzt die folgenden Spezifikationen:

  • Standort: Es ist jetzt eine zwingende Anforderung, dass der Standort für jedes Muster angegeben werden muss. Alle Muster in der Regel MÜSSEN ein <Location>-Tag haben.

  • Schnelles Spiel: Alle Signaturregeln müssen ein schnelles Übereinstimmungsmuster haben. Wenn es kein Fast-Match-Muster gibt, wird versucht, wenn möglich eines auszuwählen. Fast Match ist eine literale Zeichenfolge, PCRE kann aber für eine schnelle Übereinstimmung verwendet werden, wenn sie eine verwendbare Literalzeichenfolge enthält.

  • 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

Cross-Site-Scripting/SQL Transform: Rohdaten werden für die Transformation verwendet, da die SQL-Sonderzeichen wie einfaches Anführungszeichen (‘), Backslash () und Semikolon (;)) sowie Cross-Site-Scripting-Tags identisch sind und keine Kanonisierung von Daten erfordern. Die Darstellung von Sonderzeichen wie HTML-Entity-Codierung, prozentuale Codierung oder ASCII wird für den Transformationsvorgang ausgewertet.

Die Web App Firewall prüft nicht mehr sowohl den Attributnamen als auch den Wert für die Cross-Site Scripting-Scripttransformation. Jetzt werden nur Cross-Site Scripting-Attributnamen umgewandelt, wenn Streaming aktiviert ist.

Verarbeitung von Cross-Site-Scripting-Tags: Im Rahmen der Streaming-Änderungen in NetScaler 10.5.e Build und höher wurde die Verarbeitung der Cross-Site-Scripting-Tags geändert. In früheren Versionen wurde das Vorhandensein einer offenen Klammer (<) oder einer schließenden Klammer (>) oder beiden (<>) als Cross-Site-Scripting-Verletzung gekennzeichnet. Das Verhalten hat sich ab Version 10.5.e geändert. Nur das Vorhandensein des Charakters in offener Klammer (<), or only the close bracket character (>) wird nicht mehr als Angriff betrachtet. Dies ist, wenn ein Charakter in offener Klammer (<) is followed by a close bracket character (>), der Cross-Site-Scripting-Angriff markiert wird. Beide Zeichen müssen in der richtigen Reihenfolge (< followed by >) vorhanden sein, um die Cross-Site-Scripting-Verletzung auszulösen.

Hinweis:

Meldung zur Änderung des SQL-Verstoßprotokolls: Im Rahmen der Streaming-Änderungen in NetScaler ab Version 10.5.e verarbeiten wir die Eingabedaten jetzt 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 sind durch viele Byte getrennt. Die Appliance verfolgt die SQL-Schlüsselwörter und speziellen Zeichenfolgen bei der Verarbeitung der Daten, anstatt den gesamten Eingabewert zu puffern. Zusätzlich zum Feldnamen enthält die Protokollnachricht das SQL-Schlüsselwort, das SQL-Sonderzeichen oder sowohl das SQL-Schlüsselwort als auch das SQL-Sonderzeichen. Der Rest der Eingabe ist nicht mehr in der Protokollnachricht enthalten, wie im folgenden Beispiel gezeigt:

Beispiel:

In 10.5, wenn die Web App Firewall die SQL-Verletzung erkennt, ist möglicherweise die gesamte Eingabezeichenfolge in der folgenden Protokollmeldung enthalten:

Die SQL-Schlüsselwortprüfung ist text="select a name from testbed1\;\(\;\)".*<blocked>

In 11.0 protokollieren wir nur den Feldnamen, das Schlüsselwort und das Sonderzeichen (falls zutreffend) in der folgenden Protokollnachricht.

SQL-Schlüsselwortprüfung für Feld fehlgeschlagen text="select(;)" <blocked>

**Diese Änderung gilt für Anfragen, die die Inhaltstypen **application/x-www-form-urlencoded, multipart/form-data oder text/x-gwt-rpcenthalten.** Protokollmeldungen, die während der Verarbeitung von **JSON - oder XML-Nutzdaten generiert werden, sind von dieser Änderung nicht betroffen.

RAW POST Body: Die Inspektionen der Sicherheitskontrolle werden immer am RAW POST Körper durchgeführt.

Formular-ID: Die Web App Firewall hat das Tag “as_fid” eingefügt, bei dem es sich um einen berechneten Hash des Formulars handelt, das für die Benutzersitzung länger eindeutig ist. Es ist ein identischer Wert für ein bestimmtes Formular, unabhängig vom Benutzer oder der Sitzung.

Zeichensatz: Wenn eine Anforderung keinen Zeichensatz hat, wird der im Anwendungsprofil angegebene Standardzeichensatz bei der Verarbeitung der Anforderung verwendet.

Zähler:

Zähler mit dem Präfix “se” und “appfwreq” werden hinzugefügt, um die Streaming-Engine und die Streaming-Engine-Anforderungszähler 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 counters: zeigt das seltene Ereignis an, das erfolgreich gewesen sein muss, aber aufgrund eines Speicherzuweisungsproblems oder einer anderen Ressourcenkrise fehlgeschlagen ist.

_tot counters: immer größer werdende Zähler.

_cur counters: Zähler, die aktuelle Werte angeben, die sich basierend auf der Verwendung aus aktuellen Transaktionen ständig ändern.

Tipps:

  • Die Sicherheitsüberprüfungen der Web App Firewall müssen genauso funktionieren wie zuvor.
  • Für die Abwicklung der Sicherheitsüberprüfungen gibt es keine festgelegte Reihenfolge.
  • Die Response-Side-Verarbeitung ist nicht betroffen und bleibt unverändert.
  • Streaming ist nicht aktiviert, wenn ein clientloses VPN verwendet wird.

Wichtig:

Berechnung der Cookie-Länge: In Version 10.5.e wurde zusätzlich zu NetScaler Version 11.0 (in Builds vor 65.x) die Art der Verarbeitung des Cookie-Headers durch die Web App Firewall geändert. Die Appliance hat das Cookie einzeln ausgewertet, und wenn die Länge eines Cookies im Cookie-Header die konfigurierte Länge überschritt, wurde die Pufferüberlaufverletzung ausgelöst. Daher sind Anforderungen, die in der NetScaler 10.5-Version oder früheren Versionen blockiert wurden, möglicherweise zulässig. Die Länge des gesamten Cookie-Headers wird nicht für die Bestimmung der Cookie-Länge berechnet. In einigen Situationen kann die gesamte Cookie-Größe größer als der akzeptierte Wert sein, und der Server antwortet möglicherweise mit “400 Bad Request”.

Hinweis: Die Änderung wurde rückgängig gemacht. Das Verhalten von NetScaler Version 10.5.e bis Version 59.13xx.e und den nachfolgenden Builds ähnelt den Builds ohne Erweiterung von Version 10.5. Der gesamte rohe Cookie-Header wird jetzt bei der Berechnung der Länge des Cookies berücksichtigt. Umgebende Räume und die 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 Bearbeitung von Anfragen

In diesem Artikel