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?