0

I need to integrate CSRF Prevention in our existing REST Service.

We have created many rest resources and published its detail for other developers to consume. Anyone in the organization can use it. I have no control how he uses it, the form he uses or the httpclient. I have no idea who has used it till date and I cannot change all the clients. Hence, I cannot add a hidden text fields/tokens to the form, since I do not have access to the clients. Also, I cannot use the double authentication or captcha, because it wont work with the httpclient implementations. Is there any other way that I can prevent the misuse of the REST service against CSRF.

dev ray
  • 465
  • 3
  • 6
  • 18
  • Since by REST you have to send the credentials with every request, you don't have to worry about CSRF. If you created a server side session based solution, than that is not REST... You have to tell us more about your solution. You can filter IP addresses maybe. – inf3rno Aug 12 '14 at 11:44
  • Is your REST API consumed client side by web clients? Please add some more details to your question. – SilverlightFox Aug 14 '14 at 09:53
  • @inf3rno - Thanks for the response. My system is not really stateless. You see, I have a REST interface called Login that creates and returns a session for every user. So after calling Login REST Call, if any other Critical REST(CRUD) calls are made the session info is passed back to the server and the user is recognized. But the web-designer/programmer can utilize the this Login and other REST calls at his discretion and I have no access to their forms/code. – dev ray Aug 18 '14 at 10:57
  • @SilverlightFox - Thanks for the Response. I have no idea how the REST is exactly being consumed, but I believe there is a client created in .net(by other teams) that uses the REST protocol to execute CRUD operations on the Server. So, we just expose the Service and the other teams can either have web-forms or some code that can access and utilize these services. – dev ray Aug 18 '14 at 11:00
  • @devray: Do you add CORS headers to allow your service to be contacted by browser clients on different domains? If not then it appears like it is not consumed by browsers directly and therefore you do not need CSRF prevention. – SilverlightFox Aug 18 '14 at 11:03
  • @SilverlightFox - No CORS. See, I have a TestPage which has login, add res, remove res, deleteall etc etc. Using that I login. So my browser gets the session info. Then, I have created another web-application(totally irrelevant). In that I have an html with an button(which say click here to win 10M) - but the action on the button is - http://localhost:8080/restapp/deleteall(where my webservice is running). When I open this html in a different tab and click this button, all my files get deleted. – dev ray Aug 18 '14 at 11:44
  • CSRF-token helps misuse of cookies, but when the session exists, the same CSRF-token(rightone) is sent along with the cookies even from the fake html. So it does not work if one is logged in. – dev ray Aug 18 '14 at 11:45

1 Answers1

0

You could do this by checking the X-Requested-With header.

If any web clients are already using JQuery, then this header will be passed automatically and ensures that the request is not a cross-domain request either by AJAX or by HTML forms. This header will not be sent at all for HTML forms, so this will work if no web clients use HTML forms.

If your web clients use plain JavaScript then you could check that the Origin header is set to a valid domain. Please note that some versions of some browsers do not set this when the request is not cross domain.

The only drawback is that non-web clients would have to set one of these headers, or that you have some way of identifying these non-web clients from your REST service so that you could bypass the checks in these cases.

If you non-web clients already send any headers other than the following:-

  • Accept
  • Accept-Language
  • Content-Language
  • Last-Event-ID
  • Content-Type

then you could verify the value is passed (instead of X-Requested-With or Origin) to ensure that this is not a CSRF attack as custom headers cannot be sent in a CSRF attack. Even the User-Agent could be used - this can be spoofed only by a HTTP client but not by an attacker inside a browser which is the only relevant place that a CSRF attack can happen.

Community
  • 1
  • 1
SilverlightFox
  • 32,436
  • 11
  • 76
  • 145