Produktdokumentation
ADC
14.1 - Current Release 13.1 13.0 12.1
PDF anzeigen

Schutz vor Cookie-Hijacking

March 17, 2024
Beitrag von: 
C

Der Schutz vor Cookie-Hijacking mildert Angriffe von Hackern, die Cookies stehlen. Bei dem Sicherheitsangriff übernimmt ein Angreifer eine Benutzersitzung, um sich unbefugten Zugriff auf eine Webanwendung zu verschaffen. Wenn ein Benutzer eine Website besucht, beispielsweise eine Bankanwendung, baut die Website eine Sitzung mit dem Browser auf. Während der Sitzung speichert die Anwendung die Benutzerdetails wie Anmeldeinformationen und Seitenbesuche in einer Cookie-Datei. Die Cookie-Datei wird dann in der Antwort an den Client-Browser gesendet. Der Browser speichert die Cookies, um aktive Sitzungen aufrechtzuerhalten. Der Angreifer kann diese Cookies entweder manuell aus dem Cookie-Speicher des Browsers oder über eine Rouge-Browsererweiterung stehlen. Der Angreifer verwendet diese Cookies dann, um Zugriff auf die Webanwendungssitzungen des Benutzers zu erhalten.

Um Cookie-Angriffe abzuwehren, fordert die Citrix ADC Web App Firewall (WAF) die TLS-Verbindung vom Client zusammen mit der WAF-Cookie-Konsistenzüberprüfung heraus. Für jede neue Clientanforderung validiert die Appliance die TLS-Verbindung und überprüft auch die Konsistenz von Anwendungs- und Sitzungscookie in der Anforderung. Wenn ein Angreifer versucht, Anwendungscookies und Sitzungscookies, die vom Opfer gestohlen wurden, zu mischen und abzugleichen, schlägt die Validierung der Cookie-Konsistenz fehl, und die konfigurierte Cookie-Hijack-Aktion wird angewendet. Weitere Informationen zur Cookie-Konsistenz finden Sie im Thema Cookie-Konsistenzprüfung.

Hinweis:

Die Cookie-Hijacking-Funktion unterstützt Protokollierung und SNMP-Traps. Weitere Informationen zur Protokollierung finden Sie unter ADM-Thema und weitere Informationen zur SNMP-Konfiguration finden Sie unter SNMP-Thema.

Einschränkungen

  • JavaScript muss im Client-Browser aktiviert sein.
  • Der Cookie-Hijacking Schutz wird auf TLS Version 1.3 nicht unterstützt.
  • Begrenzte Unterstützung für den Internet Explorer (IE) -Browser, da der Browser die SSL-Verbindungen nicht wiederverwendet. Führt zu mehreren Weiterleitungen, die für eine Anfrage gesendet werden, die schließlich zu einem Fehler “MAX READCEED” im IE-Browser führen.

In den folgenden Szenarien wird erläutert, wie der Schutz vor Cookie-Hijacking in einer Citrix ADC Appliance funktioniert.

Szenario 1: Benutzer, der ohne Sitzungscookie auf die erste Webseite zugreift

Cookie-Hijacking-Angriff Anwendungsfall 1: Benutzerzugriff ohne Session-Cookie

  1. Der Benutzer versucht, sich bei einer Webanwendung zu authentifizieren und beginnt, auf die erste Webseite zuzugreifen, ohne dass ein ADC-Sitzungscookie in der Anfrage enthalten ist.
  2. Wenn die Anforderung empfangen wird, erstellt die Appliance eine Anwendungs-Firewall-Sitzung mit einer Sitzungscookie-ID.

  3. Dadurch wird eine TLS-Verbindung für die Sitzung initiiert. Da das JavaScript nicht gesendet und im Client-Browser ausgeführt wird, markiert die Appliance die TLS-Verbindung als validiert und es ist keine Abfrage erforderlich.

    Hinweis:

    Selbst wenn ein Angreifer versucht, alle App-Cookie-IDs von einem Opfer zu senden, ohne das Sitzungscookie zu senden, erkennt die Appliance das Problem und entfernt alle App-Cookies in der Anfrage, bevor sie die Anfrage an den Backend-Server weiterleitet. Der Backend-Server berücksichtigt diese Anfrage ohne App-Cookie und nimmt dies gemäß seiner Konfiguration erforderlich.

  4. Wenn der Backend-Server eine Antwort sendet, empfängt die Appliance die Antwort und leitet sie mit einem JavaScript-Sitzungstoken und einem Seed-Cookie weiter. Die Appliance markiert dann die TLS-Verbindung als verifiziert.
  5. Wenn der Client-Browser die Antwort empfängt, führt der Browser das JavaScript aus und generiert mithilfe des Sitzungstokens und des Seed-Cookies eine morphierte Cookie-ID.
  6. Wenn ein Benutzer eine nachfolgende Anfrage über die TLS-Verbindung sendet, umgeht die Appliance die morphierte Cookie-Validierung. Dies liegt daran, dass die TLS-Verbindung bereits validiert wurde.

