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
Difference between revisions of "Germany/Projekte/Top 10 fuer Entwickler-2013/A2-Fehler in Authentifizierung und Session-Management"
m (kleinere Textänderungen (ohne inhaltliche Änderung)) |
|||
Line 21: | Line 21: | ||
{{Top_10_2010:SummaryTableValue-1-Template|Auswirkung|SCHWERWIEGEND}} | {{Top_10_2010:SummaryTableValue-1-Template|Auswirkung|SCHWERWIEGEND}} | ||
{{Top_10_2010:SummaryTableHeaderEndTemplate}} | {{Top_10_2010:SummaryTableHeaderEndTemplate}} | ||
− | <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Nicht authentifizierte Angreifer sowie | + | <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Nicht authentifizierte Angreifer sowie authentifizierte Nutzer könnten versuchen, Zugangs- daten anderer zu stehlen. In Betracht kommen außerdem Innentäter, die ihre Handlungen verschleiern wollen.</td> |
− | <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Angreifer nutzen Lücken bei der | + | <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Angreifer nutzen Lücken bei der Authentifizierung oder im Sessionmanagement (z.B. ungeschützte Nutzerkonten, Passwörter, Session-IDs), um sich eine fremde Identität zu verschaffen.</td> |
<td colspan=2 {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Obwohl es sehr schwierig ist, ein sicheres Authentifizierungs- und Session-Management zu implementieren, setzen Entwickler häufig auf eigene Lösungen. Diese haben dann oft Fehler bei Abmeldung und Passwortmanagement, bei der Wiedererkennung des Benutzers, bei Timeouts, Sicherheitsabfragen usw. Das Auffinden dieser Fehler kann sehr schwierig sein, besonders wenn es sich um individuelle Implementierungen handelt.</td> | <td colspan=2 {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Obwohl es sehr schwierig ist, ein sicheres Authentifizierungs- und Session-Management zu implementieren, setzen Entwickler häufig auf eigene Lösungen. Diese haben dann oft Fehler bei Abmeldung und Passwortmanagement, bei der Wiedererkennung des Benutzers, bei Timeouts, Sicherheitsabfragen usw. Das Auffinden dieser Fehler kann sehr schwierig sein, besonders wenn es sich um individuelle Implementierungen handelt.</td> | ||
− | <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Diese Fehler führen zur Kompromittierung von Benutzerkonten. Ein erfolgreicher Angreifer hat alle Rechte des Opfers. Privilegierte | + | <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Diese Fehler führen zur Kompromittierung von Benutzerkonten. Ein erfolgreicher Angreifer hat alle Rechte des Opfers. Privilegierte Zugänge sind oft Ziel solcher Angriffe.</td> |
− | <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Betrachten Sie den Geschäftswert der | + | <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Betrachten Sie den Geschäftswert der betroffenen Daten oder Anwendungsfunktionen. Betrachten Sie weiterhin Auswirkungen auf das Unter-nehmen beim Bekanntwerden der Schwachstelle.</td> |
{{Top_10_2010:SummaryTableEndTemplate}} | {{Top_10_2010:SummaryTableEndTemplate}} | ||
Line 50: | Line 50: | ||
<b>Erfinde das Sessionmanagement nicht neu!</b> Die verbreiteten Plattformen (wie Tomcat, Websphere, u.a.) liefern das alles schon mit.<br> | <b>Erfinde das Sessionmanagement nicht neu!</b> Die verbreiteten Plattformen (wie Tomcat, Websphere, u.a.) liefern das alles schon mit.<br> | ||
Grundsätzliche Anforderungen an das Session Management: | Grundsätzliche Anforderungen an das Session Management: | ||
− | * | + | * SessionID mit TLS schützen (wie alle Authentifizierungsdaten) |
− | * | + | * die SessionID hat in der URL nichts verloren |
− | * nach jeder erfolgreichen | + | * nach jeder erfolgreichen Authentifizierung eine neue SessionID generieren |
− | * | + | * für die Erzeugung der SessionID einen kryptografisch sicheren Zufallszahlengenerator verwenden (Entropy mindestens 128bit) |
− | * | + | * der Timeout von Cookies sollte so schnell wie möglich erfolgen (beim Onlinebanking ist ein Wert von ca 10 Min. mittlerweile Standard) |
− | * | + | * beim Logout/TimeOut wird die SessionID auf dem Server ungültig gemacht |
− | * | + | * grundsätzlich das Secure-Attribut für Cookies benutzen |
− | * | + | * für Cookies das httponly-Attribut setzen |
− | * | + | * Domain-und Pfad-Attribut in Cookies so eng wie möglich setzen |
{{Top_10_2010:ExampleBeginTemplate}} | {{Top_10_2010:ExampleBeginTemplate}} |
Revision as of 15:04, 6 April 2013
← Top_10_fuer_Entwickler/A2_Cross-Site Scripting (XSS) | Top_10_fuer_Entwickler/A4_Unsichere direkte Objektreferenzen → |
Seite in Bearbeitung (BAUSTELLE!!)
A3 Fehler in Authentifizierung und Session-Management
______ | Ausnutzbarkeit DURCHSCHNITTLICH |
Verbreitung HÄUFIG |
Auffindbarkeit DURCHSCHNITTLICH |
Auswirkung SCHWERWIEGEND |
Application / Business Specific |
Nicht authentifizierte Angreifer sowie authentifizierte Nutzer könnten versuchen, Zugangs- daten anderer zu stehlen. In Betracht kommen außerdem Innentäter, die ihre Handlungen verschleiern wollen. | Angreifer nutzen Lücken bei der Authentifizierung oder im Sessionmanagement (z.B. ungeschützte Nutzerkonten, Passwörter, Session-IDs), um sich eine fremde Identität zu verschaffen. | Obwohl es sehr schwierig ist, ein sicheres Authentifizierungs- und Session-Management zu implementieren, setzen Entwickler häufig auf eigene Lösungen. Diese haben dann oft Fehler bei Abmeldung und Passwortmanagement, bei der Wiedererkennung des Benutzers, bei Timeouts, Sicherheitsabfragen usw. Das Auffinden dieser Fehler kann sehr schwierig sein, besonders wenn es sich um individuelle Implementierungen handelt. | Diese Fehler führen zur Kompromittierung von Benutzerkonten. Ein erfolgreicher Angreifer hat alle Rechte des Opfers. Privilegierte Zugänge sind oft Ziel solcher Angriffe. | Betrachten Sie den Geschäftswert der betroffenen Daten oder Anwendungsfunktionen. Betrachten Sie weiterhin Auswirkungen auf das Unter-nehmen beim Bekanntwerden der Schwachstelle. |
Bin ich durch 'Fehler in Authentifizierung und Session-Management' verwundbar?
Szenario 1: Eine Flugbuchungsanwendung fügt die Session ID in die URL ein: http://example.com/sale/saleitems;jsessionid=2P0OC2JDPXM0OQSNDLPSKHCJUN2JV?dest=Hawaii
Ein authentifizierter Anwender möchte dieses Angebot seinen Freunden mitteilen. Er versendet obigen Link per E-Mail, ohne zu wissen, dass er seine Session-ID preisgibt. Nutzen seine Freunde den Link, können sie seine Session sowie seine Kreditkartendaten benutzen. Szenario 2: Anwendungs-Timeouts sind falsch konfiguriert. Ein Anwender verwendet einen öffentlichen PC, um die Anwendung aufzurufen. Anstatt die „Abmelden“ Funktion zu nutzen, schließt der Anwender nur den Browser. Der Browser ist auch eine Stunde später noch authentifiziert, wenn ein potentieller Angreifer ihn öffnet. Szenario 3: Ein Angreifer erlangt Zugang zur unverschlüsselten Passwortdatenbank des Systems. Damit fallen alle Zugangsdaten im Klartext in die Hände des Angreifers. |
Wie kann ich 'Fehler in Authentifizierung und Session-Management' verhindern?
Wir empfehlen Organisationen und Unternehmen, ihren Entwicklern folgende Mittel bereitzustellen:
|
style="vertical-align: top; padding:5px; width: 50%; border: 3px solid
- 4F81BD;
background-color:
- F2F2F2;">
Erfinde das Sessionmanagement nicht neu! Die verbreiteten Plattformen (wie Tomcat, Websphere, u.a.) liefern das alles schon mit.
Grundsätzliche Anforderungen an das Session Management:
- SessionID mit TLS schützen (wie alle Authentifizierungsdaten)
- die SessionID hat in der URL nichts verloren
- nach jeder erfolgreichen Authentifizierung eine neue SessionID generieren
- für die Erzeugung der SessionID einen kryptografisch sicheren Zufallszahlengenerator verwenden (Entropy mindestens 128bit)
- der Timeout von Cookies sollte so schnell wie möglich erfolgen (beim Onlinebanking ist ein Wert von ca 10 Min. mittlerweile Standard)
- beim Logout/TimeOut wird die SessionID auf dem Server ungültig gemacht
- grundsätzlich das Secure-Attribut für Cookies benutzen
- für Cookies das httponly-Attribut setzen
- Domain-und Pfad-Attribut in Cookies so eng wie möglich setzen
tbd
</td> <td style="vertical-align: top; padding:5px; width: 50%; border: 3px solid
- 4F81BD;
background-color:
- F2F2F2;">
tbd
style="vertical-align: top; padding:5px; width: 50%; border: 3px solid
- 4F81BD;
background-color:
- F2F2F2;">
tbd
style="vertical-align: top; padding:5px; width: 50%; border: 3px solid
- 4F81BD;
background-color:
- F2F2F2;">
OWASP
- OWASP SQL Injection Prevention Cheat Sheet
- OWASP Injection Flaws Article
- ESAPI Encoder API
- ESAPI Input Validation API
- ASVS: Output Encoding/Escaping Requirements (V6)
- OWASP Testing Guide: Chapter on SQL Injection Testing
- OWASP Code Review Guide: Chapter on SQL Injection
- OWASP Code Review Guide: Command Injection
Andere
</td></tr></table>
style="vertical-align: top; padding:5px; width: 50%; border: 3px solid
- 4F81BD;
background-color:
- F2F2F2;">
tbd Text
</td> <td style="vertical-align: top; padding:5px; width: 50%; border: 3px solid
- 4F81BD;
background-color:
- F2F2F2;">
tbd Text
style="vertical-align: top; padding:5px; width: 50%; border: 3px solid
- 4F81BD;
background-color:
- F2F2F2;">
tbd Text
style="vertical-align: top; padding:5px; width: 50%; border: 3px solid
- 4F81BD;
background-color:
- F2F2F2;">
(ganze Breite) Text
style="vertical-align: top; padding:5px; width: 50%; border: 3px solid
- 4F81BD;
background-color:
- F2F2F2;">
</td></tr></table>
← Top_10_fuer_Entwickler/A2_Cross-Site Scripting (XSS) | Top_10_fuer_Entwickler/A4_Unsichere direkte Objektreferenzen → |