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/A8-Cross-Site Request Forgery (CSRF)"
m (Bei 'Top_10_2010:SummaryTableHeaderEndTemplate' die Parameter '|year=2013|language=de' ergänzt; 'Top_10_2010_Developer_Edition_De:SummaryTableHeaderBeginTemplate'->'Top_10_2010:SummaryTableHeaderBeginTemplate') |
(Updated according to OWASP Top10 2013 DE) |
||
Line 19: | Line 19: | ||
}} | }} | ||
− | {{Top_10_2010:SummaryTableHeaderBeginTemplate|type=images|year= | + | {{Top_10_2010:SummaryTableHeaderBeginTemplate|type=images|year=2013|language=de}} |
{{Top_10:SummaryTableTemplate|exploitability=2|prevalence=2|detectability=1|impact=2|language=de|year=2013}} | {{Top_10:SummaryTableTemplate|exploitability=2|prevalence=2|detectability=1|impact=2|language=de|year=2013}} | ||
{{Top_10_2010:SummaryTableHeaderEndTemplate|year=2013|language=de}} | {{Top_10_2010:SummaryTableHeaderEndTemplate|year=2013|language=de}} | ||
− | <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Jeder, der einem | + | <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Jeder, der einem Browser Inhalte unterschieben kann, die nicht beabsichtigte Requests auslösen. Hierfür kommt jede Website oder jede HTML-Quelle in Betracht, die der Nutzer verwendet.</td> |
− | <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Durch Image-Tags, XSS oder andere Techniken löst das Opfer unbeabsichtigt einen gefälschten HTTP-Request für eine Anwendung aus. <u>Falls der Nutzer | + | <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Durch Image-Tags, XSS oder andere Techniken löst das Opfer unbeabsichtigt einen gefälschten HTTP-Request für eine Anwendung aus. <u>Falls der Nutzer authentifiziert ist</u>, wird dieser Angriff Erfolg haben.</td> |
− | <td colspan=2 {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>[[CSRF]] | + | <td colspan=2 {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>[[CSRF]] nutzt aus, dass es bei den meisten Webanwendungen möglich ist, die Inhalte eines Requests für eine bestimmte Aktion vorherzusagen. |
− | + | Da Browser Informationen zum Session-Management automatisch mitsenden, kann ein Angreifer gefälschte Requests auf bösartigen Websites hinterlegen, die von autorisierten und gewollten Requests nicht unterschieden werden können. | |
− | Da Browser Informationen zum Session-Management automatisch mitsenden, kann ein Angreifer gefälschte Requests auf bösartigen Websites hinterlegen, die von | ||
CSRF-Schwächen sind leicht durch Penetrationstests oder Quellcode-Analysen auffindbar.</td> | CSRF-Schwächen sind leicht durch Penetrationstests oder Quellcode-Analysen auffindbar.</td> | ||
− | <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}> | + | <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Angreifer können über den Browser des Opfers alle zustandsändernden Aktionen auslösen, für das es berechtigt ist, z.B. Ändern von Daten, Aufgeben von Bestellungen, Logout und Login, usw.</td> |
− | <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}>Betrachten Sie den Geschäftswert der betroffenen Daten oder Funktionen. Es bleibt die Unsicherheit, ob der Nutzer die Aktion ausführen wollte. | + | <td {{Template:Top 10 2010:SummaryTableRowStyleTemplate}}> |
− | + | Betrachten Sie den Geschäftswert der betroffenen Daten oder Funktionen. Es bleibt die Unsicherheit, ob der Nutzer die Aktion ausführen wollte. | |
Bedenken Sie mögliche Auswirkungen auf Ihre Reputation.</td> | Bedenken Sie mögliche Auswirkungen auf Ihre Reputation.</td> | ||
{{Top_10_2010:SummaryTableEndTemplate}} | {{Top_10_2010:SummaryTableEndTemplate}} | ||
− | {{Top_10:SubsectionTableBeginTemplate|type=main}} {{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=example|position=firstLeft|risk= | + | {{Top_10:SubsectionTableBeginTemplate|type=main}} {{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=example|position=firstLeft|risk=8|year=2013|language=de}} |
− | Die Anwendung erlaubt es einem Benutzer, einen '''zustandsändernden Request''' auszulösen, der kein geheimes Token beinhaltet, wie z.B.: | + | Die Anwendung erlaubt es einem Benutzer, einen '''zustandsändernden Request''' auszulösen, der kein geheimes Token beinhaltet, wie z.B.: |
: '''<nowiki>http://example.com/app/transferFunds?amount=1500&destinationAccount=4673243243</nowiki>''' | : '''<nowiki>http://example.com/app/transferFunds?amount=1500&destinationAccount=4673243243</nowiki>''' | ||
− | Dadurch kann ein Angreifer einen Request erzeugen, der Geld vom Konto des Opfers auf das Konto des Angreifers transferiert. Diesen bettet | + | Dadurch kann ein Angreifer einen Request erzeugen, der Geld vom Konto des Opfers auf das Konto des Angreifers transferiert. Diesen bettet der Angreifer „unsichtbar“ in ein Image-Tag oder ein Iframe ein und hinterlegt ihn in einer beliebigen Website: |
: '''<nowiki><img src="http://example.com/app/transferFunds?</nowiki><span style="color: red;"><nowiki>amount=1500&destinationAccount=attackersAcct#" width="0" height="0" /></nowiki>'''</span> | : '''<nowiki><img src="http://example.com/app/transferFunds?</nowiki><span style="color: red;"><nowiki>amount=1500&destinationAccount=attackersAcct#" width="0" height="0" /></nowiki>'''</span> | ||
− | Wenn das Opfer eine präparierte Seite besucht, während es | + | Wenn das Opfer eine präparierte Seite besucht, während es bereits auf '''example.com authentifiziert''' ist, werden diese '''untergeschobenen Requests''' automatisch gültige Session-Informationen mit versenden. Die Requests sind somit unbeabsichtigt autorisiert. |
− | {{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=howPrevent|position=right|risk= | + | {{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=howPrevent|position=right|risk=8|year=2013|language=de}} |
− | Um CSRF zu verhindern, | + | Um CSRF zu verhindern, sollte jede Eingabeseite einen Token beinhalten. Der Token sollte unvorhersagbar und für jede Session, besser für jedes Formular, einzigartig sein und vom Server geprüft werden. |
− | # Die bevorzugte Methode, | + | # Die bevorzugte Methode, das Token einzubetten, ist ein Hidden-Input-Feld. Damit wird der Token-Wert im Body des Requests und nicht im URL übertragen (erleichtert sonst Ausspähung). |
− | # Ein solches Token kann auch direkt in den URL geschrieben oder als URL-Parameter übergeben werden. Jedoch birgt diese Vorgehensweise das Risiko, dass der URL dem Angreifer in die Hände fällt und somit das geheime Token kompromittiert ist. OWASPs [[CSRFGuard | CSRF Guard]] kann genutzt werden, um automatisch solche Token in Java EE, .NET oder PHP Anwendungen einzubinden. OWASPs | + | # Ein solches Token kann auch direkt in den URL geschrieben oder als URL-Parameter übergeben werden. Jedoch birgt diese Vorgehensweise das Risiko, dass der URL dem Angreifer in die Hände fällt und somit das geheime Token kompromittiert ist.<br/>OWASPs [[CSRFGuard | CSRF Guard]] kann genutzt werden, um automatisch solche Token in Java EE, .NET oder PHP Anwendungen einzubinden. OWASPs [[ESAPI]] beinhaltet Token-Generatoren und Validatoren, die Entwickler einsetzen können, um ihre Transaktionen zu schützen. |
+ | # Aktive Rückbestätigung vom Benutzer (erneute Authentifizierung, CAPTCHA-Eingabe, usw.) kann auch vor CSRF schützen. | ||
{{Top_10:SubsectionTableEndTemplate}} | {{Top_10:SubsectionTableEndTemplate}} | ||
Revision as of 16:35, 12 June 2015
← A7-Fehlerhafte Autorisierung auf Anwendungsebene | A9-Nutzung von Komponenten mit bekannten Schwachstellen → |
Anwendungs- spezifisch |
Ausnutzbarkeit DURCHSCHNITTLICH |
Verbreitung HÄUFIG |
Auffindbarkeit EINFACH |
Auswirkung MITTEL |
Anwendungs-/ Geschäftsspezifisch |
Jeder, der einem Browser Inhalte unterschieben kann, die nicht beabsichtigte Requests auslösen. Hierfür kommt jede Website oder jede HTML-Quelle in Betracht, die der Nutzer verwendet. | Durch Image-Tags, XSS oder andere Techniken löst das Opfer unbeabsichtigt einen gefälschten HTTP-Request für eine Anwendung aus. Falls der Nutzer authentifiziert ist, wird dieser Angriff Erfolg haben. | CSRF nutzt aus, dass es bei den meisten Webanwendungen möglich ist, die Inhalte eines Requests für eine bestimmte Aktion vorherzusagen.
Da Browser Informationen zum Session-Management automatisch mitsenden, kann ein Angreifer gefälschte Requests auf bösartigen Websites hinterlegen, die von autorisierten und gewollten Requests nicht unterschieden werden können. CSRF-Schwächen sind leicht durch Penetrationstests oder Quellcode-Analysen auffindbar. |
Angreifer können über den Browser des Opfers alle zustandsändernden Aktionen auslösen, für das es berechtigt ist, z.B. Ändern von Daten, Aufgeben von Bestellungen, Logout und Login, usw. |
Betrachten Sie den Geschäftswert der betroffenen Daten oder Funktionen. Es bleibt die Unsicherheit, ob der Nutzer die Aktion ausführen wollte. Bedenken Sie mögliche Auswirkungen auf Ihre Reputation. |
Mögliche Angriffsszenarien
Die Anwendung erlaubt es einem Benutzer, einen zustandsändernden Request auszulösen, der kein geheimes Token beinhaltet, wie z.B.:
Dadurch kann ein Angreifer einen Request erzeugen, der Geld vom Konto des Opfers auf das Konto des Angreifers transferiert. Diesen bettet der Angreifer „unsichtbar“ in ein Image-Tag oder ein Iframe ein und hinterlegt ihn in einer beliebigen Website:
Wenn das Opfer eine präparierte Seite besucht, während es bereits auf example.com authentifiziert ist, werden diese untergeschobenen Requests automatisch gültige Session-Informationen mit versenden. Die Requests sind somit unbeabsichtigt autorisiert. |
Wie kann ich 'Cross-Site Request Forgery (CSRF)' verhindern?
Um CSRF zu verhindern, sollte jede Eingabeseite einen Token beinhalten. Der Token sollte unvorhersagbar und für jede Session, besser für jedes Formular, einzigartig sein und vom Server geprüft werden.
|
Verteidigungs-Option 1 gegen 'Cross-Site Request Forgery (CSRF)':
ESAPI /** (A) CSRF-Token erzeugen **/
%> /** (B2) das CSRF-Token als URL Parameter in den GET-Request hinzufügen, jedoch **/
%>
}
|
Verteidigungs-Option 2 gegen 'Cross-Site Request Forgery (CSRF)':
CSRF Guard
<context-param>
</context-param>
</context-param>
</listener>
</filter>
</filter-mapping> vgl Owasp.CsrfGuard.Test |
Verteidigungs-Option 3 gegen 'Cross-Site Request Forgery (CSRF)':
Java Server Faces (JSF)JSF sendet ab Version 2.2 automatisch sichere CSRF-Token mit. ... |
Auswirkung(en) auf den Benutzer
Tbd!!
Z.B. Keine Bookmarks auf ausgefüllte Eingabe-Formulare, Suchergebnisse; Frameworks funktionieren teilweise nicht für Web 2.0 |
Referenzen
OWASP
Andere |
Verteidigungs-Option 1 gegen 'Cross-Site Request Forgery (CSRF)':
...
|
Verteidigungs-Option 2 gegen 'Cross-Site Request Forgery (CSRF)':
|
Verteidigungs-Option 3 gegen 'Cross-Site Request Forgery (CSRF)':
... |
Referenzen
OWASP
Andere |
Verteidigungs-Option 1 gegen 'Cross-Site Request Forgery (CSRF)':
ASP.NET Web Formulare(noch unbearbeitet => tbd) private const string AntiXsrfTokenKey = "__AntiXsrfToken";
} |
Verteidigungs-Option 2 gegen 'Cross-Site Request Forgery (CSRF)':
tbd Text |
Verteidigungs-Option 3 gegen 'Cross-Site Request Forgery (CSRF)':
tbd Text | |
Auswirkung(en) auf den Benutzer
Z.B. Keine Bookmarks auf ausgefüllte Eingabe-Formulare, Suchergebnisse; Frameworks funktionieren teilweise nicht für Web 2.0 |
Referenzen
OWASP Andere OWASP
Andere |
Verteidigungs-Option 1 gegen 'Sicherheitsrelevante Fehlkonfiguration':
tbd Text |
Verteidigungs-Option 2 gegen 'Sicherheitsrelevante Fehlkonfiguration':
tbd Text |
Verteidigungs-Option 3 gegen 'Cross-Site Request Forgery (CSRF)':
(ganze Breite) Text | |
Wie kann ich 'Cross-Site Request Forgery (CSRF)' verhindern?
Text | |
Auswirkung(en) auf den Benutzer
Text |
Referenzen
|
← A7-Fehlerhafte Autorisierung auf Anwendungsebene | A9-Nutzung von Komponenten mit bekannten Schwachstellen → |
![CC-by-sa-3 0-88x31.png](/images/6/64/CC-by-sa-3_0-88x31.png)