Szenario 2: Benutzer, der über eine neue TLS-Verbindung mit Sitzungscookie auf aufeinanderfolgende Webseiten zugreift

Cookie-Hijacking-Angriff Anwendungsfall 2: Benutzerzugriff über neues TLS mit Session-Cookie

  1. Wenn ein Benutzer eine HTTP-Anfrage für aufeinanderfolgende Seiten über eine neue TLS-Verbindung sendet, sendet der Browser die Sitzungs-Cookie-ID und die morphierte Cookie-ID.
  2. Da es sich um eine neue TLS-Verbindung handelt, erkennt die Appliance die TLS-Verbindung und fordert den Client mit einer Umleitungsantwort mit einem Seed-Cookie.
  3. Der Client berechnet nach Erhalt der Antwort vom ADC das morphierte Cookie anhand des Tokens der Sitzung und des neuen Seed-Cookies.
  4. Der Client sendet dann dieses neu berechnete Morphed-Cookie zusammen mit einer Sitzungs-ID.
  5. Wenn das innerhalb der ADC-Appliance berechnete Morphed-Cookie und das über die Anforderung gesendete Cookie übereinstimmen, wird die TLS-Verbindung als verifiziert markiert.
  6. Wenn sich das berechnete Morphed-Cookie von dem in der Client-Anfrage vorhandenen unterscheidet, schlägt die Validierung fehl. Danach sendet die Appliance die Herausforderung zurück an den Client, um ein korrektes Morphed-Cookie zu senden.

Szenario 3: Angreifer gibt sich als nicht authentifizierter Benutzer aus

Cookie-Hijacking-Angriff Anwendungsfall 3: Angreifer verkörpert sich als nicht authentifizierter Benutzer

  1. Wenn sich ein Benutzer bei der Webanwendung authentifiziert, verwendet der Angreifer verschiedene Techniken, um die Cookies zu stehlen und erneut abzuspielen.
  2. Da es sich um eine neue TLS-Verbindung des Angreifers handelt, sendet der ADC eine Umleitungsaufforderung zusammen mit einem neuen Seed-Cookie.
  3. Da auf dem Angreifer kein JavaScript ausgeführt wird, enthält die Antwort des Angreifers auf die umgeleitete Anfrage nicht das morphierte Cookie.
  4. Dies führt zu einem Fehler bei der morphierten Cookie-Validierung auf der ADC-Appliance-Seite. Die Appliance sendet erneut eine Umleitungsaufforderung an den Client.
  5. Wenn die Anzahl der Morphed-Cookie-Validierungsversuche den Schwellenwert überschreitet, kennzeichnet die Appliance den Status als Cookie-Hijacking.
  6. Wenn der Angreifer versucht, Anwendungscookies und Sitzungscookies, die dem Opfer gestohlen wurden, zu mischen und zuzuordnen, schlägt die Cookie-Konsistenzprüfung fehl und die Appliance wendet die konfigurierte Cookie-Hijack-Aktion an.

Szenario 4: Angreifer gibt sich als authentifizierter Benutzer aus

Cookie-Hijacking-Angriff Anwendungsfall 4: Angreifer verkörpert sich als authentifizierter Benutzer

  1. Angreifer können auch versuchen, sich in einer Webanwendung als echter Benutzer zu authentifizieren und die Cookies des Opfers erneut abzuspielen, um Zugriff auf die Web-Sitzung zu erhalten.
  2. Die ADC-Appliance erkennt auch solche Identitätsangreifer. Obwohl eine verifizierte TLS-Verbindung vom Angreifer verwendet wird, um das Cookie eines Opfers erneut abzuspielen, überprüft die ADC-Appliance dennoch, ob das Sitzungscookie und das Anwendungscookie in der Anforderung konsistent sind. Die Appliance überprüft die Konsistenz eines Anwendungscookies mithilfe des Sitzungscookies in der Anforderung. Da die Anfrage das Sitzungscookie eines Angreifers und das App-Cookie eines Opfers enthält, schlägt die Überprüfung der Cookie-Konsistenz fehl.
  3. Infolgedessen wendet die Appliance die konfigurierte Cookie-Hijack-Aktion an. Wenn die konfigurierte Aktion als “Blockieren” festgelegt ist, entfernt die Appliance alle Anwendungscookies und sendet die Anforderung an den Backend-Server.
  4. Der Backend-Server empfängt eine Anfrage ohne Anwendungscookie und reagiert daher auf eine Fehlerantwort an den Angreifer, z. B. “Benutzer nicht angemeldet”.

