This is an exploration of two approaches to input validation, black-listing and white-listing. It follows on from my now ancient first post
Validation -- Crunchy on the Outside

What is input anyway?

We can hardly discuss input validation techniques without understanding what input is, so here goes. At its most basic, input is a fluctuating electrical signal…. Hang on, our attackers don't control that, we write software.

Introduction

This post is a summary of a presentation I recently gave at one of the local OWASP meetings. As a web application penetration tester, I frequently encounter applications that have rolled their own password recovery mechanism or poorly implemented an existing solution. The impact of vulnerabilities in these mechanisms varies from information disclosure through to compromise of the entire application – so it is certainly a topic that warrants discussion.

We’ll cover a few of the more common issues in this post, as well as some suggestions for avoiding them.

I'm a software developer. Sure, I'm involved with security, and I spend more time on processes than code these days, but what I care about most is making software. For me, security is fundamental, because if someone pwns my code it's my mistake and my pride is on the line. And of course it's fun, I love the ingenuity of the attacks and the challenge of defending against them.

If you are a software developer you have probably attempted to at write at least one web based application at some point or other. The growth of the Internet, combined with the move towards high availability, platform agnostic tools means that the web has become the de-facto place to develop tools,per connect with an audience and to share information.

I am a firm believer that it doesn’t matter what language you decide to write your web applications in. As long as it meets your objectives and can be maintained and understood without sacrificing poultry to an un-named god (here’s looking at you Perl developers) it’s all good.

The security industry can be a cynical bunch at best. If you were to ask most of them what “secure software” was, they would probably laugh and say there was no such thing. To an extent they are right.

Like most of the defensive security professions, secure software development isn’t about creating the software equivalent of Fort Knox. It’s about integrating security considerations and design patterns into the software development lifecycle.

Not sure what this means... let’s look at an analogy...