Give the Developers a Good Start

In a previous post about positive security models I talked about defining exactly what interactions and data flows are allowed in your web application. However, it's often left up to the development team to choose what they think is correct, and they then get the blame when things go wrong. Don't let this happen!

I also touched a little on this topic in Free Text Form Field Data Validation and Know Your Form Data, but it's very common to come across cases where no-one has thought about the requirements enough.

As an example, I was recently looking at audit requirements. The Audit Commission runs the National Fraud Initiative (NFI) which provides a means of data sharing to detect fraud across audited government bodies and best value authorities in England. There is a Code of Data Matching Practice and they have produced a number of data specifications for the Data File Upload (DFU) facility. So, have the data types, ranges/lengths, character sets, formats, syntax, cardinality and everything else pertinent been defined?

No.

Looking at one of the more "elaborate" specifications, for payroll:

The data fields are defined as "numeric", "date" or "character" and the majority have no further definition. Does "character" mean "anything"? So we don't know how long a surname could be, what format is to be used for the date of birth, or what is expected in the "leaver indicator" field. I know how hard it can be to discover data specifications, especially if there are multiple proprietary systems, but how do we expect developers to build secure applications if we don't give them the correct information? If we don't know exactly what's allowed in the data, how do we validate it, how do we know what to send and how do we know whether we are allowed to send it?

This type of thing can mean developers not bothering with data validation at all and testers being unable to create test cases. That can lead to invalid characters, formats or even programming code being accepted as valid input which should otherwise be rejected.