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

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.

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&amp;destinationAccount=4673243243 

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:

''' &lt;img src=&quot;http://example.com/app/transferFunds? amount=1500&amp;destinationAccount=attackersAcct#&quot; width=&quot;0&quot; height=&quot;0&quot; /&gt; '''

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.

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.
 * 1) 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).
 * 2) 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 beinhaltet Token-Generatoren und Validatoren, die Entwickler einsetzen können, um ihre Transaktionen zu schützen.
 * 3) Aktive Rückbestätigung vom Benutzer (erneute Authentifizierung, CAPTCHA-Eingabe, usw.) kann auch vor CSRF schützen.

= JAVA =

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;

%>  " 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);

%>  ' target="_blank">Transfer Funds  /** (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;

CSRF Guard

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

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

</context-param>
 * <listener-class>org.owasp.csrfguard.CsrfGuardListener</listener-class>

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

    <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.

Java Server Faces (JSF)
JSF sendet ab Version 2.2 automatisch sichere CSRF-Token mit.


 * OWASP CSRF Prevention Cheat Sheet
 * OWASP CSRF Article
 * OWASP CSRFGuard - CSRF Defense Tool
 * OWASP CSRFGuard - CSRFGuard_3_Installation
 * OWASP CSRFGuard - CSRFGuard_3_Configuration
 * ESAPI Project Home Page
 * ESAPI HTTPUtilities Class with AntiCSRF Tokens
 * ESAPI-Java-Wiki
 * OWASP Testing Guide: Chapter on CSRF Testing
 * OWASP CSRFTester - CSRF Testing Tool


 * CWE Entry 352 on CSRF
 * John Melton's Weblog: The OWASP Top Ten and ESAPI –Part 5–

= PHP =

...

...



... Tbd: konfig ...


 * OWASP CSRF Prevention Cheat Sheet
 * OWASP CSRF Article
 * OWASP CSRFGuard - CSRF Defense Tool
 * ESAPI Project Home Page
 * OWASP Testing Guide: Chapter on CSRF Testing
 * OWASP CSRFTester - CSRF Testing Tool


 * CWE Entry 352 on CSRF
 * John Melton's Weblog: The OWASP Top Ten and ESAPI –Part 5–

= .NET =

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;
 * Response.Cookies.Set(responseCookie);
 * }
 * Page.PreLoad += master_Page_PreLoad;

}

Quelle: .NET Security Cheat Sheet

tbd Text

tbd Text

Z.B. Keine Bookmarks auf ausgefüllte Eingabe-Formulare, Suchergebnisse; Frameworks funktionieren teilweise nicht für Web 2.0
 * {Soll so etwas rein?}


 * OWASP CSRF Prevention Cheat Sheet
 * OWASP CSRF Article
 * OWASP CSRFGuard - CSRF Defense Tool
 * OWASP CSRFGuard - CSRFGuard_3_Installation
 * OWASP CSRFGuard - CSRFGuard_3_Configuration
 * ESAPI Project Home Page
 * ESAPI HTTPUtilities Class with AntiCSRF Tokens
 * ESAPI-Java-Wiki
 * OWASP Testing Guide: Chapter on CSRF Testing
 * OWASP CSRFTester - CSRF Testing Tool
 * .NET Security Cheat Sheet


 * CWE Entry 352 on CSRF
 * OWASP Top 10 for .NET developers (Troy Hunt)