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.

The symfony framework has always provided the tools needed by the developers to secure their applications. With the new form framework, we have added an automatic protection against CSRF. Speaking of the form framework, we have also added a lot of security features to protect you against all sort of injections.

He does include an example, though, of a situation where it's not just about protecting from cross-site scripting or attacks. It's about checking user input to ensure it's what it should be. They give the example of a user pushing an "is_admin" value into a form posting where there wasn't one and updating the right column to give them admin rights.

He mentions some work the Rails team has tried to do to prevent this sort of thing automatically, but Fabian points out what the symfony framework already does - prevent any injected fields other than what's in the forms from being submitted and included.

Security in a PHP application includes remote and local security concerns. Discover the habits PHP developers should get into to implement Web applications that have both characteristics.

The habits in their list are:

• Validate input
• Guard your file system
• Guard your database
• Guard your session
• Guard against XSS vulnerabilities
• Guard against invalid posts
• Protect against CSRF

Each comes with their own explanation and for some, code to help you spot the mistakes and correct them.

He will focus on the XSS and CSRF aspects of the web applications: sources of the vulnerabilities, attacks/exploits and the defense techniques. I will sadly not attend but such events are rare enough to be mentioned loudly.

The talk is a part of this meeting and requires a RVSP to attend, so if you'd like to attend, please sign up today.

For the purpose of this tutorial we have listed some commonly known attacks, and how to protect against them. This is crucial for beginners in PHP because PHP tutorials and basic documentation does not accentuate this problem enough. Examples are given that are vulnerable to attacks, and students are either not aware of the vulnerabilities, or are not adequately educated how to protect their scripts.

They topics they look at are SQL injections, XSS attacks, CSRF attacks, and PHP variable insertion. They talk talk about one of the best things you can do to help secure your site and its data - input filtering.

If you've been paying attention at all to the buzz in the PHP community lately, you'll know that articles like this are nothing new. These are the same things other developers are commenting on as well. It is good to see it get more exposure via digg though...

During an audit of phpMyAdmin's protection against CSRF: Cross Site Request Forgeries we discovered that there were multiple ways to bypass the protection.

The failure of phpMyAdmin's CSRF protection obviously means that a potential attacker can use CSRF attacks to trick the browser of a phpMyAdmin user to execute any kind of SQL queries on the victims database server.

The advisory mentions the source of the problem - a random token that is in the user's session that could be exploited to gain unauthorized access to an account. Their recommendation is to update to the latest version of phpMyAdmin (2.9.0.1 as of the time of this post) to help resolve the issue.