Defensive Java Programming Notes (06 of 11) Cross-Site Request Forgery (CSRF or XSRF)

  • strict warning: Non-static method view::load() should not be called statically in /hermes/walnaweb12a/b57/moo.greydragoncom/nodsw/sites/all/modules/views/views.module on line 906.
  • strict warning: Declaration of views_handler_argument::init() should be compatible with views_handler::init(&$view, $options) in /hermes/walnaweb12a/b57/moo.greydragoncom/nodsw/sites/all/modules/views/handlers/views_handler_argument.inc on line 744.
  • strict warning: Declaration of views_handler_filter::options_validate() should be compatible with views_handler::options_validate($form, &$form_state) in /hermes/walnaweb12a/b57/moo.greydragoncom/nodsw/sites/all/modules/views/handlers/views_handler_filter.inc on line 607.
  • strict warning: Declaration of views_handler_filter::options_submit() should be compatible with views_handler::options_submit($form, &$form_state) in /hermes/walnaweb12a/b57/moo.greydragoncom/nodsw/sites/all/modules/views/handlers/views_handler_filter.inc on line 607.
  • strict warning: Declaration of views_handler_filter_boolean_operator::value_validate() should be compatible with views_handler_filter::value_validate($form, &$form_state) in /hermes/walnaweb12a/b57/moo.greydragoncom/nodsw/sites/all/modules/views/handlers/views_handler_filter_boolean_operator.inc on line 159.
Leeland's picture

Tricks the victim's browser into performing (undesirable) actions on behalf of the victim. There is no EASY way for the site to tell if a request submitted is valid or a XSRF attack because this attack causes the browser to do exactly what it is supposed to do using those behaviors against the victim. Examples are:

  • Transfer Funds
  • Changing Passwords
  • Purchasing an Item

When a browser makes a request to a site it will use its credentials (cookies) as to authenticate itself in order to retrieve content. So if someone has multiple tabs open and one is, say, to their bank and another is just general browsing then if another site from another tab requests the browser to fetch something like and image from the bank the browser will use its authentication to get it. Even if the URL in the image tag isn't to an image (there is no way for the browser to determine a good image URL from a bad one).

Best way to avoid this attack is if you are connecting to a sensitive site that you must authenticate to (banking, company data, google email, etc.) do not go browsing other sites while that session is open. Make sure you log out and clear the authentication cookie. They target popular sites (Amazon.com, Bank of America, PayPal, Ebay, etc.).

Can be embedded into an image tag which means that things happen without the user even knowing that it happened. For example lets say that someone who banks at the one of the largest banks in the world. This person logs in to the bank. Then remembers something in an online forum that will affect some decision. So this person opens a new tab and goes to the online forum. But in one of the messages being displayed is an image link like this:

<img src="http://bigbank.com/transfer.do?acct=ATTACKER&amount=1000"
width="1" height="1" border="0">

Now the victim's browser will execute:

http://bigbank.com/transfer.do?acct=ATTACKER&amount=1000

It's logged in, the credentials are current, the transfer happens and the victim is not going to even know it happened until a check of the account balance. This is of course amazingly simplified, the real attacks are a little more sophisticated. But, in reality just as easy. All that is needed is a knowledge of the pages and functions of the major online banks and an email message or web page could be embedded with dozens of possibilities all at once.

Other possible ejections of this attack are any means used to embed elements which need to be fetched. Examples:

  • SCRIPT tags
  • FRAME tags
  • IFRAME tags
  • any html tag that allows embedding.

GET requests are especially vulnerable to this attack. POST attacks are NOT immune they are just a little harder to break. If the attacker can write their own web site then all bets are off and surf safely.

The core of this attack is that it uses browser functions AS DESIGNED. This is not due to any bug, it is due to the nature of browsers.

Javascript can also be used to do this attack without showing ANY error messages about bad images. The above attack could be done like this:

<script> var ImageObject = new Image();
ImageObject.src = "http://bigbank.com/transfer.do?acct=ATTACKER&amount=1000";
</script>

In short CSRF attacks work because:

  • Some HTML tags result in automatic HTTP Request execution;
  • Browsers have no way of telling if a resource referenced by an HTML tag is a legitimate resource;
  • Loading of images happen no matter the location of the image data; and
  • Web applications often perform security sensitive operations in response to requests WITHOUT validation of the user.

The way to guard against this attack is to append challenge tokens to each and every request. The challenge tokens need to be cryptographically secure non-sequential IDs and unique generated every time the process is initiated. Sites where the back button doesn't work are generally doing something like this.

Another method for blocking this attack is to design web application services that cross check (or trust to some degree) the HTTP Referrer header. If it isn't what it should be don't perform the action and invalidate the credentials. This is NOT full proof as the HTTP Referrer header can be spoofed.

Thread Slivers eBook at Amazon