Cross-Site Request Forgery (also known as XSRF, CSRF, and Cross Site Reference Forgery) works by exploiting the trust that a site has for the user.

CSRF is an attack which forces an end user to execute unwanted actions on a web application in which he/she is currently authenticated. With a little help of social engineering (like sending a link via email/chat), an attacker may trick the users of a web application into executing actions of the attacker’s choosing.

A CSRF attack does not exploit any browser vulnerability. As long as a user is logged into the vulnerable web site, simply browsing a malicious webpage can lead to unintended operations performed on the vulnerable web site.

How CSRF Attack Works?

Launching such CSRF attacks is possible in practice because many users browse multiple sites in parallel, and users often do not explicitly log out when they finish using a web site. A CSRF attack can also be carried out without a user visiting a malicious webpage. In a recent CSRF attack against residential ADSL routers in Mexico, an e-mail with a malicious IMG tag was sent to victims. By viewing the email message, the user initiated an HTTP request, which sent a router command to change the DNS entry of a leading Mexican bank, making any subsequent access by a user to the bank go through the attacker’s server.

• CSRF takes advantage of web applications that allow attackers to predict all the details of a particular action.
• Since browsers send credentials like session cookies automatically, attackers can create malicious web pages which generate forged requests that are indistinguishable from legitimate ones.
• Attackers can cause victims to change any data the victim is allowed to change or perform any function the victim is authorized to use
• Attacker creates forged HTTP requests and tricks a victim into submitting them via image tags, XSS, or numerous other techniques. If the user is authenticated, the attack succeeds.

An example of CSRF Attack:

A CSRF attack works as follows. While accessing the bank account, the user simultaneously browses some other web sites. One of the site ‘www.somesite.com’, contains a hidden form and a piece of JavaScript. As soon as the user visits the webpage, the browser silently submit the hidden form to ‘fictitiousbank.com’. The format and content of the request are exactly the same as the request triggered by the user clicking the submit button in the “pay bill” form provided by the bank. On sending the request, the user’s browser automatically attaches the authentication cookies to the request. Since the session is still active in the server, the request will be processed by the server as issued by the user.

Am I vulnerable to CSRF?

• The easiest way to check whether an application is vulnerable is to see if each link and form contains an unpredictable token in addition to session tokens, for each user.
• Without such an unpredictable token, attackers can forge malicious requests. Focus on the links and forms that invoke state-changing functions, since those are the most important CSRF targets.

HOW DO I PREVENT CSRF?

• Preventing CSRF requires the inclusion of an unpredictable token in the body or URL of each HTTP request. Such tokens should at a minimum be unique per user session, but can also be unique per request.
  • The preferred option is to include the unique token in a hidden field. The unique token can also be included in the URL itself, or a URL parameter.
  • Check Referrer field of each request.
  • Use Captcha on all critical page.

Sources: OWASP Foundation, Wikipedia & Indusface Internal Analysis