Citrix ADC mit Google Chrome 80
Erstellt: Mittwoch 19. Februar 2020
Version: 1.0
Problembeschreibung
Die bevorstehende Chrome-Version, Chrome 80, wird das standardmäßige domänenübergreifende Verhalten von Cookies ändern. Diese Änderung wird die Sicherheit erhöhen, erfordert jedoch, dass Kunden und Partner Citrix ADC-Bereitstellungen, die auf Cookies basieren, testen.
Hinweis: Chrome 80 wird voraussichtlich am 4. Februar veröffentlicht, obwohl die Änderungen an den Cookies nur in einer begrenzten Phase ab dem 17. Februar erfolgen werden.
https://www.chromium.org/updates/same-site/
Auswirkungen auf den ADC
Mit dem Citrix ADC können 2 Arten von Cookies im Spiel sein:
- Fall 1: APP-Cookie: Cookie, das vom Backend-Anwendungsserver eingefügt wird.
- Fall 2: ADC-Cookie: Cookie eingefügt/im Besitz der Citrix ADC-Appliance
Wenn eine Anwendung nach dem Chrome-Update das Einfügen von Citrix ADC- (oder APP-) Cookies durch den Browser in einem standortübergreifenden Kontext erfordert (im Abschnitt «Hintergrund» weiter unten erläutert), wird der Chrome-Browser dies in wenigen Szenarien mit dem Chrome 80-Update nicht tun.
- Wenn APP-Cookies fehlen, kann dies zu einem Abbruch des Anwendungsflusses führen.
- Wenn ein ADC-Cookie in der nachfolgenden Anfrage fehlt, würde ADC es als eine neue Benutzeranfrage behandeln, und Persistenz wird nicht berücksichtigt, was zu einer Unterbrechung der Anwendung führt.
Impact auf Gateway und AAA
Für alle VPN- und AAA-Bereitstellungen nur innerhalb eines Iframe mit standortübergreifendem Kontext, die das Einfügen von Citrix Gateway- oder AAA-Cookies durch den Browser erfordern, gibt der Google-Chrome-Browser nach der Aktualisierung keine standortübergreifenden Cookies frei, was sich nur auf diese speziellen Bereitstellungen auswirkt und die Iframe-Komponente der Website nicht lädt.
Alle VPN– und AAA-Bereitstellungen mit demselben Website-Kontext oder ohne Iframes haben keine Auswirkungen und funktionieren nach dem Chrome-Update problemlos.
Hintergrund
Derzeit enthalten typische Browser das Cookie in HTTP-Anfragen in 2 Kontexten.
- Kontext der gleichen Website: Hier fordert der Benutzer den Browser auf, ihn zu einer bestimmten Domain zu bringen, für die der Browser das Cookie zuvor gespeichert hat.
- Website-übergreifender Kontext: Hier leitet eine Website eines Dritten den Benutzer zu einer Domäne um, für die der Browser das Cookie gespeichert hat, und der Browser schließt das Cookie bei der Anforderung der Webseite ein.
Im standortübergreifenden Kontext kann es zu CSRF-Angriffen (Cross Site Request Forgery) kommen, die dazu führen können, dass ein Angreifer die Sitzung des Benutzers stiehlt, um unerwünschte Aktionen im Namen des Benutzers durchzuführen. Um dies zu verhindern, empfiehlt RFC6265 bis, ein neues Attribut «SameSite» in das Cookie einzufügen, das dem Browser anzeigt, ob das Cookie für den Cross-Site-Kontext oder nur für den Kontext der gleichen Website verwendet werden kann. Auch wenn eine Anwendung beabsichtigt, im standortübergreifenden Kontext aufgerufen zu werden, kann sie dies nur über eine https-Verbindung tun.
Das SameSite-Attribut kann die folgenden Optionen annehmen.
- SameSite=Keine; Sicher
- Zeigt dem Browser an, dass der Cookie nur bei sicheren Verbindungen im standortübergreifenden Kontext verwendet wird.
- SameSite=Lax
- Zeigt dem Browser an, dass er das Cookie für Anfragen auf der gleichen Domäne verwenden soll, und dass nur sichere HTTP-Methoden wie die GET-Anfrage das Cookie verwenden können.
- SameSite=Streng
- Verwenden Sie das Cookie nur, wenn der Benutzer die Domäne explizit anfordert.
Hinweis: Wenn kein SameSite-Attribut im Cookie vorhanden ist, übernimmt der Chrome-Browser ab Februar 2020 die Funktionalität von SameSite=Lax. Der aktuelle Standardwert der SameSite-Einstellung ist None, was dem Browser die Verwendung von Cookies im Kontext von Drittanbietern ermöglicht.
Lösung
Optionen auf Konfigurationsebene zur Anpassung an diese Änderung werden in den Versionen 13.0, 12.1, 12.0 und 11.1 verfügbar sein, die bis zum 6. März 2020 veröffentlicht werden sollen.
Workaround
Workaround in Chrome
In Chrome 80 gibt es eine Option, die es Ihnen ermöglicht, zum alten Cookie-Verhalten zurückzukehren. Diese wird für mindestens 12 Monate nach der Veröffentlichung von Chrome 80 stabil verfügbar sein.
Weitere Informationen finden Sie unter SameSite Updates.
Workaround Steps for Case: 1 App cookie
Man kann eine antwortbasierte Neuschreibrichtlinie so konfigurieren, dass sie sich den «Set-Cookie»-Header in der vom Backend-Server gesendeten Antwort ansieht und das «SameSite»-Cookie-Attribut anhängt.
Ein Beispiel für eine Rewrite-Richtlinie sieht so aus:
add rewrite action rewrite_http_header replace_all http.RES.full_Header "\"SameSite=None; Secure; path=/\"" -search "regex(re!(path=/\\; SameSite)|(path=/)!)" add rewrite policy append_samesite_cookie "http.RES.HEADER(\"Set-Cookie\").EXISTS" rewrite_http_headerobige Umschreibungsrichtlinien müssen anwendungsspezifische virtuelle Server auf Citrix ADC gebunden werden.
Workaround Steps for Case: 2 ADC cookie (Persistence Use case)
Derzeit gibt es zwei Workarounds, um einen eventuellen Bruch (aufgrund des Chrom-Updates) von Anwendungen mit COOKIEINSERT-Persistenz, die auf LB vserver konfiguriert sind, zu verhindern.
1. Verwenden Sie eine RULE-basierte Persistenz der Antwort
Wenn die Backend-Anwendung ein eindeutiges Cookie für jede der Client-Sitzungen sendet, kann Citrix ADC diesen eindeutigen Cookie-Wert als Schlüssel verwenden und einen RULE-basierten Persistenzeintrag erstellen, der die Backend-Server-Informationen speichert, die dem empfangenen Cookie entsprechen. Wenn die Clientanforderung mit diesem Cookie zurückkommt, verwendet Citrix ADC den Cookie-Wert als Schlüssel und holt den entsprechenden Backend-Server, um die Anforderung weiterzuleiten, wodurch die durch die COOKIEINSERT-Persistenz erreichte Klebrigkeit beibehalten wird. Dieser Ansatz funktioniert nur dann, wenn der Backend-Server für jeden Client in der Antwort ein eindeutiges Cookie-Schlüssel/Wert-Paar sendet.
Unten finden Sie eine Beispielkonfiguration, bei der der Back-End-Server ein Cookie mit dem Schlüssel als SESSIONID sendet. Die SESSIONID in der folgenden Konfiguration muss durch den vom Backend gesendeten eindeutigen Cookie-Schlüssel ersetzt werden.
set lb vserver lbvs -persistenceType RULE -rule "HTTP.REQ.COOKIE.VALUE(\"SESSIONID\")" -resRule "HTTP.RES.SET_COOKIE.COOKIE(\"SESSIONID\").VALUE(0)"2. Zweistufige Topologie mit einer neuen Citrix ADC-Front, die die bestehenden Citrix ADCs beendet
Der Kunde kann eine zweistufige Topologie mit einer neuen Citrix ADC-Front haben, die den Datenverkehr für den Tier-2-Citrix ADC (bestehender Citrix ADC) beendet. Der erste Citrix ADC der ersten Schicht schreibt die Antwort neu, um das SameSite-Attribut für alle Cookies, die vom Tier-2-Citrix ADC empfangen werden, zu berücksichtigen.
Für das Tier-2-Citrix-ADC sind keine Konfigurationsänderungen erforderlich.
Unten ist eine Beispielkonfiguration für das Tier-1-Citrix-ADC aufgeführt.
enable feature lb rewrite
add lb vserver tier-1-lb <protocol> <IP> <port>
add service tier-2-lb-svc <tier-2-vserver-IP> <tier-2-vserver-protocol> <tier-2-vserver-port>
bind lb vserver tier-1-lb tier-2-lb-svc
add rewrite action rewrite_http_header replace_all http.RES.full_Header "\"SameSite=None; Secure; path=/\"" -search "regex(re!(path=/\\; SameSite)|(path=/)!)"
add rewrite policy append_samesite_cookie "http.RES.HEADER(\"Set-Cookie\").EXISTS" rewrite_http_header
bind lb vserver tier-1-lb -policyname append_samesite_cookie -priority 10 -type RESPONSEHinweis: Dies sollte auch dann funktionieren, wenn der Back-End-Server kein eigenes Cookie enthält.
