T.Gigler: Created Page

2019-03-08T12:30:02Z

Created Page

New page

{{Top_10_2013:TopTemplate
|useprev=2017PrevLink
|prev=A1-{{Top_10_2010:ByTheNumbers
|1
|year=2017
|language=de
}}
|usenext=2017NextLink
|next=A3-{{Top_10_2010:ByTheNumbers
|3
|year=2017
|language=de
}}
|year=2017
|language=de
}}

{{Top_10_2010:SummaryTableHeaderBeginTemplate|year=2017|language=de}}
{{Top_10-2017:SummaryTableTemplate|exploitability=3 |prevalence=2 |detectability=2 |impact=3 |year=2017|language=de}}
{{Top_10_2010:SummaryTableHeaderEndTemplate|year=2017}}
<td colspan=2 {{Template:Top_10_2010:SummaryTableRowStyleTemplate|year=2017}}>

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. </td>
<td colspan=2 {{Template:Top_10_2010:SummaryTableRowStyleTemplate|year=2017}}>

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. </td>
<td colspan=2 {{Template:Top_10_2010:SummaryTableRowStyleTemplate|year=2017}}>

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. </td>
{{Top_10_2010:SummaryTableEndTemplate|year=2017}}

{{Top_10:SubsectionTableBeginTemplate|type=main}}
{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=isTheApplicationVulnerable|position=firstLeft|year=2017|language=de}}
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|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. [[{{Top_10:LanguageFile|text=documentRootTop10New|language=de|year=2017 }}_A3-{{Top_10_2010:ByTheNumbers|3|year=2017|language=de}} | A3:2017-{{Top_10_2010:ByTheNumbers|3|year=2017|language=de}}]]).
* 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.

{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=howToPrevent|position=right|year=2017|language=de}}
* 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 [https://github.com/danielmiessler/SecLists/tree/master/Passwords 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 [https://pages.nist.gov/800-63-3/sp800-63b.html#memsecret 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.

{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=exampleAttackScenarios|position=left|year=2017|language=de}}
Szenario 1: [[Credential_stuffing|Credential Stuffing]] oder die Verwendung [https://github.com/danielmiessler/SecLists 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.

{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=references|position=right|year=2017|language=de}}
{{Top_10_2010:SubSubsectionOWASPReferencesTemplate|year=2017|language=de}}

* [[OWASP_Proactive_Controls#5:_Implement_Identity_and_Authentication_Controls|OWASP Proactive Controls: Implement Identity and Authentication Controls]]
* [[:Category:OWASP_Application_Security_Verification_Standard_Project|OWASP Application Security Verification Standard: V2 Authentication]]
* [[:Category:OWASP_Application_Security_Verification_Standard_Project|OWASP Application Security Verification Standard: V3 Session Management]]
* [[Testing_Identity_Management|OWASP Testing Guide: Identity]], [[Testing_for_authentication|Authentication]]
* [[Authentication_Cheat_Sheet|OWASP Cheat Sheet: Authentication]]
* [[Credential_Stuffing_Prevention_Cheat_Sheet|OWASP Cheat Sheet: Credential Stuffing]]
* [[Forgot_Password_Cheat_Sheet|OWASP Cheat Sheet: Forgot Password]]
* [[Session_Management_Cheat_Sheet|OWASP Cheat Sheet: Session Management]]
* [[OWASP_Automated_Threats_to_Web_Applications|OWASP Automated Threats Handbook]]

{{Top_10_2010:SubSubsectionExternalReferencesTemplate|year=2017|language=de}}
* [https://pages.nist.gov/800-63-3/sp800-63b.html#memsecret NIST 800-63b: 5.1.1 Memorized Secrets]
* [https://cwe.mitre.org/data/definitions/287.html CWE-287: Improper Authentication]
* [https://cwe.mitre.org/data/definitions/384.html CWE-384: Session Fixation]

{{Top_10_2013:BottomAdvancedTemplate
|type=box
|useprev=2017PrevLink
|prev=A1-{{Top_10_2010:ByTheNumbers
|1
|year=2017
|language=de
}}
|usenext=2017NextLink
|next=A3-{{Top_10_2010:ByTheNumbers
|3
|year=2017
|language=de
}}
|year=2017
|language=de
}}

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

T.Gigler: Created Page