Single Sign-On News

Kehrtwende: Third-Party Cookies in Chrome bleiben unverändert bestehen 🍪🍪🍪

Im letzten Jahr hat uns das geplante Ende der Unterstützung von Third-Party Cookies in Google Chrome wiederholt beschäftigt. Von dem Zeitplan Third-Party Cookies bis Ende 2024 komplett zu entfernen (Q1/2024), über die Anpassung des Zeitplans (Q2/2024), bis hin zur späteren Abkehr vom ursprünglichen Plan (Q3/2024).

Anfang April 2025 hat Google nun bekannt gegeben, dass die aktuelle Umsetzung in Google Chrome bestehen bleibt, die “den Nutzer*innen in Chrome die Wahlfreiheit” in Bezug auf die Verwendung von Third-Party Cookies lässt. Erneut wird diese Abkehr von der geplanten Strategie mit Feedback aus dem “Ökosystem” (Publishern, Entwickler*innen, Aufsichtsbehörden und der Werbebranche) begründet.

Für Single Sign-On Flows im Browser, die direkt von dem Aus der Third-Party Cookies betroffen gewesen wären, ist Googles Entscheidung eine Entwarnung. Für Nutzende von Google Chrome, die nicht manuell die Unterstützung für Third-Party Cookies deaktivieren, hingegen bedeutet Googles Entscheidung, dass eine geplante Stärkung ihrer Privatsphäre bei der Verwendung von Google Chrome ausbleibt.

Kritische Schwachstelle in der node.js SAML-Library “samlify”

Eine von Endor Labs im Mai veröffentlichte Schwachstelle in der SAML-Library “samlify” erlaubt es angreifenden Personen, sich in Anwendungen als beliebige User (z. B. Admins) zu authentifizieren. Der Schwachstelle liegt ein simpler Fehler in der Verarbeitung der signierten SAML-Assertions zugrunde. Dieser Fehler ermöglicht sogenannte “XML Signature Wrapping” (XSW)-Angriffe*. Github stuft die Schwachstelle mit dem höchstmöglichen CVSS-Score von 9.9 als kritisch ein. Anwendungen, die samlify in Versionen < 2.10.0 einsetzen, sollten daher schleunigst auf die neueste Version der Library aktualisiert werden.

* Eine Erklärung zu XSW-Angriffen finden Sie in unserem Blogpost. Wir berichten dort von einer ähnlichen Schwachstelle, die wir vor einigen Jahren im Rahmen eines Penetrationstests in einer SAML-Library für PHP entdeckt haben.

Draft Updates

Im vergangenen Quartal wurden eine Vielzahl neuer Drafts oder Draft Versionen in der Sphäre von OAuth veröffentlicht. Unter anderem die Folgenden:

• In der letzten Ausgabe des Hackletters wurde in den SSO News auf eine Schwachstelle im Zusammenhang mit JWTs, die zur Client-Authentifizierung verwendet werden (RFC 7523 bzw. OIDC), hingewiesen. Diese Schwachstelle besteht darin, dass eine angreifende Person u. U. ein JWT, welches von einem Client signiert wurde, missbrauchen kann. Dadurch könnten sich angreifende Personen im Namen des Clients authentifizieren. Die Schwachstelle resultiert aus der unterschiedlichen Definition des “Audience”-Claims (aud) in verschiedenen OAuth-Spezifikationen, die JWTs verwenden. Dieser Claim gibt an, wer der beabsichtigte Empfänger des Tokens ist. Betroffen von dieser Schwachstelle sind nur Clients, die mehrere Authorization Server / Identity Provider unterstützen.
  Der Draft mit dem (Arbeits-)Titel “Updates to Audience Values for OAuth 2.0 Authorization Servers” (rfc7523bis) soll RFC 7523 und weitere betroffene RFCs mit Gegenmaßnahmen aktualisieren. Das Dokument legt fest, dass der “Audience”-Claim ausschließlich den “Issuer Identifier” des Authorization Servers enthalten soll. Dieser Identifier findet sich z. B. in den Metadaten des IdPs und wird bei Tokens, die der IdP ausstellt, in den “Issuer”-Claim (iss) geschrieben. In Q2 ist eine neue Version des Drafts rfc7523bis erschienen. Zuvor wurde auf der Mailingliste und auf IETF-Konferenzen diskutiert, wie der Aufbau des Dokuments möglichst klar und verständlich ist und das Dokument gleichzeitig möglichst zeitnah fertiggestellt werden kann. So soll gewährleistet werden, dass die identifizierten Schwachstellen schnell und effektiv von Entwickler:innen von Libraries und Frameworks behoben werden können.
  
  
