9

I'm looking to implement protections against CSRF attacks in my API, which I developed using GAE Endpoints with oAuth2 required for all methods.

Before implementing any specific protection I'm trying to actually break my app (CSRF looked simple at first glance). But just can't make it work.

When I reference my endpoint in another page, the browser adds the cookie information but not the Authorization header with the bearer access token. This does not seem to be enough, because my endpoints automatically return 401 with a www-authenticate:Bearer realm="https://accounts.google.com/" header.

As I said, I have no specific protection against CSRF. But does using Google Cloud Endpoints with oAuth2 under HTTPS grants me protection against this type of attack "for free"?

--edit to address comment

I tried a simple CSRF attack. I got a page up with an <img src="https://bla-bla-bla-appspot.com/_ah/api/myapi/v1/resource.getMethod">. Then I accessed this page while I had my app opened in another tab, so my browser would send my authentication information. And it does send the cookie, but not my oAuth token).

I didn't even tried doing a POST, if I "hack" a GET it would be great already.

Henrique G. Abreu
  • 17,406
  • 3
  • 56
  • 65
  • Not sure if you seen [this](http://stackoverflow.com/questions/16688489/cloud-endpoints-csrf-protection) and the article that's linked in comments, but it seams (if I understood correctly) that with OAuth2 CSRF isn't an issue. I might be wrong tho', if you find any answers elsewhere, please share (; – Sasxa Jan 26 '16 at 09:52
  • What concretely do you mean by "When I reference my endpoint in another page, the browser adds the cookie information but not the Authorization header with the bearer access token"? Could you show the code? – Nick Jan 26 '16 at 23:44

2 Answers2

2

OAUth 2.0 explicitly protects against CSRF via the use of a non-guessable state parameter which is generated by the client and validated by the server. Even if an attacker was able to trick a client into visiting a URL to authorize a malicious token, the state parameter would not match that of the client and the request would be denied.

The Google Cloud Endpoints libraries handle this bit of the OAuth spec for you, so you're in the clear.

Oauth2 requires all requests to have the bearer access token either as an HTTP header (use XMLhttpRequest from javascript to set the header and make the request) or as a URL query parameter (access_token). An attacker won't know this secret value, so would not be able to create a URL which would pass validation.

Community
  • 1
  • 1
Dave Snigier
  • 2,574
  • 3
  • 21
  • 29
  • The link you provided is about CSRF attacks against the OAuth Authorization server, but does the OAuth2 token protects my app server against such attacks? – Henrique G. Abreu Feb 05 '16 at 18:28
0

Here is (I hope) helpful java snippet from my Kuoll remote debugger for web apps.

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

}

Replace * in resp.addHeader("Access-Control-Allow-Origin", "*"); to your Origin (if needed).

web.xml

<filter-mapping>
    <filter-name>CrossOriginFilter</filter-name>
    <url-pattern>/api/*</url-pattern>
</filter-mapping>
Dmitry Kaigorodov
  • 1,512
  • 18
  • 27
  • Setting headers in Filter does not work in App Engine... But anyway, you didn't say anything about CSRF... as I said, I'm looking for how to break my app before blindly implementing any fixes (or proof that I'm actually already protected). But thanks – Henrique G. Abreu Feb 05 '16 at 18:22