CSRF (cross site request forgeries )

               CSRF  (cross site request forgeries ) ATTACK

CSRF is an almost opposite type of attack. Rather than exploiting the trust that a user has for a particular site, CSRF exploits the trust that a site has for a particular user. In the case of XSS, the user is the victim. In the case of CSRF, the user is an accomplice.
Because CSRF involves a forged HTTP request, it is important to first understand a little bit about HTTP, the protocol that web clients and servers use to communicate. Web clients (browsers) send HTTP requests to web servers, and the servers return HTTP responses in reply. A request and its corresponding response make up an HTTP transaction.

The word CSRF itself means that the attack is done using a cross-site request; it’s “forged” because it’s invisible to the user. A cross-site request is one where a page loaded from one website makes a request to another site for resources that are part of the page (like images, for example). While it’s easy for a malicious site to have such HTML code in its pages, such cross-site requests can also be caused by viewing bulletin boards, forums, or social networking sites (for example) where users are allowed to post images with foreign URL sources — that is, the images are hosted on other sites. CSRF attacks are effective in situations which meet the following criteria:

• The victim has an active session on the target site.
• The victim is authenticated by implicit authentication mechanisms (like cookies or HTTP authentication) on the target site.

                

                   The differences between XSS and CSRF

Though CSRF seems similar to Cross-Site Scripting (XSS) at first, both are completely different attack vectors. Where XSS aims at inserting active code in an HTML document to either abuse client-side active scripting holes, or to send privileged information (e.g., authentication/session cookies) to an unknown evil website, CSRF aims to perform unwanted actions on a website where the victim has some prior relationship and authority.
Moreover, where XSS sought to steal your online trading cookies so an attacker could manipulate a victim’s account, CSRF seeks to use the victims’ cookies to force them to execute a trade without their knowledge or consent. While XSS attacks exploits the trust that a user has on the website, CSRF attacks exploit the trust that the website has in its user.

 

Types of CSRF attacks

CSRF attacks can be divided into two major categories — reflected and stored/local.

 

Reflected CSRF attacks

In a reflected CSRF attack, the attacker uses a system outside the application to expose the victim to the exploit link or content. This can be done using a blog, an email message, an instant message, a message-board posting, or even a flyer posted in a public place with a URL that a victim types in.
Reflected CSRF attacks will frequently fail, as users may not be currently logged into the target system when the exploits are tried. The trail from a reflected CSRF attack, however, may be under the attacker’s control, and could be deleted once the exploit is completed. The three attack scenarios we looked at earlier are examples of reflected CSRF attacks.

 

Local/stored CSRF attacks

A stored/local CSRF attack is one where the attacker can use the application itself to provide the victim the exploit link, or other content which directs the victim’s browser to perform attacker-controlled actions in the application. Stored CSRF vulnerabilities are more likely to succeed, since the user who receives the exploit content is almost certainly currently authenticated to perform actions.
Stored CSRF attacks also have a more obvious trail, which may lead back to the attacker, since the origin of the malicious HTTP request is hosted in the attacked website. Examples include bulletin boards and social sites where users are allowed to post images with foreign URL sources. These are harder to find and destroy.

 

Advanced uses of CSRF

The following advanced techniques that use CSRF attacks have been observed in recent years.

 

Bypassing CSRF protections with click-jacking

This recently-evolved technique can be used to bypass CSRF protection and submit POST method-based forms with attacker controlled data, using click-jacking. (See the highlight box on click-jacking for more information.) The best example of this attack is exploiting email update services. Such services are quite common in Web applications. In this, the attacker manages to force victims to update their e-mail IDs with that of the attacker, so that the attacker can then compromise the victims’ account by performing a password reset.
This attack can occur even if the Web application contains tokens for CSRF protection.

Click-jacking is an attack involving embedded objects on a maliciously crafted Web page. Using framed content, or that from Flash, Silverlight, or Java, the attacker places a transparent or invisible click button beneath the mouse, so that whenever the user clicks on something they see on the page, the user is also clicking to an unseen website that may contain malicious code. The attack can also take advantage of dynamic HTML and CSS (Cascading Style Sheets) code for further disguise.
The difference between CSRF and click-jacking is that in CSRF, the victim’s browser performs the attack (loading the state-changing URL directly) without the victim clicking to launch it, while in click-jacking, the user actually interacts with something, but the action is “hijacked” by placing a layer between the user and the page element that launches a legitimate action.

 

Safeguarding Against CSRF

Safeguarding your applications against CSRF is a bit more challenging than safeguarding them against XSS attacks, but there are a few guidelines that you can follow.

 

Use POST

Although it doesn't prevent CSRF, you should require POST for any request that performs an action. This also means using $_POST instead of $_REQUEST.

 

Require Verification

Although convenience is a hallmark of good design, if a single request can trigger an important action, the risk of CSRF is increased. For important actions, don't hesitate to ask the user for verification. For extremely sensitive actions, consider requiring the user to provide a password in order to authorize the action.

 

Use an Anti-CSRF Token

The root cause of CSRF is a failure to verify intent. In order to help verify intent, consider adding an anti-CSRF token to your forms. Consider Listing 2 as a substitute for the form used to post to forum.example.org. When a user requests this form, a new token is generated, saved in the user's session, and included in the form as a hidden form variable. Therefore, when a request is received by post.php, not only can $_POST['token'] be compared with $_SESSION['token'], but a timeout can also be applied to further minimize the risk. This tactic practically eliminates CSRF.