Germany/Projekte/Top 10 fuer Entwickler-2013/A8-Cross-Site Request Forgery (CSRF)

A8 Cross-Site Request Forgery (CSRF, XSRF, Session Riding)


Anwendungs- spezifisch	Ausnutzbarkeit DURCHSCHNITTLICH	Verbreitung HÄUFIG	Auffindbarkeit EINFACH	Auswirkung MITTEL	Anwendungs-/ Geschäftsspezifisch
Jeder, der einem Nutzer einer Webanwendung einen nicht beabsichtigten Request für diese Anwendung unterschieben kann. 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 authentisiert ist, wird dieser Angriff Erfolg haben.	CSRF zielt auf Anwendungen, die es dem Angreifer erlauben, alle Details 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 legitimen Requests nicht unterschieden werden können. CSRF-Schwächen sind leicht durch Penetrationstests oder Quellcode-Analysen auffindbar.		Der Angreifer kann unbemerkt das Opfer über dessen Browser dazu veranlassen, alle Daten zu ändern oder jede Funktion auszuführen, für die das spezifische Opfer berechtigt ist.	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.:

http://example.com/app/transferFunds?amount=1500&destinationAccount=4673243243

Dadurch kann ein Angreifer einen Request erzeugen, der Geld vom Konto des Opfers auf das Konto des Angreifers transferiert. Diesen bettet er in einem Image-Tag oder einem Iframe ein und hinterlegt ihn in einer beliebigen Website.

<img src="http://example.com/app/transferFunds?amount=1500&destinationAccount=attackersAcct#" width="0" height="0" />

Wenn das Opfer eine präparierte Seite besucht, während es z.B. bereits auf example.com authentisiert ist, wird der untergeschobene Request unbemerkt ausgeführt, da der Browser die aktuellen Session-Informationen automatisch mitsendet und somit unbeabsichtigt autorisiert.

Wie kann ich 'Cross-Site Request Forgery (CSRF)' verhindern?

Um CSRF zu verhindern, muss ein unvorhersagbarer Token im Body oder in der URL eines jeden HTTP-Requests eingebettet sein (und geprüft werden). Ein solcher Token sollte für mindestens jede Nutzer-Session, besser noch für jeden Request, einzigartig sein.

Die bevorzugte Methode, ein solches Token unterzubringen ist ein Hidden-Input-Feld. Damit wird der Token-Wert im Body des HTTP-Requests und nicht im URL übertragen. Eine Übertragung im URL kann leichter ausgespäht werden.
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 CSRF Guard kann genutzt werden, um automatisch solche Token in Java EE, .NET oder PHP Anwendungen einzubinden. OWASPs ESAPI / OWASP’s ESAPI (tbd!!) beinhaltet Token-Generatoren und Validatoren, die Entwickler einsetzen können, um ihre Transaktionen zu schützen.

JAVA
PHP
.NET
Test

Verteidigungs-Option 1 gegen 'Cross-Site Request Forgery (CSRF)':

ESAPI

 /** (A) CSRF-Token erzeugen **/ 

private String csrfToken = resetCSRFToken();

/** (B) In zu schützenden FORM-Seiten (B1), oder Urls (B2) das CSRF-Token als 'hidden field' hinzufügen, vgl ESAPI DefaultHTTPUtilities.java**/

/** (B1) das CSRF-Token als 'hidden field' in den GET-Request hinzufügen **/

example.jsp

...

<% 
  String csrfTokenFieldName = org.owasp.esapi.HTTPUtilities.CSRF_TOKEN_NAME;
  String csrfToken = ESAPI.httpUtilities().getCSRFToken();%>

<input type="hidden" id="<%=csrfTokenFieldName%>" value="<%=csrfToken%>"/>

...

/** (B2) das CSRF-Token als URL Parameter in den GET-Request hinzufügen, jedoch **/

/** höheres Risiko, dass die URL und damit das Token dem Angreifer in die Hände fällt **/

<%
  String unprotectedHref = "/main?function=TransferFunds&solution";
  String betterProtectedHref = ESAPI.httpUtilities().addCSRFToken(unprotectedHref);
%>

<a href='<%=betterProtectedHref%>' target="_blank">Transfer Funds</a>

