LD SoftwareBespoke Software, Web Design, Security Consultants and Host Services.


You have been warned!
We have caught 5852 shameful hackers.


Paypal Referral
Sign up for PayPal and start accepting credit card payments instantly.

Link Exchange
Join our free link exchange

Click Here
Cross-site request forgery

Web Design & Development Guide

Cross-site request forgery

Home | Up

Cross-site request forgery, also known as one click attack or session riding and abbreviated as CSRF (Sea-Surf) or XSRF, is a kind of malicious exploit of websites. Although this type of attack has similarities to cross-site scripting (XSS), cross-site scripting requires the attacker to inject unauthorized code into a website, while cross-site request forgery merely transmits unauthorized commands from a user the website trusts.

Example and characteristics

The attack works by including a link or script in a page that accesses a site to which the user is known to have authenticated. For example, one user, Bob, might be browsing a chat forum where another user, Alice, has posted a message with an image that links to Bob's bank. Suppose that, as the URL for the image tag, Alice has crafted a URL that submits a withdrawal form on Bob's bank's website. If Bob's bank keeps his authentication information in a cookie, and if the cookie hasn't expired, then Bob's browser's attempt to load the image will submit the withdrawal form with his cookie, thus authorizing a transaction without Bob's approval.

A cross-site request forgery is a confused deputy attack against a Web browser. The deputy in the bank example is Bob's Web browser which is confused into misusing Bob's authority at Alice's direction.

The following characteristics are common to CSRF:

  • 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

At risk are web applications that perform actions based on input from trusted and authenticated users without requiring the user to authorize the specific action. A user that is authenticated by a cookie saved in his web browser could unknowingly send an HTTP request to a site that trusts him and thereby cause an unwanted action.

CSRF attacks using images are often made from Internet forums, where users are allowed to post images but not JavaScript.

Here is an example of an attack on Digg. Here is another example of an attack on Amazon.com, and one on Google's Adsense.


For the web site, switching from a persistent authentication method (e.g. a cookie or HTTP authentication) to a transient authentication method (e.g. a hidden field provided on every form) will help prevent these attacks. A similar approach is to include a secret, user-specific token in forms that is verified in addition to the cookie.

An alternate method is to "double submit" cookies. This method only works with Ajax based requests, but it can be applied as a global fix without needing to alter a large number of forms. If an authentication cookie is read using JavaScript before the post is made, the stricter (and more correct) cross-domain rules will be applied. If the server requires requests to contain the value of the authentication cookie in the body of POST requests or the URL of GET requests, then the request must have come from a trusted domain, since other domains are unable to read cookies from the trusting domain. On the other hand, this method forces users to enable JavaScript, negating the only way a user has to prevent most Cross-site scripting vulnerabilities from being exploited.

Contrary to popular belief, using POST instead of GET does not offer sufficient protection. JavaScript can be used to forge POST requests with ease. Nonetheless, requests that cause side effects should always use POST.[1] Also, POST does not leave a trail of variable data in webserver and proxy server logs, while GET does leave such a trail. It is still clearly best to use POST when coding in a defense-in-depth approach.

Another approach is to check the HTTP Referer header to see if the request is coming from an authorized page. Unfortunately, this technique may not work reliably, since browsers sometimes omit the Referer header because of a user's privacy settings or because the Referer is a secure https page.

Although cross-site request forgery defenses typically require modifying the web application, individual users can help protect their accounts at poorly designed sites by logging off the site before visiting another, or clearing their browser's cookies at the end of each browser session.[2]


This attack relies on a few assumptions:

  • The attacker has knowledge of sites the victim has current authentication on (more common on web forums, where this attack is most common)
  • The attacker's "target site" has persistent authentication cookies, or the victim has a current session cookie
  • The "target site" doesn't have secondary authentication for actions

While having potential for harm, the effect is mitigated by the attackers need to "know his audience" such that he attacks a small familiar community of victims, or a more common "target site" has poorly implemented authentication systems (for instance, if a common book reseller offers 'instant' purchases without re-authentication).


  1. ^ RFC 2616 9.1.1
  2. ^ Dark Reading, CSRF Vulnerability: A Sleeping Giant, accessed 2006-10-18

Home | Up | Browser exploit | Cross-site cooking | Cross-site request forgery | Cross-site scripting | Cross-zone scripting | Directory traversal | Evil twin (wireless networks) | HTTP response splitting | IDN homograph attack | Referer spoofing | Session fixation | Session poisoning | Website spoofing

Web Design & Development Guide, made by MultiMedia | Websites for sale

This guide is licensed under the GNU Free Documentation License. It uses material from the Wikipedia.


Text Ads
There isn't content right now for this block.

Community Login


People Online:
Visitors: 179
Members: 1
Total: 180

Online Now:
01 : Monty

Like my code
Then please make a donation.

Which help me produce more free code.

Paypal Verified


Powered by PHP-Nuke

Valid CSS!

Valid Robots.txt

Bad Behavior

[Valid RSS]

[Valid RSS]
You can syndicate our News with backend.php And our Forums with rss.php
You can also access our feeds via Feedburner Site News and LD Software Forums
© 2009 ld-software.co.uk All Rights Reserved.
PHP-Nuke Copyright © 2005 by Francisco Burzi. This is free software, and you may redistribute it under the GPL. PHP-Nuke comes with absolutely no warranty, for details, see the license.
Page Generation: 0.43 Seconds