Cross-Site Request Forgery is a web-based attack, in which an attacker could launch an action on behalf of an authenticated user, without the user “actually” performing it. This vulnerability According to OWASP, “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.

The malicious code is often not on the attacked site. This is why it is called ‘Cross Site’. ”

Let us understand it more by taking an example :

Bob is logged on to a shopping website named for example http://myshoppingwebsite.com.
Alice, is the attacker, knows that Bob uses myshoppignwebsite.com. Alice then finds out that there exists a CSRF vulnerability on the website.
Alice then crafts a URL, similar to http://myshoppingwebsite.com/completepayment.php?pid=32.
Alice then embeds the URL in an iframe to a forum which bob visits.
As soon as Bob visits the forum, the payment is done by Bob’s account on that shopping website.

This is an example of a cross-site scripting attack on an e-commerce shopping website.

A Cross-Site Request Forgery tricks an authenticated user (in most cases) to send a request to the web application in order to perform malicious action chosen by the attacker. The request originating from a third-party website would look exactly the same as it would have been generated by a legitimate source, and it will be granted the same privileges. Unlike XSS, which exploits the trust a user has on the website, CSRF exploits the trust, a user has on his web browser.

Let’s take another example of a banking website, on which the user is already authenticated.

Now, the banking website would perform specific actions, only if requested by a user who is authenticated.

The attacker sends a link

(http://mysafebankingwebsite.com/transferfromacc=my&toaccount=attacker&balance=20000)

to the victim using Social Engineering, and makes him click on it. Nothing, in particular, happened as seen by the victim. But in reality, the victim made a request of transferring $20000 from his account to the attacker’s account.

The following characteristics are common in a CSRF attack :

Involve sites that rely on a user’s identity
Exploit the site’s trust in that identity
Trick the user’s browser into sending HTTP requests to a target site
Involve HTTP requests that have side effects.

According to Bill Zeller (1983-2011),
CSRF vulnerabilities occur when a website allows an authenticated user to perform a sensitive action but does not verify that the user herself is invoking that action.

The key to understanding CSRF attacks is to recognize that websites typically don’t verify that a request came from an authorized user. Instead, they verify only that the request came from the browser of an authorized user. Because browsers run code sent by multiple sites, there is a danger that one site will send a request to a second site, and the second site will mistakenly think that the user authorized the request.

Using CSRF, an attacker could post messages to his Social Networking Profiles, transfer funds, delete his account, change the username, vote in an online poll, subscribe to an online newsletter, and much more.

Just like other web application vulnerabilities, this also occurs due to negligence by the web developers. It is also said that if a web developer doesn’t add additional protection against CSRF, he is vulnerable to CSRF.

Following is a graphical representation of a CSRF attack in progress :