Sie können ein bestimmtes Anwendungs-Firewallprofil auswählen und eine oder mehrere Aktionen festlegen, die das Hijacking von Cookie verhindern.

Geben Sie in der Befehlszeile Folgendes ein:

set appfw profile <name> [-cookieHijackingAction <action-name> <block | log | stats | none>]

Hinweis:

Standardmäßig ist die Aktion auf “none” gesetzt.

Beispiel:

set appfw profile profile1 - cookieHijackingAction Block

Wo sind Aktionstypen:

Blockieren: Blockiert Verbindungen, die gegen diese Sicherheitsüberprüfung verstoßen. Protokoll: Verstöße gegen diese Sicherheitsüberprüfung protokollieren. Statistiken: Generieren Sie Statistiken für diese Sicherheitsüberprüfung. Keine: Deaktivieren Sie alle Aktionen für diese Sicherheitsüberprüfung.

  1. Navigieren Sie zu Sicherheit > Citrix Web App Firewall > Profile.
  2. Wählen Sie auf der Seite Profile ein Profil aus, und klicken Sie auf Bearbeiten.
  3. Wechseln Sie auf der Citrix Web App Firewall Profilseite zum Abschnitt Erweiterte Einstellungen und klicken Sie auf Sicherheitsprüfungen.
  4. Wählen Sie im Abschnitt Sicherheitsüberprüfungen die Option Cookie-Hijacking aus und klicken Sie dann auf Aktionseinstellungen.
  5. Wählen Sie auf der Seite Cookie-Hijacking-Einstellungen eine oder mehrere Aktionen aus, um das Hijacking von Cookies zu verhindern.
  6. Klicken Sie auf OK.

Um Fehlalarme bei der Überprüfung der Cookie-Konsistenz zu behandeln, können Sie eine Relaxationsregel für Cookies hinzufügen, die von der Cookie-Validierung ausgenommen werden können.

  1. Navigieren Sie zu Sicherheit > Citrix Web App Firewall > Profile.
  2. Wählen Sie auf der Seite Profile ein Profil aus, und klicken Sie auf Bearbeiten.
  3. Wechseln Sie auf der Seite Citrix Web App Firewall-Profil zum Abschnitt Erweiterte Einstellungen, und klicken Sie auf Relaxationsregeln.

  4. Wählen Sie im Abschnitt Relaxationsregeln die Option Cookie-Konsistenz aus und klicken Sie auf Aktion.

  5. Legen Sie auf der Seite Regel zur Entspannung der Cookie-Konsistenz die folgenden Parameter fest.
    1. Aktiviert. Wählen Sie aus, ob Sie die Relaxationsregel aktivieren möchten.
    2. Ist Cookie-Name Regex. Wählen Sie aus, ob der Cookie-Name ein regulärer Ausdruck ist.
    3. Name des Cookies. Geben Sie den Namen des Cookie ein, das von der Cookie-Validierung ausgenommen werden kann.
    4. Regex-Editor. Klicken Sie auf diese Option, um die Details für reguläre Ausdrücke bereitzustellen.
    5. Kommentare. Eine kurze Beschreibung des Cookie.
  6. Klicken Sie auf Erstellen und Schließen.

Zeigen Sie Details zu Sicherheitsdatenverkehr und Sicherheitsverletzungen in einem tabellarischen oder grafischen Format an.

So zeigen Sie Sicherheitsstatistiken an:

Geben Sie in der Befehlszeile Folgendes ein:

stat appfw profile profile1

