Neue Schwachstellen bei der SMS-basierten Authentifizierung

Die Verwendung von SMS als zweiter Faktor schließt nicht nur viele der bestehenden Schwachstellen der reinen Kennwortauthentifizierung nicht, sondern setzt eine Anwendung auch zusätzlichen Angriffsmethoden aus.

Diebstahl eines physischen Geräts

Der vielleicht offensichtlichste Angriff auf eine besitzbasierte Authentifizierung ist der Diebstahl eines physischen Geräts. Ein Krimineller, der ein Telefon stiehlt, könnte Zugriff auf einen in einer Benachrichtigung angezeigten OTP-Code erhalten, selbst wenn das Telefon gesperrt ist. Viele Opfer von Telefondiebstahl haben das Geld auf ihren Bankkonten verloren.

SIM-Austausch (Subscriber Identity Module)

Kriminelle müssen nicht im physischen Besitz eines Telefons sein, um Zugriff auf per SMS gesendete OTPs zu erhalten. SIM-Swapping , auch als SIM-Hijacking oder SIM-Porting bekannt, ermöglicht es Angreifern, die SMS-basierte Authentifizierung zu umgehen, die in kundenorientierten Apps am häufigsten verwendete Form der MFA. Bei einem SIM-Swap-Angriff nutzt der Betrüger die Möglichkeit von Telekommunikationsdienstleistern, eine Telefonnummer auf ein anderes Gerät zu übertragen, eine Funktion, die bei Verlust oder Diebstahl eines Telefons von Vorteil ist.

Der Betrüger sammelt zunächst durch Online-Recherche, Phishing oder Social Engineering persönliche Informationen über das Opfer. Mit diesen Informationen überzeugt der Angreifer die Telefongesellschaft, die Telefonnummer des Opfers auf die SIM-Karte des Betrügers zu übertragen. Oder der Angreifer könnte sich mithilfe von Credential Stuffing, Brute-Force-Angriffen oder einem Wörterbuchangriff Zugang zum Benutzerkonto beim Dienstanbieter verschaffen.

Durch die Kontrolle über den Telefondienst des Opfers empfängt der Betrüger alle SMS und Sprachanrufe, die für das Opfer bestimmt sind. Auf diese Weise kann der Betrüger alle per SMS gesendeten Sicherheitstoken abfangen.

Hardware-Token-Geräte

Hardware-Token-Geräte sind spezielle, normalerweise recht kleine Geräte, die ein OTP anzeigen, das der Benutzer zur Authentifizierung in eine Anwendung eingibt. Diese Geräte bieten eine Möglichkeit, den Besitz nachzuweisen, ohne dass eine Kommunikation zwischen der Anwendung und dem Benutzer erforderlich ist. Dadurch wird eine der Hauptschwachstellen der SMS-basierten Authentifizierung behoben.

Anstatt sich darauf zu verlassen, dem Benutzer bei jeder Anmeldung das OTP zu senden, generiert das Gerät einen OTP-Stream basierend auf einem anfänglichen Startwert und einem Algorithmus. Der Seed-Wert selbst wird beim Einrichten zwischen dem Gerät und dem Authentifizierungsdienst geteilt. Der Startwert wird durch einen Zähler ergänzt, der entweder bei einem Ereignis (z. B. einer Anmeldeanforderung) oder über eine Zeitspanne (z. B. 60 Sekunden) erhöht wird . Wir bezeichnen diese jeweils als ereignisbasiertes OTP (EOTP) und zeitbasiertes OTP (TOTP). EOTP und TOTP sind beides Arten von hashbasiertem OTP (HOTP), da Zähler und Seed zusammen an eine Hash-Funktion übergeben werden, die eine scheinbar zufällige Ziffernfolge generiert, die bei korrekter Implementierung kein vorhersehbares Muster aufweist.

