This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

Germany/Projekte/Top 10-2017 A2-Fehler in der Authentifizierung

From OWASP
Jump to: navigation, search

==BAUSTELLE! Hier entsteht das deutsche Wiki der OWASP Top 10-2017==

==Bitte benutzen Sie die PDF Version.==

← A1-Injection
2017 Inhaltsverzeichnis

PDF version

A3-Verlust der Vertraulichkeit sensibler Daten →
Bedrohungsquellen / Angriffsvektoren Schwachstellen Auswirkungen
Anw.-
spezifisch
Ausnutzbarkeit: 3
Verbreitung: 2
Auffindbarkeit: 2
technisch: 3
Business ?
Angreifer haben Zugriff auf Millionen gültiger Benutzerdatensätze um diese als Prüfgrundlage zu nutzen, Listen mit administrativen Standard-zugängen, Werkzeuge zum Durchführen von Bruteforce- und Wörterbuch-Angriffen. Angriffe auf die Authentifizierung sind gut erforscht, insbesondere in Bezug auf nicht erloschene Session-Token. Aufgrund des Designs und der Implementierung von Identitäts- und Zugriffsprüfungen sind Fehler in der Authentifizierung weit verbreitet. Sitzungsverwaltung („Session Management“) ist die Grundlage zur Prüfung von Authentisierung und Zugriffsberechtigung und in zustandsbehafteten Anwendungen vorhanden.
Angreifer können fehlerhafte Authentifizierung mit manuellen Methoden erkennen und mithilfe automatisierter Tools mit Passwortlisten und Wörterbuchangriffen ausnutzen.
Um ein System zu kompromittieren, genügt es einem Angreifer, nur wenige Zugänge oder den einen administrativen Zugang zu erlangen. Abhängig vom Zweck der Anwendung ermöglicht ihm das z. B. Geldwäsche, Sozialbetrug, Identitätsdiebstahl oder die Veröffentlichung hochsensibler Informationen.
Ist die Anwendung verwundbar?

Um eine Anwendung gegen Angriffe auf die Authentisierung zu schützen, müssen die Nutzeridentität, Anmeldung und die Sitzungsverwaltung überprüft werden. Folgende Fehler in der Authentisierung können vorhanden sein:

  • Automatisierte Angriffe wie "Credential Stuffing" werden ermöglicht.
  • Bruteforce oder andere automatisierte Angriffe sind möglich.
  • Schwache oder bekannte Passwörter wie "Passwort!" oder "admin/admin" sind erlaubt, Standardpasswörter unverändert.
  • Funktionen um Zugangsdaten oder Passwörter wiederherzustellen sind schwach, wie z. B. "wissensbasierte Antworten", die nicht sicher sein können.
  • Speicherung von Passwörtern im Klartext, verschlüsselt oder mit schwachen Hashes (vgl. A3:2017-Verlust der Vertraulichkeit sensibler Daten).
  • Keine oder nicht wirksame Mehrfaktor-Authentisierung
  • Die Sitzungs-ID wird im URL exponiert (z. B. URL rewriting)
  • Kein Wechsel der Sitzungs-ID nach einer erfolgreichen Anmeldung.
  • Sitzungs-IDs werden nicht korrekt ungültig gemacht, d.h. Benutzersitzungen oder Authentisierungs-Token (wie z.B. Single-Sign-On (SSO)-Token) werden nach einer Abmeldung, nach einer festen Zeit oder bei Nicht-Aktivität nicht explizit ungültig gemacht.
Wie kann ich das verhindern?
  • Sofern es möglich ist, implementieren Sie Mehrfaktor-Authentisierung, um automatisierte Angriffe zu verhindern.

Im Auslieferungszustand sollten keine Standardbenutzer angelegt sein. Dies gilt besonders für administrative Benutzer.

  • Es sollten Prüfungen zum Verhindern schwacher Passwörter implementiert sein. So können Passwörtern gegen eine Liste der 10000 beliebtesten Passwörter. geprüft werden.
  • Die Prüfung der Länge, Komplexität und Häufigkeit des Passwortwechsels sollte sich an den Vorgaben der NIST 800-63 o. anderen Vorgaben mit nachweisbarer Sicherheit orientieren.
  • Funktionen zur Benutzerregistrierung, Wiederherstellung von Zugangsdaten und API Zugängen sollten gegen das automatische Durchsuchen nach gültigen Benutzernamen geschützt sein, in dem bei allen fehlerhaften Anmeldeversuchen dieselbe Fehlermeldung ausgegeben wird.
  • Begrenzen Sie die Gesamtanzahl der Anmeldeversuche oder setzen Sie Verzögerungen ein. Fehlerhafte Anmeldungen müssen protokolliert und Administratoren informiert werden, wenn Anomalien oder Angriffe erkannt werden.
  • Es sollten serverseitige, sichere und etablierte Sitzungsmanager verwendet werden, die eine zufällig vergebene Sitzungs-ID mit hoher Entropie verwenden. Sitzungs-IDs sollten nicht in der URL stehen, sicher gespeichert und nach Abmeldung, Inaktivität oder einer gewissen Zeitenspanne entwertet werden.
Mögliche Angriffsszenarien

Szenario 1: Credential Stuffing oder die Verwendung von Passwortlisten sind übliche Angriffe. Sofern eine Anwendung keine automatisierte Erkennung von „Credential Stuffing“ implementiert, können gültige Benutzerdaten durchprobiert und auf Gültigkeit geprüft werden.

Szenario 2: Die meisten Angriffe sind erfolgreich, weil weiterhin auf passwortbasierte Verfahren als einzigen Faktor gesetzt wird. Ehemals als Best-Practice anerkannte Verfahren wie Passwortwechsel und Komplexitätsanforderungen führen nur dazu, dass Benutzer Passwörter wiederverwenden und schwache Passwörter vergeben. Organisationen sind aufgefordert, diese Vorgehensweise entsprechend NIST 800-53 zu verhindern und Mehrfaktor-Authentisierung zu benutzen.

Szenario 3: Die automatische Abmeldung bei Inaktivität ist nicht korrekt implementiert. Ein Nutzer verwendet einen öffentlichen Computer, um auf die Anwendung zuzugreifen. Anstatt die Abmeldefunktion zu nutzen, schließt der Benutzer lediglich den Browsertab. Eine Stunde später nutzt ein Angreifer denselben Browser und stellt fest, dass der Nutzer immer noch angemeldet ist.

Referenzen

OWASP

Andere

← A1-Injection
2017 Inhaltsverzeichnis

PDF version

A3-Verlust der Vertraulichkeit sensibler Daten →

© 2002-2017 OWASP Foundation This document is licensed under the Creative Commons Attribution-ShareAlike 3.0 license. Some rights reserved. CC-by-sa-3 0-88x31.png