• Unvalidated Parameters
• Broken Access Control
• Broken Account and Session Management
• Cross-Site Scripting (XSS) Flaws
• Buffer Overflows
• Command Injection Flaws
• Error Handling Problems
• Insecure Use of Cryptography
• Remote Administration Flaws
• Web and Application Server Misconfiguration

Each item on the list has a bit of detail (and sometimes some code) to help point out the problem. Some of them even have references to external sources and packages to help you solve the problems.

In a nutshell, sessions are the way that we "maintain state" from one page to the next, that is, how we identify specific users across multiple page requests. The ability to track users as they go from one page to the next using sessions allows us a number of options, such as tracking where they are going (web statistics) or to verify credentials for a specific section of the site.

First, there's a little mini-intro to sessions for those unsure on their use. It's followed by a look at some session vulnerabilities that could be introduces by malicious users looking to break things on your site (including HTML/Javascript injection, as their example shows).

They recommend a three step plan to get started with the validation of your user's sessions - making it easy for users to log out when they want to, use unique aspects of the remote machine to define the session and to validate all user input, especially things that will be put into a session variable.

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.

An attacker's fondest wish is to be able to run their code on the target system; an RFI exploit does just that. By exploiting two very dubious 'features' of the PHP language, an attacker can inject their code into a PHP program on the server.

Basically, if the potential hacker can manage to get in on a varaible that's inside of an include and use it (in)correctly, they can get the script to jump out and run the code from their server instead of the local copy. Turning off regiter_globals will provide some protection, put poor programming and not performing any input validation can poke holes in the script's security without the need for globals.

Check out the rest of the article for more information on this (potentially) serious issue and check your code/configuration doubly to make sure you're not at risk.

Stephen de Vries sent an email to SecurityFocus's web application security mailing list earlier today to comment on the new Google Code Search: "Google's code search provides an easy way to find obvious software flaws in open source and example applications."

Chris talks about cross-site scripting problems, issues with the superglobals, SQL injection problems, and even a misplaced trust of the $_SERVER superglobal. Each of the items is linked to is search terms on the Code Search to make it easy to locate.

Sometimes it's not very easy to check if a vulnerability occured where Morcilla told you it occured. In order to pinpoint this issue, it is neccessary that you get a deeper look to the callstack of all the functions that were involved calling the SQL abstraction layer.

They include a screenshot of how the functionality will (in the upcoming version) work in the case of a MySQL SQL injection problem.

Multiple input validation vulnerabilities in CJ Tag Board have been reported, which can be exploited by remote users to compromise a vulnerable system.

The issue comes from improperly filtered user input for the "User-Agent" HTTP header and the "banned" parameter for the admin side. This issue effects CJ Tag Board version 3.0. No update or patch has been posted as of yet to correct this issue.

During the development of suhosin, which is our new PHP protection module, several compatibility tests with binary 3rd party PHP extensions like the Zend Platform and the Zend Optimizer have been made. When testing the session protection features of suhosin, we discovered that the session clustering system, which is shipping with the Zend Platform is vulnerable to several different attacks.

They mentions a few things a potential attacker could use this issue for, including crashing the session daemon, remote code execution, and being able to view and write files of their choice (like session files) to execute malicious code.

The details are listed out, but a "proof of concept" isn't published for this exploit. Thankfully, Zend has already provided a patch for the issue which can be downloaded at Zend's website (an upgrade to version 2.2.1a).

In a nutshell, sessions are the way that we "maintain state" from one page to the next, that is, how we identify specific users across multiple page requests.

When the user comes to the site, we need to be able to give them a unique identifier (a session id) that will allow us to know the difference between each user on the site. So, when the user logs in, and then modifies their choices for foo.php, we know whose profile to save those changes to.

The article goes on to talk about what sessions really are, how they're handled on both the client and server side, and a simple code example of how to check the value of them. Thankfully, they also include a section on session vulnerabilities, showing how with something as simple as some Javascript, a session can be maipulated.

To help prevent this, they give some examples of securing your sessions. Then, to illustrate all of the above points, they provide some simple code validate the session information that's been set.

Included in this issue are vulnerabilities for:

• SecurityImages Component Multiple Remote File Include Vulnerabilities
• Ajax Chat Multiple Remote Vulnerabilities
• ATutor Multiple SQL Injection Vulnerabilities
• Coppermine Photo Gallery Theme.PHP Remote File Include Vulnerability
• PHPAuction PHPAds_Path Variable Remote File Include Vulnerability
• myEvent Myevent.PHP Remote File Include Vulnerability

This is just a sampling of the issues reported, so head over to the full listing for the complete information.