Da das OTP nicht per SMS gesendet werden muss, machen es Hardware-Tokens unmöglich, das OTP abzufangen, bevor es den Benutzer beispielsweise durch SIM-Swapping erreicht. Da der Benutzer das OTP jedoch in die App eingeben muss, die das OTP über denselben Kommunikationskanal wie das Kennwort an den Authentifizierungsdienst überträgt, bleiben die meisten anderen Schwachstellen der SMS-basierten Authentifizierung bestehen. Der Angreifer kann sich Zugriff auf das Kennwort und den OTP verschaffen, indem er den Endpunkt, das Netzwerk oder die Anwendung kompromittiert, und zwar auf die gleiche Art und Weise, wie er es bei per Textnachricht übermittelten OTPs tun würde.

Der gängigste Angriff auf die SMS-basierte Authentifizierung, nämlich Echtzeit-Phishing-Proxys, funktioniert genauso gut mit OTPs, die auf Hardwaregeräten generiert werden. Denn der Benutzer wird dazu verleitet, das OTP auf der gefälschten Site einzugeben, unabhängig davon, ob das OTP auf einem Telefon oder einem speziellen Gerät angezeigt wird.

Während Hardwaregeräte die Möglichkeit ausschließen, dass Angreifer das OTP während der Übertragung an den Benutzer abfangen, basieren die Geräte auf Seed-Werten, die kompromittiert werden können. Angreifer können auf den Startwert zugreifen, indem sie sich physischen Zugriff auf die Geräte verschaffen (siehe Erwähnung eines Elektronenmikroskop-Angriffs in „12+ Möglichkeiten zum Hacken von MFA“ ), die vom Authentifizierungsdienst verwendete Datenbank kompromittieren oder den Einrichtungsprozess abfangen, bei dem der Startwert zwischen dem Gerät und dem Authentifizierungsdienst vereinbart wird.

Authenticator-Apps

Authentifizierungs-Apps können ähnlich wie Hardware-Token funktionieren, indem sie einen Datenstrom aus OTPs auf Grundlage eines anfänglichen Seeds und Algorithmus generieren, sodass der Seed nicht über einen anfälligen Kanal übermittelt werden muss. Sie können aber auch noch einen Schritt weiter gehen und einen alternativen Kanal zur Übermittlung des OTPs verwenden. In diesem Szenario sendet der Authentifizierungsdienst nach der erfolgreichen Überprüfung eines Benutzernamens und Passworts eine Push-Benachrichtigung an die Authentifizierungs-App, die den Benutzer auffordert, die Anfrage zu genehmigen. Nach der Genehmigung sendet die Authentifizierungs-App das OTP direkt an den Authentifizierungsdienst, ohne dass der Benutzer es in die Anwendung eingeben muss. Die Kommunikation zwischen der Authenticator-App und dem Authentifizierungsdienst erfolgt über eine separate Verbindung.

Die Verwendung eines alternativen Kommunikationskanals bedeutet, dass ein Angreifer nicht durch Kompromittierung der Anwendung auf das OTP zugreifen kann, da das OTP nie in die Anwendung eingegeben wird. Zudem ist es schwieriger, sowohl das Kennwort als auch das OTP durch Beeinträchtigung der Netzwerkverbindung abzugreifen, da das Kennwort und das OTP über unterschiedliche sichere Kanäle übermittelt werden. Durch die Kompromittierung des Endpunkts könnte ein Angreifer jedoch sowohl auf das Kennwort als auch auf den OTP-Code zugreifen, wenn die Anwendung selbst und die Authentifizierungs-App auf demselben Gerät ausgeführt werden. (Siehe den Bericht von F5 Labs zu Malware , die Google Authenticator gefährdet.)

Leider verhindern Authentifizierungs-Apps nicht die Verwendung von Echtzeit-Phishing-Proxys. Der Benutzer wird immer noch durch eine Phishing-Textnachricht dazu verleitet, seinen Benutzernamen und sein Passwort auf einer gefälschten Site einzugeben. Nach Eingabe der Anmeldeinformationen löst die Anwendung eine Anfrage an die Authentifizierungs-App aus. Da der Benutzer davon ausgeht, dass er sich gerade bei einer vertrauenswürdigen Anwendung anmeldet, wird er die Anfrage wahrscheinlich genehmigen und damit die Authentifizierung abschließen. Obwohl der Angreifer das OTP nie sieht, hat sein Proxy nun die Kontrolle über eine authentifizierte Sitzung und erhält so Zugriff auf das Benutzerkonto. (Weitere Informationen zu RTPP und Push-Benachrichtigungsauthentifizierung finden Sie in diesem Artikel zu Phishing-Plattformen in Hacker News.)

