Es ist kein Wunder, dass gebrochene Authentifizierung es auf die OWASP-Liste für API-Probleme geschafft hat - Authentifizierungsmechanismen sind notorisch schwierig korrekt zu implementieren. Außerdem haben Angreifer einen kleinen Vorteil, da die meisten Authentifizierungsherausforderungen von Natur aus für die Benutzer sichtbar sein müssen, was Angreifern die Möglichkeit gibt, sie zu studieren und nach Mustern oder Schwachstellen zu suchen, die sie ausnutzen können.

Da die Authentifizierung häufig als Tor zu einer Anwendung und möglicherweise auch zum restlichen Netzwerk fungiert, sind sie ein verlockendes Ziel für Angreifer. Wenn ein Authentifizierungsprozess fehlerhaft oder anfällig ist, besteht eine gute Chance, dass Angreifer diese Schwäche entdecken und ausnutzen.

In diesem Kapitel werden wir also lernen, wie man die bösen Jungs ausschaltet, wenn es um Authentifizierungsprobleme geht. Wenn Sie Ihre Fähigkeiten zuerst testen möchten, spielen Sie unsere spielerische Herausforderung:

Wollen Sie Ihr Ergebnis verbessern? Bleiben Sie bei mir, während wir es aufschlüsseln.

Was sind einige Beispiele für fehlerhafte oder falsch konfigurierte Authentifizierung?

Ein Beispiel, bei dem das Problem vielleicht nicht so offensichtlich ist, ist, wenn eine Authentifizierungsmethode anfällig für Credential Stuffing ist, also die Verwendung von Listen mit bekannten Benutzernamen und Passwörtern, um die Sicherheit zu umgehen. Selbst eine normalerweise sehr sichere Autorisierungsmethode, wie die Multifaktor-Authentifizierung, kann anfällig sein, wenn Anfragen nicht begrenzt, gedrosselt oder anderweitig überwacht werden.

Ein Angreifer könnte zum Beispiel eine Passwort-Wiederherstellungsanfrage auslösen, indem er eine POST-Anfrage an /api/system/verification-codes sendet und einen Benutzernamen im Anfragetext angibt. Wenn eine App eine SMS-Challenge verwendet, bei der ein sechsstelliger Code an das Telefon eines Benutzers gesendet wird, das Eingabefeld aber nicht begrenzt ist, kann die Anwendung in wenigen Minuten geknackt werden. Ein Angreifer muss einfach jede mögliche sechsstellige Kombination in die Anwendung senden, bis er die richtige trifft.

In diesem Szenario sieht es oberflächlich betrachtet so aus, als ob die Zwei-Faktor-Authentifizierung eine Anwendung sicher machen würde. Aber da die Benutzereingabe nicht ratenbegrenzt ist, ist die Authentifizierung fehlerhaft und angreifbar.

In einem anderen Beispiel könnte eine Anwendung verschlüsselte Benutzerobjekte als Authentifizierungs-Cookies verwenden. Wenn jedoch ein Angreifer mit Low-Level-Benutzerzugriff dieses Cookie mit Base64 dekodiert, könnte er herausfinden, wie das Cookie Sitzungen und Benutzer für die Anwendung definiert. Nach der Dekodierung könnte er zum Beispiel folgendes JSON sehen:

{
"username" : "ShadyGuy",
"role" : "user"
{

An diesem Punkt könnte der böswillige Benutzer seinen Benutzernamen, seine Rolle oder beides ändern. Er könnte ein anderer Benutzer mit einer höheren Berechtigungsstufe werden, indem er ein paar Werte ändert:

{
"username" : "GoodGuy",
"role" : "admin"
{

Wenn der Angreifer zu diesem Zeitpunkt die Informationen umkodiert und als Cookie-Wert einstellt, wird er im Wesentlichen zum neuen Benutzer mit einer höheren Berechtigungsstufe. Wenn keine Methoden vorhanden sind, um eine solche Änderung zu verhindern, besteht eine gute Chance, dass die Anwendung die Umwandlung akzeptiert.

Eliminieren von fehlerhafter oder falsch konfigurierter Authentifizierung

Wenn die Authentifizierung fehlschlägt, ist die Wahrscheinlichkeit groß, dass die Sicherheit in der gesamten Anwendung beeinträchtigt wird. Aber das Befolgen einiger wichtiger Richtlinien beim Codieren von Anwendungen kann dazu beitragen, dass alles sicher bleibt.

Zunächst einmal sollten Sie sicherstellen, dass überall dort, wo Benutzer auf Programmfunktionen zugreifen können, Authentifizierungsprüfungen vorhanden sind. Wenn die Authentifizierungsprüfung überhaupt nicht vorhanden ist, dann ist die Schlacht von vornherein verloren.

In Bezug auf Best Practices ist eine gute Sache, die man im Hinterkopf behalten sollte, zu vermeiden, dass Sitzungs-IDs in der URL, die für Benutzer zugänglich ist, offengelegt werden. Im zweiten Beispiel oben bezüglich der gebrochenen Authentifizierung ist es viel einfacher, einen Angreifer davon abzuhalten, zu versuchen, das Sitzungs-Cookie zu entschlüsseln, wenn es ihm niemals offengelegt wird.

Es ist auch eine gute Idee, eine Multifaktor-Authentifizierung zu implementieren. Dies kann sicher mit Hardware-Tokens erfolgen, die Passwörter nach einem festen Zeitplan algorithmisch generieren. Wenn Sie Ihren Benutzern solche Geräte nicht zur Verfügung stellen können, können auch SMS-Textnachrichten funktionieren. Sie müssen jedoch sicherstellen, dass die Benutzeranfragen auf etwas Vernünftiges wie drei oder vier Versuche in einem Zeitraum von 30 Sekunden beschränkt sind und dass die Codes insgesamt nach wenigen Minuten ablaufen. Die Verwendung eines alphanumerischen Codes kann auch die Sicherheit erhöhen, indem Buchstaben und Zahlen zu potenziellen Passwörtern hinzugefügt werden.

Vermeiden Sie schließlich nach Möglichkeit die Abhängigkeit von Benutzernamen oder vorhersehbaren sequentiellen Werten als Sitzungs-IDs. Verwenden Sie stattdessen einen sicheren serverseitigen Sitzungsmanager, der jedes Mal eine zufällige Sitzungs-ID erzeugt.

Die Implementierung sicherer Authentifizierungsmethoden ist ein wenig kniffliger als die Bekämpfung einer durchschnittlichen Schwachstelle. Aber da die Autorisierung für jede Anwendung, jedes Programm und jede API so wichtig ist, lohnt es sich, sich extra Zeit zu nehmen, um sicherzustellen, dass Sie es richtig machen.

Schauen Sie sich die Secure Code Warrior Blog-Seiten, um mehr über diese Schwachstelle zu erfahren und zu erfahren, wie Sie Ihr Unternehmen und Ihre Kunden vor den Auswirkungen anderer Sicherheitslücken schützen können. Sie können auch eine Demo der Schulungsplattform Secure Code Warrior ausprobieren, um alle Ihre Cybersecurity-Kenntnisse zu schärfen und auf dem neuesten Stand zu halten.