Having read about Cross Site Request Forgery I tried to find out how easy it is.
Consider an application that use HTTP GET requests to perform actions. For example if our payroll application were to accept the following request:
I may be tempted to try to trick my manager into making that request. OK, maybe a million pounds would be a bit unsubtle. One technique I could use would be to send an email with the following image tag
<img style="width: 0; height: 0;" src="http://our.company.com/staff/richard/salary?newValue=10000000">
In this case my mischief would be easily traced. Perhaps I could embed the image on a blog or other page that my manager visits.
Any sensible application should not perform actions as a side effect of a GET request. This is part of the HTTP convention: http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html
In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered “safe”. This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is made aware of the fact that a possibly unsafe action is being requested.
Fortunately the attack against our application failed. We overrode the JAX-RS providers, so our result may not be the same as yours. We perform strict content type negotiation, so the request content type of “text/plain” was refused. It seemed a near miss. Our setup was made to give us control of date formats, not because we were thinking about security.
Unfortunately our content type negotiation does not save us. Sockwave Flash reportedly allows cross domain requests to be made with arbitrary content type. We implemented CSRF tokens in our requests to protect against cross site request forgery.
The Future of Cross Domain Requests
Cross Domain Requests are a potentially very useful feature. They make it easy to make mashups in the browser, without needing server side code to perform the requests on behalf of the user. An application may wish to expose an API to cross domain requests. Care would be needed to ensure that they are secure.