Darüber hinaus bietet die Benutzerfreundlichkeit von Authentifizierungs-Apps Angreifern eine weitere Möglichkeit, MFA durch Social Engineering zu umgehen. Bei MFA-Bombing- oder MFA-Fatigue-Angriffen bringt der Angreifer das Ziel durch das Senden mehrerer betrügerischer Code-Anfragen dazu, ihm seinen Authentifizierungscode preiszugeben. Der Angreifer verwendet in der Regel automatisierte Tools, um eine große Zahl von Anfragen zu generieren und überhäuft das Opfer mit einer übermäßigen Anzahl von Benachrichtigungen oder Nachrichten, in denen es aufgefordert wird, seinen Authentifizierungscode einzugeben.

Während MFA-Bombing einen Benutzer dazu verleiten kann, ein OTP aus einer SMS-Nachricht oder einem Hardwaregerät einzugeben, ist es besonders effektiv gegen Authentifizierungs-Apps, da der Benutzer die Flut an Anfragen ganz einfach durch Drücken einer Taste stoppen kann.

Biometrische Authentifizierung

Es gibt noch mehr Möglichkeiten zur Implementierung der biometrischen Authentifizierung als die besitzbasierte Authentifizierung. Es gibt nicht nur zahlreiche Methoden, um die Authentifizierungsanforderung auszulösen und diese Daten an den Authentifizierungsdienst zurückzusenden, sondern auch viele Formen der Biometrie vom Fingerabdruck bis zum Iris-Scan. Die für den Scan erforderliche Hardware ist möglicherweise in das Gerät integriert, auf dem die Anwendung ausgeführt wird (z. B. die Kamera eines Fingerabdrucklesers auf einem Laptop), oder es ist separate Hardware erforderlich. Der biometrische Leser kann vom Betriebssystem oder einer speziellen Anwendung gesteuert werden. Angesichts dieser Unterschiede in der Implementierung ist es schwierig, jede Schwachstelle zu modellieren. Man muss sich jedoch darüber im Klaren sein, dass die biometrische Authentifizierung trotz ihres Rufs einer höheren Sicherheit immer noch ganz klare Schwachstellen aufweist.

Tatsächlich kann eine der beliebtesten Methoden zum Umgehen des Besitzfaktors – Echtzeit-Phishing-Proxys – genauso gut zum Umgehen biometrischer Daten verwendet werden. Sobald sich der Benutzer bei einer vom Angreifer gesteuerten Anwendung anmeldet und davon ausgeht, dass es sich um eine vertrauenswürdige Anwendung handelt, verwendet diese Anwendung die Anmeldeinformationen, um sich im Namen des Benutzers bei der Anwendung anzumelden und löst dadurch die Anforderung zur biometrischen Authentifizierung aus. Solange der Benutzer glaubt, dass er sich bei der echten Anwendung authentifiziert, wird er wahrscheinlich mit der biometrischen Authentifizierung fortfahren und dem Angreifer Zugriff auf das Konto gewähren. (Der vom W3C entwickelte FIDO2-Standard WebAuthn umfasst einen Schutz vor Phishing, wird von Webanwendungen allerdings noch nicht so weithin übernommen.)

Ob die biometrische Authentifizierung durch Kompromittierung des Endpunkts, der Anwendung oder des Netzwerks umgangen werden kann, hängt von der jeweiligen Implementierung ab. Sofern das biometrische Authentifizierungssystem auf demselben Gerät wie die Anwendung ausgeführt wird, kann eine Kompromittierung des Endpunkts zu einer Unterbrechung der Authentifizierung führen. Sofern die Anwendung den biometrischen Authentifizierungsprozess verwaltet, kann eine Kompromittierung der App zu einer Unterbrechung der Authentifizierung führen. Und sofern die biometrische Authentifizierung über denselben Kommunikationskanal gesendet wird, den auch die Anwendung verwendet, kann eine Beeinträchtigung des Netzwerks zu einer Unterbrechung der Authentifizierung führen. Kurz gesagt erfordert die biometrische Authentifizierung eine detaillierte, implementierungsspezifische Bedrohungsmodellierung.