• Mitte April wurde RFC 9728 (“OAuth 2.0 Protected Resource Metadata”) final veröffentlicht. In dem RFC wird ein Format definiert, um Metadaten von Ressourcen zu beschreiben. Mithilfe dieser Metadaten können OAuth Clients oder Authorization Server erfahren, wie sie mit den Ressourcen interagieren.
  
  
• In Q2 wurden für den Draft “Selective Disclosure for JWTs (SD-JWT)” vier neue Versionen veröffentlicht, die kleine Fehler aus einem letzten Feedback korrigieren und redaktionelle Verbesserungen umsetzen. Ende Mai wurde Draft #22 von der IESG (einem leitenden Gremium der IETF) angenommen. Damit ist der Draft inhaltlich final und es folgt nur noch eine weitere redaktionelle Überarbeitung durch den “RFC Editor", bevor der Draft als RFC veröffentlicht wird. Die Veröffentlichung könnte in Q3 erfolgen. SD-JWTs erlauben es, ausgewählte Claims eines JWTs preiszugeben und dabei alle anderen Claims geheim zu halten. Dies kann u. A. im Kontext von “Verifiable Credentials” verwendet werden, um z. B. nur preiszugeben, dass eine Person volljährig ist, ohne dabei weitere persönliche Informationen (Geburtsdatum, Name, …) zu verraten. Es befindet sich bereits ein Draft in der Entwicklung für Verifiable Credentials basierend auf SD-JWTs.
  
  
• Zum Ende von Q1 wurde in der OAuth Working Group dazu aufgerufen, letzte Kommentare zu dem Draft “Status Token Lists” abzugeben. Diesem Aufruf sind einige Personen gefolgt und haben offene Probleme und Unklarheiten im Dokument bemängelt. Nachdem einige der bemängelten Punkte behoben wurden, konnte eine Einigung erzielt werden, dass das Dokument von der Working Group als “fertig” angesehen wird. Danach folgte der Shepherd's Review eines der “Working Group Chairs”; im Zuge dessen wurden einige kleinere Verbesserungen vorgeschlagen und in Draft-Version 11 umgesetzt. Im nächsten Schritt wird sich bald die IESG mit dem Draft beschäftigen und ebenfalls Kritik, Verbesserungsvorschläge und Rückfragen äußern.
  
  
• Für die zukünftige Version OAuth 2.1 wurde in Q2 eine neue Draft-Version veröffentlicht. Diese enthält jedoch nur minimale Änderungen und dient hauptsächlich dazu, dass der Draft wieder als “Active” im Datatracker der IETF angezeigt wird. Zuvor hatte dort der Status “Expired” zu der Frage geführt, ob Version 2.1 von OAuth noch gearbeitet wird. Die Arbeiten im Hintergrund dauern an, während die Autor:innen zuletzt andere Dokumente stark weitergebracht haben (z. B. “OAuth 2.0 for Browser-Based Applications”, siehe Hackletter Q1/2025).
  
  
• Auch für den Draft “Cross-Device Flows: Security Best Current Practice” wurde eine neue Draft-Version mit kleineren Änderungen veröffentlicht. In dem Draft werden Bedrohungen und Gegenmaßnahmen für sogenannte “Cross-Device Flows” beschrieben. Gemeint sind damit Flows, bei denen mehrere Geräte beteiligt sind. Ein typisches Beispiel ist das Einloggen auf einem Smart TV unter Zuhilfenahme eines Smartphones, auf dem die eigentliche Autorisierung bzw. Authentifizierung des Users stattfindet. Die Personen der Working Group haben den Inhalt des Drafts bereits seit Q2/2024 als “fertig” angesehen. Seitdem wartet der Draft auf den nächsten Schritt auf dem Weg zur Veröffentlichung als RFC: Die Reviews und das Umsetzen von Feedback aus diesen Reviews von anderen Gremien innerhalb der IETF.
  
  

Fragen, Ausblick und Diskussionen

• Nachdem wir in der letzten Ausgabe des Hackletters die finale Veröffentlichung von RFC 9700 – “Best Current Practice for OAuth 2.0 Security” – verkündigen konnten, gibt es nun bereits einen ersten Draft, der ein Update für bzw. eine Erweiterung zu RFC 9700 darstellen soll. Bisher wurde dieser Draft (“Updates to OAuth 2.0 Security Best Current Practice”) allerdings nur als “Individueller Draft” veröffentlicht, d. h. er wurde von Individuen veröffentlicht und nicht offiziell unter Bearbeitung der OAuth Working Group. Wenn die Working Group den Inhalt für sinnvoll hält, kann sie den Draft “adoptieren” und später im OAuth-Kontext veröffentlichen. Es wurde innerhalb der Working Group von vornherein erwartet, dass nach Veröffentlichung von RFC 9700 ein neues Dokument mit neuen Sicherheitsempfehlungen begonnen wird – sobald neue Angriffe entdeckt werden, die neue Empfehlungen und Gegenmaßnahmen erfordern.
  
  Der nun veröffentlichte individuelle Draft befindet sich in einem sehr frühen Stadium. Adressiert werden in der aktuellen Fassung:
  • “Audience Injection Attacks”
    Damit sind die Angriffe gemeint, die mit rfc7523bis verhindert werden sollen, siehe Draft Updates oben.
  • Neue Varianten und Anwendungsfälle für “Mix-Up Attacks”
    Ein Beispiel für eine bereits zuvor bekannte Variante und die dafür passende Gegenmaßnahme finden Sie in unserem englischsprachigen Blogpost zu Mix-Up Attacks.
    
    