/** (C) Beim Empfang der Daten das CSRF-Token prüfen (GET-Request) **/

try {
 ESAPI.httpUtilities().verifyCSRFToken(request);
 } catch( IntrusionException e ) {

 // log intrusion exception
 // abort request and deny access}

/** (D) Beim Abmelden bzw. Timeout die Session ungültig machen **/

User  user = ESAPI.authenticator().logout;

Verteidigungs-Option 2 gegen 'Cross-Site Request Forgery (CSRF)':

CSRF Guard

/** Parameter für CsrfGuard und Java EE-Filter im Deployment **/
/** Descriptor des Webserver-Containers definieren (web.xml-Datei) **/
<context-param>
	<param-name>Owasp.CsrfGuard.Config</param-name>
 	<param-value>WEB-INF/Owasp.CsrfGuard.properties</param-value></context-param>

 	
<context-param>
	<param-name>Owasp.CsrfGuard.Config.Print</param-name>
	<param-value>true</param-value></context-param>

 	
<listener>
	<listener-class>org.owasp.csrfguard.CsrfGuardListener</listener-class></listener>


<filter>
	<filter-name>CSRFGuard</filter-name>
	<filter-class>org.owasp.csrfguard.CsrfGuardFilter</filter-class></filter>

<filter-mapping>
	<filter-name>CSRFGuard</filter-name>
	<url-pattern>/*</url-pattern></filter-mapping>

vgl Owasp.CsrfGuard.Test
Die Parameter in der Datei 'Owasp.CsrfGuard.properties' gemäß CSRFGuard_3_Configuration einstellen.

Verteidigungs-Option 3 gegen 'Cross-Site Request Forgery (CSRF)':

Java Server Faces (JSF)

JSF sendet ab Version 2.2 automatisch sichere CSRF-Token mit.

...

Tbd: konfig

... 

Auswirkung(en) auf den Benutzer

Tbd!!

{Soll so etwas rein?}

Z.B. Keine Bookmarks auf ausgefüllte Eingabe-Formulare, Suchergebnisse; Frameworks funktionieren teilweise nicht für Web 2.0

Referenzen

OWASP

Andere

« JAVA

JAVA »

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)':

...

Tbd: konfig

... 

Referenzen

OWASP

Andere

« PHP

PHP »

Verteidigungs-Option 1 gegen 'Cross-Site Request Forgery (CSRF)':

ASP.NET Web Formulare

(noch unbearbeitet => tbd)
If you don't use Viewstate, then look to the default master page of the ASP.NET Web Forms default template for a manual anti-CSRF token.

private const string AntiXsrfTokenKey = "__AntiXsrfToken";

private const string AntiXsrfUserNameKey = "__AntiXsrfUserName";

private string _antiXsrfTokenValue;

protected void Page_Init(object sender, EventArgs e)

{

   // The code below helps to protect against XSRF attacks
   var requestCookie = Request.Cookies[AntiXsrfTokenKey];
   Guid requestCookieGuidValue;
   if (requestCookie != null && Guid.TryParse(requestCookie.Value, out requestCookieGuidValue))
   {
      // Use the Anti-XSRF token from the cookie
      _antiXsrfTokenValue = requestCookie.Value;
      Page.ViewStateUserKey = _antiXsrfTokenValue;
   } else {
     // Generate a new Anti-XSRF token and save to the cookie
     _antiXsrfTokenValue = Guid.NewGuid().ToString("N");
     Page.ViewStateUserKey = _antiXsrfTokenValue;
     var responseCookie = new HttpCookie(AntiXsrfTokenKey)
     {
         HttpOnly = true,
         Value = _antiXsrfTokenValue
     };
     if (FormsAuthentication.RequireSSL && Request.IsSecureConnection)
     {
         responseCookie.Secure = true;
     }
     Response.Cookies.Set(responseCookie);
   }
   Page.PreLoad += master_Page_PreLoad;}

Quelle: .NET Security Cheat Sheet

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

{Soll so etwas rein?}

Z.B. Keine Bookmarks auf ausgefüllte Eingabe-Formulare, Suchergebnisse; Frameworks funktionieren teilweise nicht für Web 2.0

Referenzen

OWASP Andere OWASP

Andere

« .NET

.NET »

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