Bei der biometrischen Authentifizierung besteht die besondere Anfälligkeit für Kopieren und Spoofing. Denken Sie an Fingerabdrücke. Wir hinterlassen sie überall, auf fast jeder glatten Oberfläche, die wir berühren. Wir hinterlassen sie an Türklinken, in Restaurants, im Müll. Das Sammeln von Fingerabdrücken auf diesen Oberflächen ist trivial; wir alle haben das in Polizeiserien schon unzählige Male gesehen. Auch das Replizieren von Fingerabdrücken ist mit allen möglichen Mitteln – vom 3D-Drucker bis hin zu Gummibärchen – ganz einfach.

Bei anderen Formen der Biometrie herrscht ein anhaltender Wettbewerb zwischen Sicherheitsforschern, die aufdecken, wie biometrische Daten gefälscht werden können, und Anbietern, die Technologien gegen Spoofing entwickeln. 3D-Masken haben Gesichtserkennungssysteme an Flughäfen getäuscht, obwohl diese Masken durch Echtheitsprüfungen und andere Methoden erkannt werden können. Ebenso haben Angreifer Sprachaufzeichnungen mit Deepfake-Sprachsynthese verwendet, um Spracherkennungssysteme zu umgehen . Diese Fälschungen können jedoch möglicherweise durch die subtilen Verzerrungen erkannt werden, die von den Aufnahmegeräten hinzugefügt werden. Sogar Irisbilder können durch die Verwendung kosmetischer Kontaktlinsen oder eines künstlichen Auges reproduziert und gefälscht werden. Verschiedene Anti-Spoofing-Techniken – darunter die Unterscheidung der Beleuchtung zwischen menschlichem Gewebe und synthetischen Materialien – können die Fälschung jedoch erkennen. Kurz gesagt: Die Sicherheit biometrischer Lesegeräte hängt vom aktuellen Stand der Spoofing- und Anti-Spoofing-Technologie ab.

Selbst wenn wir ein Leben wie ein Einsiedler führten und das physische Berühren von Oberflächen vermieden, könnten Angreifer unsere biometrischen Daten stehlen. Durch Malware, Social Engineering und die Ausnutzung ungepatchter Schwachstellen haben Angreifer Milliarden von Benutzernamen und Passwörtern gestohlen. Wenn es Angreifern gelingt, in die Datenbanken einzudringen, in denen unsere Passwörter gespeichert sind, werden sie mit Sicherheit auch in die Datenbanken eindringen, in denen unsere biometrischen Daten gespeichert sind. Und wenn unsere biometrischen Daten erst einmal durch einen einzigen Verstoß offengelegt werden, können wir sie unter Umständen nicht mehr sicher zur Authentifizierung verwenden, je nachdem, ob das Spoofing erkannt wird.

Das Sicherheitsrisiko des Kopierens und Spoofings wird noch dadurch verschärft, dass wir die biometrisch gemessenen Merkmale nicht einfach ändern können. Wenn ein Angreifer ein Passwort stiehlt, können wir es ändern. Wenn ein Angreifer einen OPT-Dongle oder ein Mobiltelefon stiehlt, können wir es ersetzen und den Seed zurücksetzen. Wenn sich ein Angreifer jedoch Zugang zu unserem Fingerabdruck, Handflächenabdruck, Gesichtsbild oder einem anderen biologischen Merkmal verschafft und lernt, diese wirksam zu fälschen, können wir diese körperlichen Merkmale nicht ändern, ohne erhebliche Schmerzen zu erleiden.

Verbesserung der Sicherheit von MFA

