Should I use CSRF protection for GET requests?

Question

I've seen several blanket statements on the web to the effect that you don't need CSRF protection for GET requests.

But many web applications have GET requests that return sensitive data, right? Then wouldn't you want to protect those against CSRF attacks?

Am I missing something, or are these blanket statements assuming that the data the GET request gives is unimportant?

Examples of blanket recommendations gainst using CSRF tokens with GET:

• https://security.stackexchange.com/a/90027/5997

  Therefore, if a website has kept to the standard and only implements "unsafe" actions as POSTs, then here only POST requests are vulnerable.

• http://www.django-rest-framework.org/topics/ajax-csrf-cors/

  1. Ensure that the 'safe' HTTP operations, such as GET, HEAD and OPTIONS cannot be used to alter any server-side state.

  The assumption here is that if GET doesn't modify state, it's not worth protecting.

• http://sakurity.com/blog/2015/03/04/hybrid_api_auth.html contains a code line that suggests this approach:

  # 1) verify CSRF token for all non-GET requests
  

Answer 1

CSRF protection is only needed for state-changing operations because of the same-origin policy. This policy states that:

a web browser permits scripts contained in a first web page to access data in a second web page, but only if both web pages have the same origin.

So the CSRF attack will not be able to access the data it requests because it is a cross-site (that's the CS in CSRF) request and prohibited by the same-origin policy. So illicit data access is not a problem with CSRF.

As a CSRF attack can execute commands but can't see their results, it is forced to act blindly. For example, a CSRF attack can tell your browser to request your bank account balance, but it can't see that balance. This is obviously a pointless attack (unless you're trying to DDoS the bank server or something). But it is not pointless if, for example, the CSRF attack tells your browser to instruct your bank to transfer money from your account to the attacker's account. The success or failure page for the transfer is inaccessible to the attacking script. Fortunately for the attacker, they don't need to see the bank's response, they just want the money in their account.

As only state-changing operations are likely to be targets of CSRF attacks, only they need CSRF defenses.

Answer 2

Ordinarily safe methods do not have to be protected against CSRF because they do not make changes to the application, and even if they're returning sensitive information this will be protected by the Same Origin Policy in the browser.

If your site is implemented as per standards, your GET requests should be safe and therefore do not need protection.

However, there is a specific case where a "Cross-Site DoS"^* attack could be executed. Say your reporting page takes 10 seconds to execute, with 100% CPU usage on your database server, and 80% CPU usage on your web server.

Users of your website know never to go to https://yoursite.example.org/Analysis/GetReport during office hours because it kills the server and gives other uses a bad user experience.

However, Chuck wants to knock your yoursite.example.org website offline because he doesn't like you or your company.

On the busy forum he posts to often, http://forum.walkertexasranger.example.com, he sets his signature to the following:

<img src="https://yoursite.example.org/Analysis/GetReport" width=0 height=0 />

He also know that your company employees frequent the forum, often while also logged into yoursite.example.org.

Every time one of Chuck's posts are read by your employees, authentication cookies are sent to https://yoursite.example.org/Analysis/GetReport, so your site processes the request and generates the report, and your system goes offline because CPU is eaten by these constant requests.

So even though the request is a GET request and doesn't make any permanent changes to your system (aka "safe"), it is infact bringing down your system every time it is ran. Therefore, it would be better to protect this with a CSRF prevention method.

^{*XSDoS, or Cross-Site Denial if Service, is a phrase coined by me, so don't go Googling for it.}

Answer 3

CSRF protection is not used to protect data. It is used to protect a user from unknowingly changing state, such as transferring money or logging out of an account.

Thus, if your GET request is changing a state (which it shouldn't be), then you should have CSRF protection. But if it's just returning data, it doesn't need CSRF protection, because CSRF protection wouldn't protect anything in this case.

It may help to go over this page again: https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29

Answer 4

CSRF, or Cross-Site Request Forgery, isn't about protecting data from being retrieved, but protecting data from being changed. This is also referred to as state changes. In an application, state changes can include profile data, like the email address, user password, or biography, or transferring funds.

GET requests are to be used for idempotent requests, or requests that do not change state. These requests do not need to have anti-CSRF tokens.

POST requests are to be used for non-idempotent requests, or requests that do change state.

Answer 5

Generally, POST requests should be used for changing the state of something. If you have GET requests set up so that they can change the state (e.g. www.example.com/settings?delete_account=True), then you should use CSRF protection as a Band-Aid fix.

Try to use POSTs to change the state, not GETs.