What is CSRF?

Cross-site request forgery (CSRF) is a type of exploit of your web site whereby a malicious party may be able to perform operations posing as a given user of your site, without that user having authorized those operations, or even being aware they are performed.

In a nutshell, here is how a CSRF attack works:

1. The setup – You are a client of Acme Bank. Through Acme Bank's web site, you can transfer funds from your account to someone else's account. When doing so, say transfering $1,000 to account #123, your browser issues a request that looks like http://acmebank.com/transfer?to=123&amount=1000. (We're using an GET in this example for simplicity, but the attack also works if requests are issues through a POST.)
2. Authentication and HTTPS – To be able to issue that command you need to be logged in. When you log in, the bank site give your browser a cookie, say JSESSIONID=abc, which your browser then sends with every request. Since the value of this cookie was chosen by the bank site just for this session, and given just to you over a secure connection, the site can be certain that every request you issue comes from you. If a malicious party where to issue the request http://acmebank.com/transfer?to=123&amount=1000, the bank site would just reject it because the malicious party didn't provide the proper cookie. And again, thanks to HTTPS, there is no way for them to know what the value of the cookie is, even if they had the ability to eavesdrop on your connection. So you're safe, right? Not quite.
3. The attack – A malicious party can't issue that HTTP transfer directly. But what if they put the link somewhere and get you to click on it. For instance, the link could be in an email, a message you get on a social network, or a web site you usually go to and that they managed to hack. Then the request will be issued by your browser, which will send the cookie, assuming you're still logged into the bank site. And bingo, the transfer will happen.

What can web apps do to prevent CSFR?

A web app can protect its users against CSRF attacks by generating for each user connecting to the site a random token, and requiring that token to be sent along every request. (And of course a mechanism other than cookies must be used to send this token with every request.) Software packages, such as Spring Security or OWASP CSRFGuard, can make it easier for you to do this in your own web application.

Orbeon Forms does this out-of-the-box

Orbeon Forms does everything required to prevent CSRF attacks, out-of-the-box, so this is one less thing you'll need to worry about. Specifically, every time users load a page containing a form, Orbeon Forms generates a document id, which acts as the token described earlier. That document id is then sent with every request, Ajax or form POST, and Orbeon Forms won't execute the request if the document id isn't valid, and doesn't match the session cookie.

This post was updated on 2014-05-23 to include more information on how CSRF attacks work, and to describe how Orbeon Forms completely prevents CSRF attacks on forms it generates.