Home > Blockchain >  My web application is not publicly hosted, do I need to worry about CSRF?
My web application is not publicly hosted, do I need to worry about CSRF?

Time:04-27

My web app is not publicly available and will be used by certain verified users within a firewall. Do I need to worry about CSRF? Reading about the CSRF attacks and the below:

From Spring documentation:- 18.3 When to use CSRF protection

When should you use CSRF protection? Our recommendation is to use CSRF protection for any request that could be processed by a browser by normal users. If you are only creating a service that is used by non-browser clients, you will likely want to disable CSRF protection.

I believe apps hosted publicly are more susceptible.

Thank you in advance!

CodePudding user response:

Naturally I do not know the exact circumstances or environment you are dealing with; so I can't say beyond a reasonable doubt here.

Your risk factor is definitely low, being that the web app it is not publicly accessible, behind firewalls, verified users. But it depends on what your app is doing.

I've found that XSRF or CSRF protection is only needed for domains that use cookies. Every request to your site carries your cookies even if the request comes from a web page not controlled by you. It is most important when you are modifying state on the server but there are cases where it can be useful even in cases where state is not changed.

This guide here contains a short tutorial on XSRF and how to avoid it, and allows you to actually try it out.

CodePudding user response:

CSRF is one of the attacks that is actually used to bypass firewalls. So it sounds like you do need protection if authentication in your app relies on something sent automatically by the browser (eg. session cookies). If authentication tokens are not sent automatically (you have explicit Javascript to attach them to requests, like request headers), then you are inherently protected from CSRF.

In case of CSRF, the unsuspecting victim user, while being logged in to your (internal) application visits a malicious external site. That site then creates a request (eg. POSTs) the user to your apps internal url, with appropriate parameters to do something your user didn't want. As cookies are sent automatically to the destination domain, the request will be valid and processed by your app (even in case of javascript, mostly).

Notice that the user doing the internal request is your victim user with access to the internal resource. So the firewall is bypassed, the victim's browser was tricked into making the request.

Also note that this required knowledge of your app (most probably a targeted attack specifically against your app). That reduces the risk somewhat, but it is still very much a risk from a security perspective. You don't want to rely on security by obscurity, ie. you should assume that attackers know everything about your application except cryptographic secrets, but including endpoints, parameters necessary and so on. That will not always be the case, but you should design for this to make it secure.

  • Related