Tutorial : Cross-Site Request Forgery (CSRF)

Cross-site request forgery, also known as a one-click attack or session riding and abbreviated as CSRF (sometimes pronounced sea-surf) or XSRF, is a type of malicious exploit of awebsite whereby unauthorized commands are transmitted from a user that the website trusts. Unlike cross-site scripting (XSS), which exploits the trust a user has for a particular site, CSRF exploits the trust that a site has in a user's browser.
                --by Wikipedia..
This way an attacker can access functionality in a target web application via the victim's already authenticated browser. Targets include web applications like social media, in browser email clients, online banking, and web interfaces for network devices.

Key Concepts of Cross-Site Request Forgery

• Malicious requests are sent from a site that a user visits to another site that the attacker believes the victim is validated against.
• The malicious requests are routed to the target site via the victim’s browser, which is authenticated against the target site.
• The vulnerability lies in the affected web application, not the victim’s browser or the site hosting the CSRF.

Example Attack Scenarios

The application allows a user to submit a state changing request that does not include anything secret. For example:

http://example.com/app/transferFunds?amount=1500&destinationAccount=4673243243

So, the attacker constructs a request that will transfer money from the victim’s account to the attacker’s account, and then embeds this attack in an image request or iframe stored on various sites under the attacker’s control:

<img src="http://example.com/app/transferFunds?amount=1500&destinationAccount=attackersAcct#" width="0" height="0" />

If the victim visits any of the attacker’s sites while already authenticated to example.com, these forged requests will automatically include the user’s session info, authorizing the attacker’s request.

How Do I Prevent 'Cross-Site Request Forgery (CSRF)'

• Preventing CSRF usually requires the inclusion of an unpredictable token in each HTTP request. Such tokens should, at a minimum, be unique per user session.
• The preferred option is to include the unique token in a hidden field. This causes the value to be sent in the body of the HTTP request, avoiding its inclusion in the URL, which is more prone to exposure.
• The unique token can also be included in the URL itself, or a URL parameter. However, such placement runs a greater risk that the URL will be exposed to an attacker, thus compromising the secret token.
  Requiring the user to reauthenticate, or prove they are a user (e.g., via a CAPTCHA) can also protect against CSRF.