Das Obsidian Security Research Team hat einen persistenten Angriffsvektor, Shadow Linking, aufgedeckt, der es Bedrohungsakteuren ermöglicht, über OpenID Connect (OIDC) Login dauerhaften Zugang zu den SaaS-Konten der Opfer zu erhalten. Mitarbeiter können diese Technik auch missbrauchen, um selbst nach ihrem Ausscheiden aus dem Unternehmen weiterhin Zugriff auf Unternehmensressourcen zu erhalten. Viele Anwendungen sind nicht ausreichend gegen solche Angriffe geschützt, was sowohl für Einzelpersonen als auch für Unternehmen eine große Herausforderung darstellt. Dieses Problem betrifft mehrere beliebte SaaS-Anwendungen, darunter OpenAI, Zoom, Slack, Atlassian, Twitter, Expensify und Notion.
Hintergrund
Zahlreiche SaaS-Anwendungen haben Single Sign-On-Dienste (SSO) für ihre Authentifizierungsabläufe übernommen. Soziale Identitätsanbieter (IdPs) wie Google, Apple, Microsoft und Facebook genießen aufgrund ihrer weiten Verbreitung ein hohes Maß an Vertrauen.
Unsere Untersuchungen haben jedoch gezeigt, dass Anwendungen häufig nicht korrekt mit diesen IdPs integriert werden, was die Sicherheit dieser SaaS-Anwendungen untergräbt. Hierfür gibt es zwei Hauptgründe:
Beliebige Registrierung von E-Mail-Adressen bei IdPs
Viele Unternehmen unterschätzen, wie einfach E-Mail-Adressen von Organisationen bei fast allen Identitätsanbietern registriert werden können. So kann beispielsweise eine bei Google Workspace verwaltete E-Mail-Adresse zur Registrierung bei anderen Identitätsanbietern wie Apple und Microsoft verwendet werden.
Persönliche E-Mail-Adressen, die von einem Identitätsanbieter verwaltet werden, können auch zur Registrierung von Konten bei einem anderen Anbieter verwendet werden. So kann beispielsweise eine Google-E-Mail-Adresse (z. B. gmail.com) zur Registrierung eines Apple-Kontos und eine Microsoft-E-Mail-Adresse (z. B. outlook.com) zur Registrierung eines Google-Kontos verwendet werden.
Tatsächlich können Sie sich bei allen gängigen Identitätsanbietern mit fast jeder E-Mail-Adresse registrieren, unabhängig von deren Herkunft. Für die Registrierung ist in der Regel nur ein einmaliger Nachweis des Besitzes erforderlich, z. B. die Vorlage eines Verifizierungscodes, der an die E-Mail-Adresse gesendet wird.
OpenID-Verbindung
OIDC ist ein Authentifizierungsprotokoll, das auf dem OAuth 2.0 Framework (RFC 6749) aufbaut. Als eines der am häufigsten implementierten SSO-Protokolle wird OIDC von zahlreichen Identitätsdienstanbietern genutzt und in eine Vielzahl von Anwendungen integriert, um die Authentifizierung von Drittanbietern zu erleichtern.
OIDC sichert in erster Linie den Prozess der Benutzerauthentifizierung, indem es Anwendungen ermöglicht, Benutzer über IdPs von Drittanbietern wie Google zu authentifizieren. Nach erfolgreicher Authentifizierung gibt der IdP ein ID-Token mit den grundlegenden Informationen des Benutzers an die Anwendung aus. Dieses Token dient als Nachweis für die Identität des Benutzers. Es ist jedoch nicht festgelegt, wie Anwendungen das ID-Token für die Benutzeridentifizierung und Kontoverknüpfung verwenden sollen. Die Anwendung trägt die Verantwortung für die Zuordnung des erhaltenen ID-Tokens zu den entsprechenden internen Benutzerkonten.
Diskrepante Abhängigkeit von ID-Token-Ansprüchen
Ein ID-Token, der von Identitätsanbietern im JSON-Format ausgestellt wird, enthält mehrere Angaben, die die grundlegenden Informationen des Benutzers, wie Name, ID und E-Mail-Adresse, enthalten. Anwendungen nutzen diese Angaben zur Authentifizierung von Endbenutzern. Ein typisches ID-Token, das vom Identitätsdienst von Google ausgestellt wurde, veranschaulicht diese Struktur.
Ein ID-Token, der von Identitätsanbietern im JSON-Format ausgestellt wird, enthält mehrere Angaben, die die grundlegenden Informationen des Benutzers, wie Name, ID und E-Mail-Adresse, enthalten. Anwendungen nutzen diese Angaben zur Authentifizierung von Endbenutzern. Ein typisches ID-Token, das vom Identitätsdienst von Google ausgestellt wurde, veranschaulicht diese Struktur.
Ein ID-Token, der von Identitätsanbietern im JSON-Format ausgestellt wird, enthält mehrere Angaben, die die grundlegenden Informationen des Benutzers, wie Name, ID und E-Mail-Adresse, enthalten. Anwendungen nutzen diese Angaben zur Authentifizierung von Endbenutzern. Ein typisches ID-Token, das vom Identitätsdienst von Google ausgestellt wurde, veranschaulicht diese Struktur.
Obwohl OpenID Connect betont, dass Anwendungen Benutzer eindeutig identifizieren sollten, indem sie den Sub-Claim (einen eindeutigen Identifikator für ein Drittanbieterkonto) verwenden, wie definiert:
„Die sub (subject) und issuer (issuer) Claims des ID Tokens, die zusammen verwendet werden, sind die einzigen Claims, auf die sich ein RP (relying party) als stabiler Identifikator für den Endbenutzer verlassen kann. Bei allen anderen Claims gibt es keine Garantien für die zeitliche Stabilität oder die Einzigartigkeit über verschiedene Emittenten hinweg.“
Dieser Ansatz wird nicht immer beachtet und von den Anwendungen weitgehend übernommen.
Schatten-Verknüpfung
Viele Anwendungen, wie z. B. OpenAI, stützen sich auf die Angabe der E-Mail-Adresse, um Benutzer eindeutig zu identifizieren und Benutzerkonten zu verknüpfen. Um dies zu verdeutlichen, betrachten Sie einen Benutzer mit einem OpenAI-Konto, das mit einer E-Mail-Adresse registriert ist (victim@domain.com). Wenn ein soziales Schatten-IdP-Konto, wie z. B. Apple, mit derselben E-Mail-Adresse erstellt wird (victim@domain.com) und dieses Apple-Konto zur Authentifizierung bei OpenAI über Apples OIDC-Login verwendet wird, wird es als dasselbe Konto authentifiziert, ohne dass eine zusätzliche Überprüfung erforderlich ist. Dies zeigt, dass das Apple-Konto automatisch mit dem OpenAI-Konto des Opfers verknüpft ist.
Aus dieser Beobachtung schlossen wir, dass OpenAI unabhängig davon, von welchem Identitätsdienst eines Drittanbieters sich der Benutzer anmeldet, solange die E-Mail-Adresse des Drittanbieters mit einem der internen Konten übereinstimmt, den Drittanbieter-Endbenutzer ohne weitere Überprüfung mit diesem internen Konto verknüpft und zusammenführt. Dieses Verhalten wird in vielen Anwendungen beobachtet.
Dies ist problematisch. Betrachten Sie zwei Szenarien, in denen dieses Verhalten ein erhebliches Sicherheitsrisiko darstellen kann:
- Kompromittierung eines E-Mail-Kontos: Ein Bedrohungsakteur kompromittiert das Google Mail-Konto eines Benutzers und registriert mit dessen E-Mail-Adresse Konten bei Apple, Facebook, Microsoft und anderen IdP-Anbietern. Da diese Konten von Drittanbietern vollständig von dem Bedrohungsakteur verwaltet werden und die E-Mail-Überprüfung nur einmal während der Registrierung erfolgt, kann der Bedrohungsakteur diese Konten nutzen, um auf alle persönlichen und organisatorischen Ressourcen des Opfers zuzugreifen. Dieser Zugriff bleibt auch dann bestehen, wenn der Bedrohungsakteur die Kontrolle über die E-Mail des Opfers verloren hat. Dies stellt eine ernsthaftere Bedrohung dar als der Missbrauch von Kontoverknüpfungsfunktionen innerhalb einzelner SaaS-Anwendungen, da es nicht erforderlich ist, das SaaS-Konto selbst zu kompromittieren. Darüber hinaus ermöglicht es die Übernahme zukünftiger SaaS-Konten, die das Opfer möglicherweise erstellt, selbst wenn diese derzeit nicht existieren.
- Missbrauch von Organisationsmitgliedern: Ein Mitglied einer Google Workspace-Organisation kann mit der E-Mail-Adresse seiner Organisation Konten bei Apple, Facebook, Microsoft und anderen IdP-Anbietern registrieren. Diese Konten von Drittanbietern werden vollständig vom Nutzer verwaltet, nicht von der Organisation, und die E-Mail-Adresse wird nur einmal während des Registrierungsprozesses überprüft. So kann das Organisationsmitglied diese Konten nutzen, um über verschiedene Anwendungen auf die internen Ressourcen der Organisation zuzugreifen, auch nachdem es die Organisation verlassen hat.
Eine Anwendung, die einem fremden Endbenutzer eine Kontositzung nur auf der Grundlage einer E-Mail-Adresse ohne zusätzliche Überprüfung gewährt, nennen wir Shadow Linking. Unsere Tests haben ergeben, dass Shadow Linking fast überall vorkommt. Ein kompromittiertes Konto eines Drittanbieters kann als Skeleton Key fungieren, der für zahlreiche Anwendungen als „Shadow Link“ fungiert und in Bezug auf die Persistenz perfekt funktioniert.
Testfälle
Während unserer Untersuchung haben wir neun verschiedene beliebte Anwendungen getestet, sowohl Einzel- als auch Unternehmensversionen, unter der Annahme, dass sie OIDC-Authentifizierung verwenden (was sie standardmäßig tun).
Unsere Beobachtung zeigt, dass 7 von 9 Anwendungen für Shadow Linking anfällig sind. Die Testergebnisse sind im Folgenden zusammengefasst:
| Application | Identification Claim | Vulnerable to Shadow Linking (without 2FA by default) | Vulnerable (with 2FA enabled) / 2FA Bypass | Set 2FA Without Extra Verification | Manage IdP Links (disable or occupy) | Modify Email Address | Cost to Enable SAML SSO |
| Zoom | ☠️ | 🚫(basic) 👍(pro-) |
🚫(basic) 👍(pro-) |
☠️ | 👍 | $21.99/month/user | |
| Notion | ☠️ | ☠️ | 👍 | ☠️ | 👍 | $15/month/user | |
| Atlassian | ☠️ | ☠️ | 👍 | ☠️ | 👍 | $11.75/month/user | |
| Slack | ☠️ | 👍 | ☠️ | ☠️ | 👍 | $15/month/user | |
| OpenAI | ☠️ | ☠️ | ☠️ | ☠️ | ☠️ | $60/month/user | |
| Expensify | ☠️ | ☠️ | ☠️ | ☠️ | 👍 | $9/month/user | |
| X | ☠️ | 👍 | 👍 | ☠️ | 👍 | 🚫 | |
| GitLab | Sub | 👍 | 👍 | ☠️ | 👍 | 👍 | 👍 |
| Shopify | Sub | 👍 | 👍 | ☠️ | 👍 | 👍 | 👍 |
Legend:
☠️ – Vulnerable
👍 – Secure
🚫 – Not Available
(basic) – Applies to Zoom’s basic subscription
(pro-) – Applies to Zoom’s pro subscription and higher
Die Durchsetzung von SAML SSO ist die beste Methode, um sich gegen Schattenverknüpfungen in der Unternehmensumgebung zu schützen. SAML SSO ist jedoch oft nur als Teil des „Enterprise“-Preises in Anwendungen verfügbar. Gemäß der „SSO-Steuer“ können Anbieter den doppelten, dreifachen oder vierfachen Preis des Basisprodukts für den Zugang zu SSO verlangen, was kleine Unternehmen davon abhält, SSO zu nutzen, und sie anfälliger macht als größere Unternehmen.
Wir haben auch die Möglichkeit untersucht, Abwehrmaßnahmen und Reaktionen auf Vorfälle zu umgehen, sobald eine Schattenverknüpfung stattgefunden hat. Unsere Ergebnisse zeigen, dass es bei vielen Anwendungen keine wirksamen Maßnahmen zur aktiven Abwehr oder Abschwächung der Auswirkungen von Schattenverknüpfungen gibt, sobald diese hergestellt wurden. Dies gibt dem Angreifer die Möglichkeit, dauerhaft zu verweilen und das Opfer sogar auszusperren, sobald der Angreifer einmal Fuß gefasst hat. Wir werden dies weiter erörtern.
2FA-Umgehung
Die Zwei-Faktor-Authentifizierung (2FA) soll den Anwendungen eine zusätzliche Sicherheitsebene verleihen. Viele Anwendungen verlassen sich jedoch vollständig auf Identitätsdienste von Drittanbietern und wenden 2FA nicht auf SSO-Anmeldungen an, selbst wenn die Benutzer sie aktiviert haben. Unsere Testergebnisse zeigen, dass 5 von 7 anfälligen Anwendungen die 2FA ignorieren, wenn sich ein Benutzer über SSO anmeldet. Dieses Versäumnis führt zu schwerwiegenden Sicherheitsproblemen, da es Angreifern ermöglicht, Abwehrmechanismen zu umgehen und dauerhaften Zugriff auf das Konto des Opfers zu erhalten.
Atlassian gibt beispielsweise ausdrücklich an, dass die zweistufige Verifizierung nicht auf SSO-Anmeldungen von Drittanbietern angewendet wird.
Darüber hinaus haben unsere Testfälle gezeigt, dass alle anfälligen Anwendungen nicht über die Funktion verfügen, ein Drittanbieterkonto zu entkoppeln oder zu deaktivieren. In Kombination mit der Umgehung der 2FA bietet dies den Angreifern die Möglichkeit, die Konten der Opfer nach dem Angriff dauerhaft zu übernehmen.
2FA-Missbrauch
Unsere Untersuchungen haben auch ergeben, dass viele Anwendungen bei der Einrichtung von 2FA keine zusätzliche Überprüfung verlangen, wie in unseren Testfällen mit Slack, OpenAI und Expensify zu beobachten war. Diese unzureichende Verifizierung ermöglicht es Bedrohungsakteuren, 2FA zu missbrauchen, um die alleinige Kontrolle über das Zielkonto zu erlangen und den legitimen Benutzer effektiv auszusperren.
So sind beispielsweise die Produkte von OpenAI, einschließlich des sehr beliebten ChatGPT und seiner API-Plattform, sowohl für Shadow Linking- als auch für MFA-Angriffe (Multi-Factor Authentication) anfällig. OpenAI implementiert 2FA so, dass sich Benutzer nach der Aktivierung von 2FA mit der gleichen Authentifizierungsmethode eines Drittanbieters anmelden müssen, die bei der Einrichtung von 2FA verwendet wurde. Der Einrichtungsprozess erfordert nur die Überprüfung des aktuell angemeldeten Drittanbieterkontos, was unzureichend ist und ein falsches Gefühl der Sicherheit vermittelt.
Infolgedessen können Angreifer diese Funktion leicht ausnutzen, um 2FA zu aktivieren, wodurch alle anderen Authentifizierungsmethoden deaktiviert werden und eine vollständige Übernahme des Kontos erreicht wird, was zu einer vollständigen Aussperrung des Opfers führt.
Können Nutzer einfach ihre Telefonnummer oder E-Mail-Adresse verwenden, um das Konto wiederherzustellen? Leider stellt OpenAI die Telefonverifizierung ein und hat Probleme mit der E-Mail-Zustellung. Außerdem ist es unmöglich, die mit dem Konto verknüpfte E-Mail-Adresse zu ändern. Bis heute gibt es keine Möglichkeit, ein Konto wiederherzustellen, das auf diese Weise übernommen wurde.
Erkennung
Auch wenn die Erkennung eine Herausforderung darstellt, kann das Blue Team dennoch wertvolle Informationen aus den Protokollen der Anmeldeaktivitäten des Benutzers gewinnen. Durch die Analyse der Metadaten von Anmeldeereignissen – z. B. die Authentifizierungsmethode (Passwort, OIDC, SAML SSO usw.), der verwendete IdP eines Drittanbieters, die IP-Adresse und der Zeitstempel – kann das Blue Team bösartige Aktivitäten identifizieren, indem es diese Details mit anderen Kompromittierungen und Ereignissen korreliert.
Bei unseren Recherchen haben wir festgestellt, dass nicht alle anfälligen Anwendungen umfassende Protokolle zur Verfügung stellen, die eine Erkennung unterstützen. So stellt Slack beispielsweise nur Zugriffsprotokolle zur Verfügung, die die Anmeldeaktivitäten der Benutzer ohne Details wie Anmeldetyp und SSO-Quellen beschreiben. Andere Anwendungen, wie z. B. Atlassian, bieten nicht einmal anmeldebezogene Aktivitätsprotokolle. Das Fehlen von detaillierten Anmeldeprotokollen macht es schwer, Shadow Linking überhaupt zu erkennen.
Obsidian empfohlene Abhilfemaßnahmen
Für Anwendungsentwickler
- Verknüpfen Sie Konten von Drittanbietern basierend auf dem Unteranspruch
Wenn ein ID-Token mit einer E-Mail-Adresse, die mit einem bestehenden Konto übereinstimmt, zum ersten Mal vorgelegt wird, verlangen Sie vom Benutzer, dass er zuerst das bestehende Konto authentifiziert, oder fordern Sie den Benutzer auf, das Konto über das Benutzerportal zu verknüpfen, anstatt das Drittanbieterkonto automatisch mit dem bestehenden Konto zu verknüpfen und zusammenzuführen. Nach der Authentifizierung verknüpfen Sie das Konto mit dem Unteranspruch im ID-Token. Dieser Prozess stellt sicher, dass der aktuelle Benutzer des Drittanbieters tatsächlich der rechtmäßige Eigentümer des Kontos ist. Anwendungen wie GitLab und Shopify setzen diese Methode ein, um Shadow Linking von vornherein wirksam zu verhindern.
- Umfassende Verwaltung der Verknüpfung von Drittanbietern
Erhöhen Sie die Sicherheit, indem Sie den Benutzern Transparenz und vollständige Kontrolle über den SSO-Verknüpfungsprozess geben, einschließlich der Möglichkeit, die Verknüpfung von Drittanbieterkonten aufzuheben und bestimmte Drittanbieter-Anmeldungen sowohl in Einzel- als auch in Unternehmens-Setups zu deaktivieren. Unsere Testfälle haben gezeigt, dass nur 2 von 9 Anwendungen ausreichende Funktionen bieten, um den Shadow Linking-Angriff zu entschärfen.
- Anwendung von 2FA auf die Anmeldung bei Drittanbietern
Wenn Benutzer 2FA aktivieren, sollten Anwendungen auch 2FA für die Anmeldung bei Dritten erzwingen. Diese Maßnahme entschärft den Shadow Linking-Angriff und beugt weiteren Bedrohungen durch 2FA-Missbrauch und -Umgehung vor.
- Erfordern Sie eine zusätzliche Verifizierung vor der Einrichtung von 2FA
Stellen Sie sicher, dass bei der Einrichtung von 2FA über das Benutzerportal eine zusätzliche Benutzerüberprüfung erforderlich ist. Durch diesen zusätzlichen Schritt wird die Identität des Benutzers bestätigt und 2FA-Missbrauchsangriffe werden abgeschwächt.
- Unterstützung detaillierter Anmeldeprotokolle für Sicherheitsaudits
Stellen Sie sicher, dass detaillierte Metadaten zu Anmeldeereignissen aufgezeichnet werden, einschließlich der Authentifizierungsmethode (Passwort, OIDC, SAML SSO usw.), des verwendeten Drittanbieter-IdP, der IP-Adresse und des Zeitstempels.
Für Endbenutzer
Endbenutzer sollten proaktive Maßnahmen ergreifen, um die potenziellen Auswirkungen von Shadow Linking abzuschwächen.
- 2FA erzwingen
Aktivieren Sie die Zwei-Faktor-Authentifizierung (2FA) für alle Konten, sofern möglich.
- Einrichten eines Passworts
Das Einrichten eines Passworts für ein Konto kann zusätzliche Sicherheit bieten, ähnlich wie die Aktivierung von 2FA. Wenn Sie sich beispielsweise über eine SSO-Option wie Google für ein Zoom-Konto anmelden, verfügt Ihr Konto standardmäßig nicht über ein Passwort. Durch die Einrichtung eines Passworts wird sichergestellt, dass viele Vorgänge, wie die Verknüpfung mit einem Drittanbieterkonto oder die Aktivierung von 2FA, eine zusätzliche Überprüfung erfordern.
- Deaktivieren oder Vorverknüpfen von Anmeldekonten von Drittanbietern
Entfernen Sie ungenutzte oder unnötige Anmeldeoptionen von Drittanbietern oder verknüpfen Sie Konten von Drittanbietern im Voraus, um Angriffsmöglichkeiten zu reduzieren.
Für IT-Administratoren/Unternehmenssicherheit
- Durchsetzung der SAML SSO-Authentifizierung
Implementieren Sie die SAML SSO-Authentifizierung für alle Arbeitsanwendungen. Dies zentralisiert die Verwaltung der Mitarbeiterkonten und verhindert, dass externe Benutzer in die Arbeitsbereiche der Anwendungen eindringen. Außerdem verringert sich der Aufwand für IT-Administratoren, die Konten von Benutzern in verschiedenen Anwendungen nach dem Offboarding manuell zu löschen.
- Deaktivieren Sie nicht verwendete Anmeldeoptionen von Drittanbietern
Deaktivieren Sie ungenutzte Anmeldeoptionen von Drittanbietern, um zu verhindern, dass externe Benutzer dem Arbeitsbereich beitreten.
- 2FA-Richtlinie für verwaltete Konten durchsetzen
Stellen Sie sicher, dass alle verwalteten Konten 2FA aktiviert haben, wo immer dies möglich ist.
- Erzwingen Sie die Einrichtung von Passwörtern für verwaltete Konten
Stellen Sie sicher, dass für alle verwalteten Konten Passwörter eingerichtet sind, die ähnlich wie die 2FA-Authentifizierung funktionieren und zusätzliche Sicherheit bieten können.
Für Identitätsdienstleister
- Domänenbezogener Anspruch in ID-Token hinzufügen
Um zu verhindern, dass externe Drittnutzer in die Arbeitsbereiche von Unternehmen eindringen, sollten Identitätsdienstleister domänenbezogene Angaben in ihren ID-Tokens unterstützen. Dies hilft Anwendungen, zwischen persönlichen und organisatorischen Nutzern zu unterscheiden, ähnlich wie der hd-Anspruch, der von Google Identity Services unterstützt wird.
- Registrierung von Arbeits- und Ausbildungs-E-Mail-Adressen ablehnen
Verhindern Sie die Verwendung von Arbeits- oder Ausbildungs-E-Mail-Adressen für die Kontoregistrierung. Microsoft und Apple beispielsweise blockieren bereits die Registrierung von Konten mit vielen E-Mail-Adressen von großen Unternehmen und renommierten Bildungseinrichtungen.
Da es schwierig ist, alle E-Mail-Adressen aus dem Arbeits- oder Bildungsbereich für die Kontoregistrierung zu sperren, sollten Anbieter von Identitätsdiensten Organisationen eine Möglichkeit bieten, ihre Domänenadressen zu deklarieren und anzugeben, ob ihre Domänen-E-Mail-Adressen registriert werden können. Apple ID könnte beispielsweise eine Website einrichten, auf der Unternehmen manuell den Besitz ihrer Domäne nachweisen können, indem sie einen TXT-DNS-Eintrag einrichten und Apple benachrichtigen, wenn Benutzer Konten mit dieser Domäne registrieren dürfen.
Fazit
Das Aufkommen von SSO-Diensten hat die Benutzerauthentifizierung bei zahlreichen SaaS-Anwendungen vereinfacht. Unsere Untersuchung zeigt jedoch, dass der Rückgriff auf diese Dienste erhebliche Sicherheitsrisiken mit sich bringen kann.
Anwendungsentwickler müssen robuste Sicherheitspraktiken anwenden, wie z. B. die Verknüpfung von Konten auf der Grundlage des Unteranspruchs und eine umfassende Verwaltung der Verknüpfung mit Dritten. Endbenutzer müssen wachsam bleiben, 2FA aktivieren und ihre Links zu Drittanbietern angemessen verwalten. IT-Administratoren sollten strenge Sicherheitsrichtlinien durchsetzen, einschließlich SAML SSO-Authentifizierung und 2FA-Richtlinien, um verwaltete Konten zu schützen. Identitätsdienstleister spielen ebenfalls eine wichtige Rolle, indem sie domänenbezogene Ansprüche anbieten und die Registrierung von Arbeits- und Bildungs-E-Mail-Adressen ablehnen.
Durch die Umsetzung dieser Maßnahmen können wir gemeinsam die Sicherheit von SSO-Integrationen verbessern und uns gegen die anhaltenden Bedrohungen durch Shadow Linking schützen.