1. The client receives code from the attacker, via either a compromised server or a
script or image tag placed by the attacker on a third-party web site (possibly via
XSS). The code references a URI of the target application that performs some
action.
2. The client requests that URI from the target application, sending the authentication
cookie (because the client is already authenticated to the target). The target
then performs the action on the client??™s behalf, even though the end user did not
authorize the action.
CSRF mitigation
The first and foremost way to defend against CSRF is to use the proper HTTPverbs.
This has been the mantra of the Rails core team since before Rails 1.0. GET and HEAD
requests should be safe: they can be called without changing server state. GET, HEAD,
PUT, and DELETE should be idempotent: calling them once or 100 times should have
the same effect. (They are defined this way so that a client, unsure if a request has
completed, can retry the same request with no ill effects.)
So, the primary problem with the preceding example is that it used a verb that
should be safe (GET) with an action that caused side effects (instant_purchase). If the
action had in fact been free of side effects, there would have been no problem. No
confidential information could be leaked directly, as the response went directly from
the target to the client.
Pages:
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223