CSRF на GAE Конечные точки с oAuth

Question

Я ищу для реализации защиты от атак CSRF в моем API, которые я разработал с использованием конечных точек GAE с oAuth2, необходимых для всех методов.

Перед тем как реализовать какую-либо специальную защиту, я пытаюсь на самом деле разорвать свое приложение (CSRF выглядел простым на первый взгляд). Но просто не могу заставить его работать.

Когда я ссылаюсь на свою конечную точку на другой странице, браузер добавляет информацию cookie, но не заголовок авторизации с токеном доступа к каналу. Это, похоже, не достаточно, потому что мои конечные точки автоматически возвращают 401 с заголовком www-authenticate:Bearer realm="https://accounts.google.com/".

Как я уже сказал, у меня нет конкретной защиты от CSRF. Но использует ли Google Cloud Endpoints с oAuth2 под HTTPS, предоставляет мне защиту от этого типа атаки «бесплатно»?

- редактировать обратиться комментарий

Я попытался простой атаки CSRF. У меня есть страница с <img src="https://bla-bla-bla-appspot.com/_ah/api/myapi/v1/resource.getMethod">. Затем я обратился к этой странице, пока мое приложение открылось на другой вкладке, поэтому мой браузер отправит мою идентификационную информацию. И он отправляет файл cookie, но не мой токен oAuth).

Я даже не пробовал делать POST, если я «взломал» GET, было бы здорово уже.

Answer 1

OAUth 2.0 explicitly protects against CSRF с использованием неопределяемого параметра состояния, который создается клиентом и проверяется сервером. Даже если злоумышленник смог обмануть клиента при посещении URL-адреса для авторизации вредоносного токена, параметр состояния не будет соответствовать параметру клиента, и запрос будет отклонен.

Библиотеки Google Cloud Endpoints обрабатывают этот бит спецификации OAuth для вас, поэтому вы находитесь в ясном виде.

Oauth2 требует, чтобы все запросы имели токен доступа к каналу либо как HTTP-заголовок (используйте XMLhttpRequest из javascript для установки заголовка и запроса), либо как параметр запроса URL (access_token). Злоумышленник не знает этого секретного значения, поэтому не сможет создать URL-адрес, который будет проходить проверку.

Answer 2

Вот (я надеюсь) полезный фрагмент java из моего Kuoll remote debugger для веб-приложений.

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() { 
    } 

} 

Заменить * в resp.addHeader("Access-Control-Allow-Origin", "*"); ваше происхождение (в случае необходимости).

web.xml

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