Zwar stellt MFA eine Verbesserung gegenüber der passwortbasierten Ein-Faktor-Authentifizierung dar, doch ist es zumindest in den derzeit gängigen Implementierungsformen immer noch anfällig. Betrachten Sie MFA nicht als das Ende der Sicherheitsreise, sondern als einen Neuanfang. Best Practices zur App-Sicherheit sind nach wie vor relevant wie eh und je, darunter Bedrohungsmodellierung, Codeüberprüfungen, Schwachstellenscans, Penetrationstests und Red Teaming. Betrachten Sie bei der Bedrohungsmodellierung jeden Aspekt des Authentifizierungs- und Sitzungsverwaltungsprozesses und berücksichtigen Sie dabei die vielen Angriffspunkte, vom Identitätsspeicher bis hin zur physischen Sicherheit sowie der Netzwerk- und Datensicherheit. Cyberangriffe zielen wahrscheinlich auf das schwächste Glied. Insbesondere die Schwachstellen von MFA weisen auf einige wichtige Problembereiche hin, die mehr Aufmerksamkeit erfordern: Eindämmung der Automatisierung, Schutz vor JavaScript-Lieferkettenangriffen und Berücksichtigung des Risikokontexts.

Entfernen Sie Bots aus Ihrem Netzwerk

Kriminelle nutzen Bots, um mehrere wichtige Angriffe auf MFA zu skalieren, darunter Credential Stuffing, Echtzeit-Phishing-Proxys und MFA-Bombing. Die Abwehr von Bots ist daher der Schlüssel zum Schutz vor allen Formen von MFA.

Bei Credential-Stuffing-Angriffen gemäß der Definition von OWASP stehlen Kriminelle Anmeldeinformationen aus früheren Sicherheitsverletzungen (in der Regel durch Käufe im Dark Web) und testen diese Anmeldeinformationen anhand der Logins anderer Anwendungen. Da durch Sicherheitsverletzungen Milliarden von Anmeldeinformationen offengelegt wurden, maximieren Kriminelle ihren Gewinn, indem sie die Tests mit Bots automatisieren, sodass sie riesige Mengen an Anmeldeinformationen testen können. Das FBI, die US-Börsenaufsichtsbehörde Securities and Exchange Commission und der New Yorker Generalstaatsanwalt haben vor den finanziellen Risiken von Credential Stuffing gewarnt und die Global Privacy Assembly , ein Zusammenschluss von über 130 Regulierungsbehörden, erklärte Credential Stuffing zu einer globalen Bedrohung für die Privatsphäre.

Das Verhindern von Credential Stuffing ist bei MFA genauso wichtig wie bei der reinen Kennwortauthentifizierung. Der ganze Sinn von MFA besteht in der Verwendung von mehr als einem Faktor. Wenn es Ihnen jedoch nicht gelingt, den ersten Faktor zu schützen, bleibt Ihnen nur noch ein Faktor. Sobald ein Angreifer das Passwort eines Benutzers herausgefunden hat, wird die Zwei-Faktor-Authentifizierung zur Ein-Faktor-Authentifizierung und die tiefgreifende Verteidigung geht verloren.

Darüber hinaus ist die Abwehr von Bots von entscheidender Bedeutung, da Kriminelle mit Bots nicht nur Passwörter angreifen. Tatsächlich sind Bots ein wichtiges Instrument zum Starten erfolgreicher Phishing-Proxy-Angriffe in Echtzeit, den gängigsten Mechanismen zum Umgehen von MFA. Wenn ein Benutzer Opfer einer Phishing-E-Mail wird, die ihn dazu verleitet, seine Anmeldeinformationen auf einer gefälschten Site einzugeben, muss der Angreifer diese Anmeldeinformationen an die Zielanwendung weiterleiten, um die MFA-Anforderung zu generieren, unabhängig davon, ob es sich bei dieser Anforderung um eine SMS, eine Authentifizierungs-App oder komplexe biometrische Daten handelt. Um die Anfrage schnell und in großem Umfang weiterzuleiten, muss der Kriminelle den Prozess automatisieren, was bedeutet, dass die Anfrage von einem Bot an die Anwendung weitergeleitet wird. (Eine Übersicht über Dienste, die Bots zum Umgehen von OTP verwenden, finden Sie im Krebs on Security-Beitrag „The Rise of One-Time Password Interception Bots“. ) Dies bedeutet, dass ein Unternehmen die Wirksamkeit von Echtzeit-Phishing-Proxys beeinträchtigen und sowohl Besitz- als auch Inhärenz-Authentifizierungsfaktoren wirksamer schützen kann, indem es unerwünschte Bots daran hindert, Anmeldeinformationen zu übermitteln.

