Cross site request forgery

The underlying framework provides protection for the application against cross-site request forgery (CSRF), which maliciously exploits a web site where unauthorized commands are transmitted from a user that the web site trusts.

CSRF (also called XSRF) is different from cross-site scripting (CSS or XSS), which exploits the trust a user has for a particular site. CSRF is also known as one-click attack, sidejacking, or session riding.

CSRF works by including a link or script in a page that accesses a site to which the user is known (or is supposed) to have authenticated. For example, User A might be browsing a forum where User B has posted a message. With CSRF, User B might create the following HTML image element that, instead of being an image file, references a script on the web site of User A's bank and requests a withdrawal of $1,000,000:

<img src="http://bank.example/withdraw?amount=1000000&for=USER-B">

If User A's bank keeps their authentication information in a cookie, and if the cookie hasn't expired, then the attempt by User A's browser to load the image will submit the withdrawal form with the authentication cookie, and authorize a transaction without User A's approval.

In this scenario, the problem can be summed up in the following three points:

Because of the browser's policy, the authentication cookies are sent to the bank server even though the request originated from a different web site.
User A's bank stores authentication information in a cookie and completely relies on the cookies for authentication purposes.
User A's bank does not differentiate between GET and POST requests.

The CSRF protection in the underlying framework does not apply to the first point, since it is a browser policy. But it does apply to the second and third points by using both a cookie and an additional token for authentication. CSRF attacks are usually prevented by always checking for a unique token in each request that hits the server. In the underlying framework, the token is used in the following manner:

When login finishes, a newly created token is set for the session (for validation purposes). This token is available on the client side of the application.
The token is used in the following ways:
- This token is used for all AJAX requests and within the underlying framework utilities.
- When a POST or GET request is made to the server, the application automatically validates that the CSRF token is available in the request.