• Anfang Juni wurde mit “Deferred Key Binding for OAuth” ein individueller Draft zur Diskussion gestellt. Mit dem Draft soll ein Verfahren definiert werden, das es erlaubt, ein Token an einen Schlüssel zu binden, den die anfragende Partei nicht selbst besitzt. Es wurden Bedenken geäußert, dass dieses Verfahren die Sicherheitsannahmen, die bei Proof-of-Possession (PoP)-Verfahren getroffen werden, aufheben könnte. Dementgegen bestätigen mehrere Personen, dass in der Praxis bereits vergleichbare Verfahren verwendet werden und es somit einen Bedarf gibt, eine Lösung zu standardisieren.
  
  
• Ende Juni wurde von demselben Autor ein weiterer individueller Draft auf der OAuth Mailingliste vorgestellt und diskutiert. Der Draft zur “Pushed Client Registration” sieht vor, dass zuvor unregistrierte Clients ihre Metadaten zur Client Registrierung als Teil eines “Pushed Authorization Requests” (PAR, RFC 9126) mit schicken. Dies soll Einschränkungen bzgl. der Verwendung einer fixen Client ID bei kurzlebigen und hochdynamischen Clients umgehen. Diskutiert werden die Unterschiede zu der bereits bestehenden Dynamic Client Registration (RFC 7591). Zudem werden Bedenken hinsichtlich des “Trust Modells” und der Verwaltung der Token von solchen kurzlebigen Clients geäußert.
  
  
• Auf der Mailingliste der “AB/Connect”-Working Group der OpenID Foundation (in der u. A. OpenID Connect standardisiert wurde) wurde die Frage aufgeworfen, wie eine Partei kommunizieren kann, wenn in einem Feld, das üblicherweise eine Gültigkeitsdauer oder Timestamp enthält (z. B. Ablaufzeitpunkt eines Refresh Tokens), “unendlich” bzw. eine unbegrenzte Gültigkeit stehen soll. Es wurden verschiedene Optionen diskutiert; bis jetzt mit keinem eindeutigen Ergebnis. Passend dazu hat derselbe Autor vor wenigen Tagen einen individuellen Draft (“OAuth 2.0 Refresh Token and Consent Expiration”) vorgestellt, der zu der Token Response des Authorization Servers ein Feld für die Gültigkeitsdauer des ausgestellten Refresh Tokens hinzufügt. Die Frage nach dieser Information wurde im Kontext von OAuth 2.1 bereits wiederholt aufgeworfen und ebenfalls diskutiert.
  
  

Immer informiert – Abonnieren Sie jetzt den Hackletter!

Melden Sie sich noch heute für den Hackletter an und verpassen Sie keine spannenden Ausgaben.
Erhalten Sie exklusive Insights zu neuesten Entwicklungen und Updates rund um Single Sign-On einmal
im Quartal direkt in Ihr Postfach. 

>> Anmeldung zum Hackletter

Unsere Experten:innen entwickeln die optimale Lösung für Sie

Single Sign-On – OAuth – FAPI

Stehen Sie vor der Entscheidung, wie Sie Ihr IAM-Szenario und Ihre Kundendaten optimal schützen können? Oder verwenden Sie OAuth/OpenID Connect bereits und fragen sich, ob Ihre Single Sign-On Implementierung sicher ist?

Wir beraten Sie gerne; kontaktieren Sie uns für eine unverbindliche Erstberatung. So stehen wir Ihnen mit folgenden Services und Lösungen zur Seite:

IT-Sicherheitsberatung  |  Schulungen   |  Penetrationstests

Zögern Sie nicht und finden Sie mit uns Ihren Weg zu sicherem Single Sign-On. Wir freuen uns darauf Sie bei Ihren Projekten zu unterstützen.

Ihr Ansprechpartner für Single Sign-On und sichere API

Karsten Meyer zu Selhausen
karsten.meyerzuselhausen@hackmanit.de