Eine weitere offensichtliche Methode, mit der Kriminelle Bots verwenden, um MFA anzugreifen, ist das MFA-Bombing. Unter Bombing versteht man in diesem Zusammenhang die Generierung von Anmeldeanforderungen in großer Menge, um so viele Authentifizierungsanforderungen auszulösen, dass der Benutzer entweder aus Versehen oder einfach nur, um die Belästigung zu beenden, dieser Anforderung nachkommt. Um eine ausreichend große Anzahl von Anfragen für viele Benutzer zu generieren, damit der Angriff profitabel wird, muss der Kriminelle eine Automatisierung vornehmen, was wiederum bedeutet, dass die Anmeldeanfragen, die Ihre Site erreichen, von Bots erstellt werden.

Wie diese Beispiele zeigen, ist für den Erfolg nahezu aller Angriffe auf MFA im großen Stil Bots erforderlich. Das bedeutet, dass Unternehmen, die MFA implementieren, die Abwehr von Bots ernst nehmen müssen.

Leider sind sich viele Organisationen der Komplexität der Bots und der Entschlossenheit der Kriminellen nicht bewusst, die Bots immer wieder umzurüsten, um eine Erkennung zu umgehen. Vielmehr verlassen sich zu viele Unternehmen auf Techniken zur Bot-Abwehr, die nicht mehr funktionieren, darunter CAPTCHA, IP-Adress-Sperrlisten und HTTP-Header-Fingerabdrücke.

CAPTCHA leistet beim Bot-Schutz wenig, außer dass es echte Kunden verärgert, denn Bots können diese Rätsel mithilfe kostengünstiger CAPTCHA-Lösungsdienste umgehen, die auf maschinellem Lernen und Klickfarmen basieren. Führen Sie einfach eine Websuche nach CAPTCHA-Lösungsdiensten durch und Sie werden mindestens ein Dutzend finden, die in Bezug auf Preis und Geschwindigkeit konkurrieren. Eine informative Lektüre zu diesen Diensten finden Sie in einem Artikel von Dan Woods, Head of Intelligence bei F5, mit dem Titel „Ich war ein menschlicher CAPTCHA-Löser“ . Noch interessanter ist, dass es ChatGPT gelang, CAPTCHA zu umgehen, indem es eine Person durch Social Engineering dazu brachte, das CAPTCHA in seinem Namen zu lösen.

Für Organisationen, die sich zur Abwehr von Bots auf WAF-basierte IP-Sperrlisten verlassen, ist die Aufgabe ebenso gewaltig. Es gibt Dienste , die Bot-Erstellern zig Millionen private IP-Adressen anbieten, mit denen die Bot-Erkennung umgangen werden kann. Diese Dienste werden als rotierende Residential Proxies beworben; der Bot sendet HTTP-Anfragen an den Proxy, ähnlich wie viele Unternehmensbrowser Anfragen über Forward-Proxies senden, und der Dienst wechselt kontinuierlich die öffentliche IP-Adresse, die zum Senden der Anfrage an die Website oder API verwendet wird. In der Vergangenheit verwendeten Bots normalerweise Data-Center-Proxies, oft von Cloud-Diensten, die bekannt und leicht zu identifizieren sind. Diese neuen Proxy-Dienste verwenden jedoch private IP-Adressen aus derselben geografischen Region wie Ihre Kunden. Da jede IP-Adresse aufgrund des NATing durch Internetdienstanbieter (ISPs) gleichzeitig entweder einen Bot oder einen gültigen Kunden darstellen könnte, ist es nicht möglich, alle diese IP-Adressen zu blockieren, ohne Ihre echten Kunden abzuweisen. (Weitere Informationen dazu, wie diese Dienste diese IP-Adressen erhalten, finden Sie im Dokument „Ihr Telefon ist mein Proxy“ .)

Auch der Versuch, Bots anhand von Unterschieden in der Header-Reihenfolge zu erkennen, funktioniert nicht mehr, da Bots den Trick durchschaut haben. Tatsächlich sorgen mehrere Open-Source-Projekte, darunter „stealth-puppeteer“ und „undetected-chromedriver“ , für die richtige Header-Reihenfolge, sodass sich Erkennungsvorgänge bei der Verwendung dieser beliebten Automatisierungs-Frameworks leicht umgehen lassen.

