Cross-Site Request Forgery (CSRF)[pronounced see-surf] is an attack that forces an end user to execute unwanted actions on a web application in which they're currently authenticated.

For example lets say I'm logged-in into my bank website and I haven't logged out. Since my session stays active for around 20 minutes on the server, although I have navigated to a different website, if that website submits a form to my bank then that request could be done successfully.

Typically, CSRF attacks are possible against web sites that use cookies for authentication, because browsers send all relevant cookies to the destination web site.

Default session expiry time in ASP.NET is 20 minutes and in PHP it is 24 minutes.

CSRF Defences

If cookies are used to store authentication tokens and to authenticate API requests on the server, CSRF is a potential problem. If local storage is used to store the token, CSRF vulnerability might be mitigated because values from local storage aren't sent automatically to the server with every request. Thus, using local storage to store the antiforgery token on the client and sending the token as a request header is a recommended approach.

1. Synchroniser Tokens (requires session state)

Server generates a random token that is associated with the user's current session and stores that in the session and also in a hidden field in the form. For each request client sends the request along with this token and server checks if the token is valid for active user.

If storing the CSRF token in session is problematic, an alternative defense is use of a double submit cookie. A double submit cookie is defined as sending a random value in both a cookie and as a request parameter, with the server verifying if the cookie value and request value match.

ASP.NET anti forgery token works this way, it creates a token and stores that in a cookie and a hidden field, when user submits the form two values get posted to the server and if they match server performs the action.

It works because in the case of CSRF attack, attacker cannot read the cookie, so he doesn't know what the token is hence he cannot create a hidden field with that token in their fake form.

3. Encrypted Token Pattern

After successful authentication, the server generates a unique Token comprised of the user's ID, a timestamp value and a nonce, using a unique key available only on the server. This Token is returned to the client and embedded in a hidden field. On the receipt of a request, server reads and decrypts the Token value with the same key used to create the Token. Inability to correctly decrypt suggest an intrusion attempt. Once decrypted, the UserId and timestamp contained within the token are validated to ensure validity; the UserId is compared against the currently logged in user, and the timestamp is compared against the current time.

4. Custom Header

Adding CSRF tokens, a double submit cookie and value, encrypted token, or other defense that involves changing the UI can frequently be complex or otherwise problematic. An alternate defense which is particularly well suited for AJAX endpoints is the use of a custom request header. This defense relies on the same-origin policy restriction that only JavaScript can be used to add a custom header, and only within its origin. By default, browsers don't allow JavaScript to make cross origin requests.

Same Origin Policy

Means that I can send request from my website to any other websites but I cannot read the response from that request because the origin of the request I have created in not the same as destination site.

AJAX calls only send Cookies if the URL you're calling is on the same domain as your calling script. hence if your are calling another domain browser won't send any cookies to protect your privacy.