Academic Integrity: tutoring, explanations, and feedback — we don’t complete graded work or submit on a student’s behalf.

I was in the middle of implementing a CSRF protection mechanism for my server wh

ID: 661498 • Letter: I

Question

I was in the middle of implementing a CSRF protection mechanism for my server when I realized that this attack only really affects web browsers. It got me wondering: why should I bother generating/validating CSRF tokens for non-browser clients?

Not only would removing such checks simplify the implementation of REST clients, it would also improve scalability.

I was thinking of having all HTML resources set a browserId cookie containing a cryptographically-strong pseudorandom value which identifies the client as a browser. Any calls into the REST api would check for this cookie and, if present, apply CSRF validation. Otherwise, the checks would be skipped.

The value of the cookie is not as important as its existence. The value is not stored or validated by the server, but it is useful for tying CSRF tokens to a specific browser (this prevents an attacker from passing his own CSRF token to a victim).

My question is as follows:

- Is it possible to differentiate between machine-to-machine (M2M) and human-to-machine (H2M) clients? If so, what is the best way (is the above approach reasonable)?
- Is it safe to differentiate between M2M and H2M clients, even if we can? Or does this open us up to possible attacks in the future?
- Can an attacker delete cookies, assuming that I control all sub-domains and use HTTPS?

Explanation / Answer

CSRF is for forms mostly and it is not used for REST APIs at all. When REST API is implemented with API keys and nonce, you could say that these 2 act as your cross-site request forgery protection.

Also, when designing REST API it's usually best to avoid such things as cookies at all. Use per-user API Keys, this will also solve your identification problems.

Is it possible to differentiate between machine-to-machine (M2M) and human-to-machine (H2M) clients? If so, what is the best way (is the above approach reasonable)?

For a rest API it should NOT matter if the client is a machine or a human. To identify humans, use per-human API key which should be supplied upon every request. There is no such thing as machine or human (i.e. there is no difference). Everyone is a client for the API.

Is it safe to differentiate between M2M and H2M clients, even if we can? Or does this open us up to possible attacks in the future?

Answered above (you should not need to do this).

Can an attacker delete cookies, assuming that I control all sub-domains and use HTTPS?

Answered above (you should not use cookies for REST APIs).

Hire Me For All Your Tutoring Needs
Integrity-first tutoring: clear explanations, guidance, and feedback.
Drop an Email at
drjack9650@gmail.com
Chat Now And Get Quote