Das Erkennen hochentwickelter Bots erfordert heutzutage eine erweiterte Signalerfassung, Überwachung rund um die Uhr, maschinelles Lernen und eine schnelle Reaktion auf die Umrüstung von Bots. Ohne eine spezielle Bot-Management-Lösung, also eine Abwehr, die Umrüstungen erkennt und schnell darauf reagiert, können Kriminelle mit Bots Angriffe gegen MFA effektiv skalieren.

Schützen Sie sich vor JavaScript-Supply-Chain-Angriffen

Nahezu jede erdenkliche Form der MFA schlägt fehl, wenn die Anwendung gefährdet ist. Wenn der Angreifer Code in eine Anwendung einfügt, ist das Spiel vorbei. Der Angreifer kann Anmeldeinformationen und andere MFA-Eingaben erfassen, Sitzungen durch Diebstahl von Sitzungskennungen übernehmen oder Daten direkt aus der Anwendung exfiltrieren. Moderne Webanwendungen bestehen typischerweise aus über 20 JavaScript-Dateien , die größtenteils von Drittanbietern stammen und nicht vom Anwendungssicherheitsteam des Unternehmens überprüft werden. Daher ist das Risiko einer Anwendungskompromittion durch JavaScript-Lieferkettenangriffe höher als oft angenommen.

Vorhandene clientseitige Sicherheitsprotokolle sind zu statisch, um die dynamischen Web-Apps von heute zu schützen. Die Content Security Policy (CSP) schränkt die Aktionen von Skripten auf eine Weise ein, die Angriffe auf die JavaScript-Lieferkette verhindern kann. Allerdings kann CSP auch zu leicht die Funktionalität einer Site beeinträchtigen, wenn ein Drittanbieter ein Skript dynamisch und auf eine Weise aktualisiert, die den CSP-Einschränkungen zuwiderläuft. Zwar möchten Sie vielleicht, dass ein Skript fehlschlägt, wenn es gegen eine Sicherheitsrichtlinie verstößt, doch ein solcher Fehler in der Produktion könnte dramatische Auswirkungen auf die Kunden haben. (Siehe „Warum schlägt CSP fehl? “) Sub-Resource Integrity (SRI), ein weiteres Web-Sicherheitsprotokoll, ist für dynamische Inhalte von Drittanbietern sogar noch weniger praktikabel , da es bei jeder Skriptänderung eine Aktualisierung der Skript-Tags mit Hash-Werten erfordert, was nicht möglich ist, wenn die Änderungen ohne Ankündigung erfolgen. Tatsächlich ist SRI dazu gedacht, die Art von Skriptaktualisierungen zu verhindern, auf die sich die meisten modernen Anwendungen verlassen.

Ohne klare Kontrollen zum Beseitigen von Schwachstellen in der JavaScript-Lieferkette müssen Unternehmen kreativ werden und Mittel und Wege finden, um das Risiko zumindest zu überwachen. Organisationen können die Skripte auf ihrer Site besser dokumentieren und sie basierend auf der Quelle und Änderungshäufigkeit nach Risiko einstufen. Über Tag-Manager hinzugefügte Skripte sollten regelmäßig überprüft werden, um das Risiko zu bewerten. Es sind Überwachungstools erhältlich, die das Verhalten von Skripten entweder mithilfe von synthetischer Überwachung, CSP im Berichtsmodus oder JavaScript-basierten Agenten verfolgen, die im Browser ausgeführt werden.

Da sich Drittanbieter-Skripte so häufig ändern und keine Möglichkeit zur Sicherheitsüberprüfung besteht, ist es für Unternehmen wichtig, ihre Anwendungen kontinuierlich auf verdächtiges Verhalten zu überwachen, beispielsweise auf Skripte, die vertrauliche Daten lesen und in nicht vertrauenswürdige Domänen exfiltrieren. Ohne diese Überwachung auf JavaScript-Lieferkettenangriffe bietet keine Form von MFA die Sicherheit der Benutzer.