There's been a bit of noise in the past week about the proper way to prevent Cross-Site-Request-Forgery (CSRF) attacks. It seemed to have started with this post. There's been discussion in the comments, and on Twitter about it, and there seems to be several opposing viewpoints on the matter. I want to start off by saying that I agree completely with the post in question. But I figured I'd write a post to explain WHY I agree with it.

He starts with an overview of a few of the common types of request forgery including from a javascript injection, a Man-in-the-Middle attack and a replay attack. He then breaks up the "lines of defense" part of the post into three different sections - adding a hidden token field to forms, changing the token for each request and using random numbers when regenrating them.

In researching the second edition for the IBM i Programmer's Guide to PHP Jeff and I decided to include a chapter on security since we really didn't talk much about it in the first edition. I'm talking about cross site request forgeries right now and I wanted to make sure that what I was going to suggest would not break the internet in some way. I did some Google searching to see what other people were recommending.

Most of the examples he saw used md5, uniqid and rand to create a randomized hash. He suggests an alternative - a method using the hash_hmac and openssl_random_pseudo_bytes methods to generate a sha256 hash for use in your page's submissions.

When it comes to application security, in addition to securing your hardware and platform, you also need to write your code securely. This article will explain how to keep your application secure and less vulnerable to hacking.

The good practices they recommend include input data validation, protecting against XSS attacks, preventing SQL injections, protecting session data, proper error handling and protecting included files. There's some good reminders here, but it barely scratches the surface of effectively protecting your application. These tips are the "low hanging fruit" for securing your app, so be aware that there's more things to worry about than just these eight.

Be aware of the most common security threats to PHP applications is the important step to secure your PHP scripts may not be immune. Here, the article is going to go over top 6 common security threads in PHP scripts. You may familiar with this, if not, this is a good time for you to read and keep in mind.

The top six on his list are:

• SQL Injection
• Cross-Site Scripting (XSS)
• Session fixation
• Session capturing/hijacking
• Cross-Site Request Forgeries (CSRF)
• Code Injection

For each item, he includes a bit of explanation as to what the issue is and a common solution as to how to prevent it.

When talking with @jmikola on #Symfony-dev this afternoon we got into the subject of cross site request forgery and symfony2 login forms. And it seems that form-login already supports this but neither of us knew how it worked. So here is another quick tip. This time about securing you login form from cross site attacks.

The key is to define a "csrf_provider" in your security.yml config file and point it to the "form.csrf_provider" provider. He also includes the controller and view code/templating you'll need to get the token included in the form (and validated).

Cross-site request forgery (CSRF) is a common and serious exploit where a user is tricked into performing an action he didn't explicitly intend to do. This can happen when, for example, the user is logged in to one of his favorite websites and proceeds to click a seemingly harmless link. In the background, his profile information is silently updated with an attacker's e-mail address. [...] Any action that a user is allowed to perform while logged in to a website, an attacker can perform on his/her behalf, whether it's updating a profile, adding items to a shopping cart, posting messages on a forum, or practically anything else.

He shows it to you "in action" with a PHP script for a basic login page that takes a username and password, does some filtering and sets the username to the session. Their "harmless.html" file offers a link to the site's "process" page with a logout action that would allow the "harmless" file access to the current session if clicked. To prevent this from happening, they suggest a unique token be included in interactions on your site. This key is checked against a token in the current session (or other location) and is only valid if they match.

The Symfony framework has included this as a part of their forms for a while now and includes automatic handling to check its validity. Solutions also exist for other frameworks like Zend Framework and many others.

CSRF (Cross-Site-Request-Forgery) attacks work by sending arbitary (form) requests from a victim. Normally, the receiving site (in our case the Controller who processes the form data) doesn't know where the data comes from. The CSRF protection in Lithium aims to solve this problem in an elegant and secure way. You can read more about those attacks here. Note that you'll need to clone the latest master branch of Lithium if you want to try it out now.

There's two parts to the protection, one on either side of things - a field in the form output and a check in the controller to see if the submitted value is correct. He includes code for a simple form (a title field and submit button) that lazy loads the Security helper and generates the token for you. He walks through the controller side of things a line at a time and includes a sample logging/forwarding bit in the second example to redirect users when the CSRF check doesn't pass.

In today's tutorial, we will learn how to painlessly protect your CodeIgniter (pre 2.0) application against Cross-Site Request Forgery attacks. The library we'll be creating today will automate all of the protection mechanisms, making your site stronger and more secure.

They've broken it up into a few different sections to dole it out in easy to follow chunks:

• Understanding the Attack Vector
• Planning
• Token Generation
• Token Validation
• Inject Tokens into the Views
• Hooks

You can also download the full source of the library.

So, cross site request forgeries are a pretty common topic these days; they're in almost every security talk, book, site etc. This is okay; they're important [...] Most of the sites, and all of the books I've read demonstrate things correctly, but when it comes to actual implementation, time and time again, I see code that's just wrong.

He looks at two of the "essentials" when it comes to protecting you and your application - comparison (not taking other values of variables into account) and the unpredictable token (not making tokens, like md5 hashes of information, random enough).

CSRF, or Cross-Site Request Forgery, is a vulnerability very common in websites. [...] This can be dangerous, especially if your admin interface is compromised: There may be a button on the other site which goes to your admin interface and deletes the latest blogpost for example - and you wouldn't want that!

His method is a three-step process for protection - use POST, protect against cross-site scripting and use a CSRF key in the form to help prevent abuse. A simple script is included to show it working and is adapted to work in a controller plugin for the Zend Framework.