Appfw-Profil Verkehrsstatistiken Geschwindigkeit (/s) Gesamt
Anfragen 0 0
Byte anfragen 0 0
Antworten 0 0
Antwort Byte 0 0
Bricht ab 0 0
Leitet 0 0
Langfristige Reaktionszeit (ms) – 0
Letzte Reaktionszeit von Ave (ms) – 0
Statistik zu HTML/XML/JSON-Verstößen Geschwindigkeit (/s) Gesamt
Start-URL 0 0
URL verweigern 0 0
Referer-Header 0 0
Pufferüberlauf 0 0
Cookie-Konsistenz 0 0
Cookie-Entführung 0 0
CSRF-Formular-Tag 0 0
Site-übergreifendes HTML 0 0
HTML SQL injection 0 0
Feld-Format 0 0
Field consistency 0 0
Kreditkarte 0 0
Sicheres Objekt 0 0
Verstöße gegen die Signatur 0 0
Inhaltstyp 0 0
JSON-Denial-of-Service-Angriff 0 0
JSON-SQL-Einschleusung 0 0
JSON-Cross-Site Scripting 0 0
Dateiuploadtyp 0 0
Ableiten der XML-Nutzlast für Inhaltstypen 0 0
HTML-Befehlseinschleusung 0 0
XML-Format 0 0
XML-Denial-of-Service-Angriff (XDoS) 0 0
XML-Nachrichtenüberprüfung 0 0
Interoperabilität der Webdienste 0 0
XML SQL Injection 0 0
Site-übergreifende XML-Skrip 0 0
XML-Anhang 0 0
SOAP-Fehlerverletzungen 0 0
Generische XML-Verstöße 0 0
Verstöße insgesamt 0 0
HTML/XML/JSON-Protokollstatistiken Geschwindigkeit (/s) Gesamt
Starten der URL-Protokolle 0 0
URL-Protokolle verweigern 0 0
Referer-Header-Protokolle 0 0
Pufferüberlauf-Protokolle 0 0
Pufferüberlauf-Protokolle 0 0
Protokolle zur Cookie-Konsistenz 0 0
Protokolle zur Cookie-Entführung 0 0
CSRF-Formulartag-Protokolle 0 0
HTML-Cross-Site Scripting-Protokolle 0 0
HTML Cross-Site Scripting-Transformationsprotokolle 0 0
HTML SQL-Einschleusungsprotokolle 0 0
HTML SQL Transformationsprotokolle 0 0
Protokolle im Feldformat 0 0
Protokolle zur Feldkonsistenz 0 0
Kreditkarten 0 0
Protokolle zur Kreditkarten-Transformation 0 0
Sichere Objektprotokolle 0 0
Signatur-Protokolle 0 0
Inhalts-Typ-Protokolle 0 0
JSON-Denial-of-Service-Protokolle 0 0
JSON SQL-Einschleusungsprotokolle 0 0
JSON-Site-Scripting-Protokolle 0 0
Protokolle zum Hochladen von Dateien 0 0
Ableiten der XML-Nutzlast des Inhaltstyps L 0 0
HTML-Befehlseinschleusungsprotokolle 0 0
Protokolle im XML-Format 0 0
XML Denial of Service (XDoS) -Protokolle 0 0
Protokolle zur XML-Nachrichtenüberprüfung 0 0
WSI-Protokolle 0 0
XML SQL Injection-Protokolle 0 0
XML-Cross-Site Scripting-Protokolle 0 0
Protokolle für XML-Anhänge 0 0
SOAP-Fehlerlogs 0 0
Generische XML-Protokolle 0 0
Gesamtzahl der Protokollmeldungen 0 0
Statistiken zur Reaktion auf Serverfehler Geschwindigkeit (/s) Gesamt
HTTP-Client-Fehler (4xx Resp) 0 0
HTTP-Serverfehler (5xx) 0 0
  1. Navigieren Sie zu Sicherheit > Citrix Web App Firewall > Profile.
  2. Wählen Sie im Detailbereich ein Web App Firewall-Profil aus und klicken Sie auf Statistiken.
  3. Auf der Seite Statistiken der Citrix Web App Firewall werden die Details des Cookie-Hijacking-Datenverkehrs und der Verstöße angezeigt
  4. Sie können die Tabellarische Ansicht wählen oder zur grafischen Ansicht wechseln, um die Daten in einem tabellarischen oder grafischen Format anzuzeigen.

Statistiken zu Verstößen gegen Cookie-Hijacking auf der Citrix ADC GUI

Schutz vor Cookie-Hijacking
March 17, 2024
Beitrag von: 
C
March 17, 2024
Beitrag von: 
C

In diesem Artikel

Feedback zur Site | Your privacy choices footer linkIhre Datenschutzauswahl | Datenschutz und rechtliche Bestimmungen | Cookie-Einstellungen | Einstellungen für die Zustimmung | docs.cloud.com
© 1999- Cloud Software Group, Inc. All rights reserved.