vorige Präsentation: A6 - Komponenten | zurück zum Buch-Kapitel [esc] | Nächste Präsentation A8 - Software and Data Integrity Failures
Auf Platz 7 der OWASP Top 10 2021: Identification and Authentication Failures.
Rund um die Identifizierung und Authentifizierung und das Session-Management treten viele Probleme auf.
Ein Angriff mittels “Credential Stuffing” ist einfach umzusetzen: ein kleines Programm probiert automatisch das Login mit den bekanntesten Passwörtern aus.
Als Benutzer*in des Internet empfiehlt sich auf jeden Fall: neues Passwort für jedes neue Login das ich anlege. Mit Hilfe eine Passwort-Managers.
Hier ein paar Maßnahmen, die man als Entwickler*in auch schon im ersten PHP-Projekt umsetzen kann:
Authentisierung kann aus vielen Gründen fehl schlagen:
Egal was die Gründe sind: die Rückmeldung an die User*in muss immer genau gleich ausfallen:
“Login Fehlgeschlagen - Falscher Username oder Falsches Passwort”
Warum? Die Information, ob ein bestimmter Username im System exisitiert ist wertvoll! Es ist ja bereits die Hälfte der nötigen Information für ein Login. Deswegen soll man die Existenz von Usernamen genau so geheim halten wie die Passwörter.
Oft werden strenge Passwort Regeln verwendet:
“Das Passwort muss mindestens einen Großbuchstaben, einen Kleinbuchstaben, ein Sonderzeichen und zwei verscheidene Ziffern enthalten und darf nicht länger als 8 Zeichen sein”
Diese Regeln sind veraltet. So empfiehlt das amerikanische National Institute of Standards and Technology seit 2017 in NIST 800-63 :
Siehe auch
Das Protokoll HTTP ist stateless. Wenn man trotzdem User*innen authentifizieren will, muss bei jedem Request eine authentifizierende Information, zum Beispiel eine Session-ID, mitgeschickt werden. Dies geschieht zum Beispiel in einem Cookie.
Wenn es gelingt diese Information abzuhören und wieder zu verwenden, dann erhält man den gleichen Zugang wie die eigentliche UserIn. Diese Art der Angriffs nennt man “Replay Attacke” - ein Request wird abgehört und gleich wieder verwendet.
Um Passwörter ebenso wie Session Ids und Cookies vor dem Abhören zu schützen muss man den gesamten HTTP-Request verschlüssen - das ist über SSL/TLS möglich.
Ein weiterer Punkt wo diese Informationen eventuell aufscheinen sind Logfiles. Auch beim Logging sollte man diese Informationen vorher ausfiltern oder verschlüsseln:
Es ist sehr schwierig, ein sicheres Authentifizierungs- und Session-Management zu implementieren. Man sollte nicht auf eigene Lösungen setzen - Diese haben dann oft Fehler bei Abmeldung und Passwortmanagement, bei der Wiedererkennung der Benutzer*innen, bei Timeouts, Sicherheitsabfragen usw. Das Auffinden dieser Fehler kann sehr schwierig sein, besonders wenn es sich um individuelle Implementierungen handelt.
PHP liefert nur ein Session-System. Frameworks wie Symphony oder Laravel liefern fertige Lösungen für den gesamten Login Prozess.
Passwörter sollten niemals im Klartext in der Datenbank gespeichert werden. Statt dessen wir nur ein Hash des Passworts gespeichert.
Beim Login wir das eingegebene Passwort dann wieder mit derselben Hash-Funktion behandelt, und mit dem gespeicherten Wert verglichen.
PHP stellt eine geeignete Hash-Funktion zur Verfügung: password_hash. Siehe auch /security/a2-crypto/
Die “Session Fixation” Attacke funktioniert mit der Session ID. Ein Beispiel:
Alyssa P. Hacker sendet einen Link an Peter Publikum. Dieser Link führt zur Bank von Peter Publikum, und gibt schon eine Session ID vor. Wenn sich Peter Publikum nun bei seinem Online-Banking einloggt, die Session ID aber gleich bleibt, dann kann Alyssa P. Hacker mit der gleichen Session die Online Banking Seite aufrufen, und ist schon eingeloggt - als Peter Publikum.
Um diese Art der Attacke zu vermeiden kann man beim Login und Logout jeweils eine neue Session starten.
In PHP geht das mit folgenden Befehlen:
session_start(); session_regenerate_id(); session_destroy(); unset($_SESSION); session_start();
Komplexere Maßnahmen wären:
Die OWAAS bietet noch mehr Informationen zu diesem Thema an im Authentication Cheat Sheet und im Session Management Cheat Sheet.
vorige Präsentation: A6 - Komponenten | zurück zum Buch-Kapitel [esc] | Nächste Präsentation A8 - Software and Data Integrity Failures
/
#