Author Archives: Sebastiaan van den Broek

I’ve seen the answer Is CSRF possible if I don’t even use cookies? but there are 2 conflicting answers and the question itself doesn’t provide that much information either.

I am creating a REST API that will be used by a web client (of our own creation) running on another domain, so we will be doing CORS requests. This API runs as an oauth2 resource server, so access is restricted by access tokens which are passed in the authentication header. We do not have any cookies there, everything is stateless. I am following the advice in the article at https://spring.io/blog/2011/11/30/cross-site-request-forgery-and-oauth2

• We will use SSL
• We have pre-registered redirect uri’s
• Our only grant type is authorization code, without requiring a client secret (as the web client source is public) instead of the implicit grant type, as per the recommendations on https://oauth.net/2/grant-types/implicit/
• The client authenticates with a header when it does actual resource server calls
• Obtaining the access token is done by passing the 1-time authorization code in form parameters (x-www-form-urlencoded), which seems to be the normal way, shouldn’t get stuck in browser history as it’s not a query parameter.
• The client will also use some secret state parameter when getting the authorization code. In this case I’m not sure there is a point since the client does not depend on a secret to get an access token by exchanging a code anyway.
• For the oauth/token endpoint where you actually get an access token, the only allowed origin is the domain of our web client
• For the oauth/authorize endpoint, CORS is not allowed. Perhaps this is excessive since the redirect uri would only point back at our own domain anyway?

I think that covers pretty much everything on that side.

Now there IS another possible attack vector in the form of the oauth2 authentication server itself, which is supposed to be SSO and does have sessions and is accessible with basic auth. However, there do not seem to be any actions you could take with a csrf attack that would actually be useful. You could do a request to these oauth endpoints but you would have to be able to read the result, which is prevented by the CORS configuration and the fact the redirect uri’s are pre-registered. There is no POST you can do there to change your password, reset your email address, et cetera, all those things are actually also exposed as a resource server.

Am I missing anything? How would you go about probing for vulnerabilities here?

Continue reading Do I need CSRF protection in this setup with a REST API backed with oauth2 and a basic auth SSO auth server?→