4

Based on other questions, it seems protecting GET resources with CSRF tokens is useless. However, that quickly becomes untrue when CORS gets thrown into the mix

I have a server domain server.com and a UI app at client.com. The server.com domain handles user auth and sets a session cookie under the server.com domain. It also has a rest-like endpoint that serves GET requests at /user_data and returns sensitive user data to users with a valid session. The 3rd party UI at client.com needs access to the user_data in an AJAX call, so CORS is enabled at the /user_data endpoint for the origin domain client.com via Access-Control-Allow-Origin.

The endpoint in question has no side effects, although it serves sensitive data to a 3rd party. Do I need to implement some CSRF token protection for the endpoint? Could the user_data be read by a compromised client.com webpage (via persistent XSS)? If so, can I use a query param mechanism of CSRF token exchange? The way I understand it, it's the only option, because the client.com cannot read csrf tokens stored in a server.com cookies. However OWASP guidelines state that:

Make sure that the token is not leaked in the server logs, or in the URL.

If that's also a problem, how can I secure my application?

Leprechaun
  • 143
  • 3

1 Answers1

3

it seems protecting GET resources with CSRF tokens is useless.

It's not useless if you have state-changing GET request (which you shouldn't have, but it does happen).

Do I need to implement some CSRF token protection for the endpoint?

No, requests which do not change state do not need CSRF protection (they may need proper authorization though).

Could the user_data be read by a compromised client.com webpage (via persistent XSS)?

Yes, if you allow client.com to read data from server.com via CORS, then a compromised client.com can read that data as well.

If so, can I use a query param mechanism of CSRF token exchange? The way I understand it, it's the only option, because the client.com cannot read csrf tokens stored in a server.com cookies.

No, CSRF protection wouldn't help. client.com can't read the cookie from server.com, but it can read anything on client.com. And you would need client.com to know the CSRF token to be able to send requests with it to server.com.

how can I secure my application?

Do not let client.com be compromised. There's no other way to prevent client.com (compromised) from accessing data on server.com while also permitting client.com (not compromised) to access data on server.com because those two can't be distinguished.

Make sure that the token is not leaked in the server logs, or in the URL.

You can send the token in a custom HTTP header to prevent this. But see above as to why it won't help if client.com is already compromised.

tim
  • 29,018
  • 7
  • 95
  • 119