CSRF auf GAE Endpoints mit oAuth

Question

Ich bin auf der Suche nach Implementierungen Schutzmaßnahmen gegen CSRF-Angriffe in meiner API, die ich mit GAE Endpoints mit oAuth2 für alle Methoden erforderlich entwickelt.

Vor dem Implementieren eines bestimmten Schutzes versuche ich, meine App zu brechen (CSRF sah auf den ersten Blick einfach aus). Aber es kann einfach nicht funktionieren.

Wenn ich meinen Endpunkt auf einer anderen Seite referenziere, fügt der Browser die Cookie-Informationen, aber nicht den Berechtigungsheader mit dem Bearer Access Token hinzu. Dies scheint nicht genug zu sein, weil meine Endpunkte 401 automatisch mit einem www-authenticate:Bearer realm="https://accounts.google.com/" Header zurückgeben.

Wie gesagt, ich habe keinen spezifischen Schutz gegen CSRF. Aber bietet die Verwendung von Google Cloud Endpoints mit oAuth2 unter HTTPS Schutz gegen diese Art von Angriff "kostenlos"?

- bearbeiten Adresse Kommentar

ich einen einfachen CSRF-Angriff versucht. Ich habe eine Seite mit einem <img src="https://bla-bla-bla-appspot.com/_ah/api/myapi/v1/resource.getMethod"> bekommen. Dann habe ich auf diese Seite zugegriffen, während ich meine App in einem anderen Tab geöffnet hatte, sodass mein Browser meine Authentifizierungsinformationen senden würde. Und es sendet den Cookie, aber nicht mein oAuth-Token).

Ich habe nicht einmal versucht, eine POST, wenn ich ein GET "hack" es wäre schon toll.

Answer 1

OAUth 2.0 explicitly protects against CSRF über die Verwendung eines nicht erratbaren Zustandsparameters, der vom Client generiert und vom Server validiert wird. Selbst wenn ein Angreifer einen Client dazu bringen könnte, eine URL zu besuchen, um ein schädliches Token zu autorisieren, würde der Zustandsparameter nicht mit dem des Clients übereinstimmen und die Anforderung würde abgelehnt.

Die Google Cloud Endpoints-Bibliotheken behandeln dieses Bit der OAuth-Spezifikation für Sie, damit Sie im Klaren sind.

Oauth2 erfordert, dass alle Anforderungen das Trägerzugriffstoken entweder als HTTP-Header haben (verwenden Sie XMLhttpRequest von Javascript, um den Header festzulegen und die Anforderung zu stellen) oder als URL-Abfrageparameter (access_token). Ein Angreifer kennt diesen geheimen Wert nicht und kann daher keine URL erstellen, die die Validierung bestehen würde.

Answer 2

Hier ist (hoffe ich) hilfreich Java-Snippet von meinem Kuoll remote debugger für Web-Anwendungen.

package com.kuoll.server.filters; 

import javax.servlet.*; 
import javax.servlet.http.HttpServletResponse; 
import java.io.IOException; 

public class CrossOriginFilter implements Filter { 

    @Override 
    public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException { 
     HttpServletResponse resp = (HttpServletResponse) response; 

     resp.addHeader("Access-Control-Allow-Origin", "*"); 
     resp.setHeader("Access-Control-Allow-Methods", "POST, OPTIONS"); 
     resp.setHeader("Access-Control-Allow-Headers", "origin, content-type, accept"); 

     chain.doFilter(request, response); 
    } 

    @Override 
    public void init(FilterConfig filterConfig) throws ServletException { 
    } 

    @Override 
    public void destroy() { 
    } 

} 

ersetzen * in resp.addHeader("Access-Control-Allow-Origin", "*"); auf Ihre Herkunft (falls erforderlich).

web.xml

<filter-mapping> 
    <filter-name>CrossOriginFilter</filter-name> 
    <url-pattern>/api/*</url-pattern> 
</filter-mapping>