Cross Site Request Forgery

Definition:

Cross site request forgery is not a new attack, but is simple and devastating. A CSRF attack forces a logged-on victim’s browser to send a request to a vulnerable web application, which then performs the chosen action on behalf of the victim.

This vulnerability is extremely widespread, as any web application that Has no authorization checks for vulnerable actions Will process an action if a default login is able to be given in the request (e.g. http://www.example.com/admin/doSomething.ctl?username=admin&passwd=admin)

Authorizes requests based only on credentials that are automatically submitted such as the session cookie if currently logged into the application, or “Remember me” functionality if not logged into the application, or a Kerberos token if part of an Intranet participating in integrated logon with Active Directory is at risk.

Unfortunately, today, most web applications rely solely on automatically submitted credentials such as session cookies, basic authentication credentials, source IP addresses, SSL certificates, or Windows domain credentials.

This vulnerability is also known by several other names including Session Riding, One-Click Attacks, Cross Site Reference Forgery, Hostile Linking, and Automation Attack. The acronym XSRF is also frequently used. OWASP and MITRE have both standardized on the term Cross Site Request Forgery and CSRF.

Protection:

Applications must ensure that they are not relying on credentials or tokens that are automatically submitted by browsers. The only solution is to use a custom token that the browser will not ‘remember’ like a unique hidden field or an additional unique GET/POST parameter and then automatically include this token with every request to the web application. A CSRF attack that does not use this token will be stopped.

The following strategies should be inherent in all web applications:

• Insert custom random tokens into every form and URL that will not be automatically submitted by the browser. and then verify that the submitted token is correct for the current user.

• For sensitive data or value transactions, re-authenticate or use transaction signing to ensure that the request is genuine. Set up external mechanisms such as e-mail or phone contact in order to verify requests or notify the user of the request.

• Do not use GET requests (URLs) for sensitive data or to perform value transactions. Use only POST methods when processing sensitive data from the user. POST alone is insufficient as a protection. You must also combine it with random tokens, out of band authentication or re-authentication to properly protect against CSRF.

• Verify the Content-Type to protect calls to Ajax functions and web services

While these suggestions will diminish your exposure dramatically, advanced CSRF attacks can bypass many of these restrictions. The strongest technique is the use of unique tokens, and eliminating all XSS vulnerabilities in your application.

.Net Overview:
We check that incoming requests have a Referer header referencing our domain.
And we put a user-specific token as a hidden field in legitimate forms, and check that the right value was submitted. Generally the user specific values are GUIDs.