Web Application Security Quiz tests your knowledge on the common security principles and quirks related to web application development. There are 15 questions. A correct answer adds one point. An incorrect answer subtracts one point. If you don't know the right answer, you can skip the question (no points are added or subtracted).

It's a pretty good overview of some of the concepts you'd find in most application security policies and includes the answers if you're interested in some of the reasoning behind them.

This is a branch off from a separate discussion on the PHP-FIG mailing list about other ways the Framework Interoperability Group can encourage and foster wider interoperability among its member projects (and by extension, the whole PHP community). I'll start by noting two interesting developments in recent months and one long standing best practice.

The two "interesting developments" he mentions are the relatively recently released SensioLabs Security Checker that uses you Composer file to find security issues and the new entry in the latest version of the OWASP Top 10 list for "Using Components with Known Vulnerabilities". The best practice he talks about is more around the timely/responsible disclosure of vulnerabilities and how some kind of decentralized tracking of these issues that puts the responsibility back on the developers of the tool and not on one tracking resource.

The security of session handling in PHP can easily be enhanced through the use of a few configuration settings and the addition of an SSL certificate. Whilst this topic has been covered numerous times before it still bears mentioning with a large number of PHP sites and servers having not implemented these features.

He talks about the httponly flag when setting the cookie/in the configuration, the "use only cookies" for sessions and forcing them to be "secure only".

In the April issue of the PHPArch magazine (also published on her blog), Elizabeth Tucker Long wrote a really interesting editorial piece coining a concept she called Security-Driven-Development. She (quite correctly) identified a problem in the current development community where security has become an after-thought (if it's thought of at all). This isn't a new concept, in fact it's a concept that I and many others have been preaching for quite a while now. However I've been coming to realize that I've had it wrong the whole time. And I think the entire industry is getting it wrong today.

He talks some about the current state of web application development and how, even with more powerful technologies than ever, we still fall short in security testing. He suggests that the current way of doing things - treating security testing as a "throw it over the wall" or "someone else's job" problem - needs to stop. Security needs to be integrated with development and he suggests that managers and developers of open source projects should take the lead.

When a customer commissions Ibuildings for a new application, he usually has plenty of functional demands. [...] And maybe some thoughts have been given to performance metrics, but security? Well… it "needs to be secure". [...] It is said, conveniently enough mostly by software engineers, that building software is perhaps the most complex activity humans have ever undertaken.

He notes that "security is not a checkbox, it's a dropdown" and should be continuously considered continuously through out development. The OWASP ASVS provides a structure that a development group can follow to test the security of their application. It defines 4 types of testing/validation and fourteen other topics to consider.

While ASVS is a wonderful addition, it has it's issues: verification and reporting can take a significant amount of time and validation rules are not specific enough to use the tools and techniques.

Ruby 2 was just released, and the new 'refinements' feature presents some interesting challenges for JRuby and just about anyone wanting to read Ruby code. Brief chat about the regex security affecting Rails back in January, but more broadly speaking, what does this say about regex in general? Should we embrace it, or find better alternatives? Finally, I've got a new blog post up about web framework security - why do (almost) no web frameworks ship with security baked-in?

The podcast references some of the thoughts from his recent post about framework security. You can listen to this latest episode either through the in-page player or by downloading the mp3.

I want to provide a simple and efficient way to check for vulnerabilities in a project and I want to serve more than just the Symfony community. That's why I'm really proud to announce a new SensioLabs initiative: a simple way to check if your project depends on third-party libraries with known security issues. The website explains how it works in details (https://security.sensiolabs.org/), but basically, this initiative gives you several ways to check for security issues in your project dependencies based on the information contained in you composer.lock file (you are using Composer to manage your dependencies, right?)

Composer users can upload their "composer.lock" file and the system will evaluate it against the vulnerabilities it knows about and return any issues it might find. The current database is hosted on github and can be added to by anyone using a pull request. Additionally, you can install the command-line version if you want to do checks locally.

Code execution vulnerabilities are, by definition, hideous monsters. The ability for external inputs to enter an execution context (i.e. injecting or manipulating code that is executed on the server) can be difficult to spot through the haze of convenience that such machinations are often designed to deliver. In Rail's case, that convenience was to automatically cast data entries in XML or YAML inputs into Ruby types including, unfortunately, Symbols and Objects.

These types of "buried" code execution vulnerabilities are still easy to locate in PHP, at least, because you are still restricted to normal code execution pathways in the absence of Ruby's dark magic, e.g. eval(), include(), require_once(), system() and, let's not forget, unserialize().

He talks about how, if you're not careful with the code (third party libraries) that you use in your applications - or don't adhere to good security practices in your own - you could be vulnerable to a similar style of attack. After some investigation on his part, he discovered an issue related to this in the Symfony2 YAML parser (now fixed with a new release).

To summarise… Pay attention to competing applications or frameworks - their problems may also be your problems. If you're worried about arbitrary code execution vulnerabilities then audit your code. You can even, as a sanity check, use grep to find uses of functions like eval(), unserialize(), etc and analyse where their parameters' might originate from.

Validation and sanitization are extremely important topics, any developer should be aware of. Especially with powerful, modern frameworks, people seem to forget about the underlying concepts and wrongly assume it's already solved somehow. Correctly used and early on integrated, both play the central role in defending against attacks on your application.

He talks a bit about why you should care about the topic, some of the common issues/threats that could come up because of it and some general information on what validation and sanitization are. He looks at implementation with the filter extension and touches on functionality from Symfony 2, Laravel 3, CakePHP 2 and shares his own data filtering module with examples of its use.

What seems to be so obvious for road traffic and its rules seems to be less obvious for many web developers. They tend to slack on defining (and monitoring) what is happening at the application level as well as the infrastructure level of their application. It is not enough to run a default install of your operating system of choice, add whatever services you need, and hope for the best. Considering the amount of money as well as damage to reputation, either directly due to fraud and abuse or indirectly by time lost to recover a hacked system or software, the "let's hope for the best" approach is of arguable quality. And we are not even considering general bugs here.

He mentions configuring the server, OS and network to ensure a higher level of security, noting that no matter how much work is put into secure code, if the attacker can get to points on the system they shouldn't, your app is still vulnerable.

But how can you tell if someone is actually trying to break in? Pretty much exactly as the police does for road traffic: with speed checks and by patrolling. A properly configured firewall will show as well as inhibit any unauthorized communication within the network and all you need to do is monitor the vital signs of your infrastructure.