The US National Security Agency helped put together a list of the 25 most dangerous coding mistakes.

Here they are, in all their glory:

Improper Input Validation

Improper Encoding or Escaping of Output

Failure to Preserve SQL Query Structure

Failure to Preserve Web Page Structure

Failure to Preserve OS Command Structure

Cleartext Transmission of Sensitive Information

Cross-Site Request Forgery

Race Condition

Error Message Information Leak

Failure to Constrain Operations within the Bounds of a Memory Buffer

External Control of Critical State Data

External Control of File Name or Path

Untrusted Search Path

Failure to Control Generation of Code

Download of Code Without Integrity Check

Improper Resource Shutdown or Release

Improper Initialization

Incorrect Calculation

Improper Access Control

Use of a Broken or Risky Cryptographic Algorithm

Hard-Coded Password

Insecure Permission Assignment for Critical Resource

Use of Insufficiently Random Values

Execution with Unnecessary Privileges

Client-Side Enforcement of Server-Side Security

Looking down the list, we can see that a number of the issues have been around for a long time. SQL injection – why are web sites still allowing this, after all the publicity and information disseminated on prevention? Many large organisations are still suffering from these problems, so it isn’t just confined to smaller businesses.

Most of the flaws come into being during implementation (development), such as:

Injection attacks

Improper file access

Some occur during design, such as:

Poor authentication

Broken security 

And some occur during the deployment/testing period, such as excess privilege for web applications. This is usually a result of developers running as administrator on their machines, and finding that the application won’t run any other way when it’s installed onto the production server.

There are also other categroies and flaws in the list, but I'm not going to be exhaustive in covering it. I'm focusing on initiatives to improve the development process.

So where do we start in tackling this? The problem really is a good example of how we must look at security as a process, rather than just trying to find a quick fix.

Concrete solutions that I have been involved in at various organisations have included the following:

Secure coding requirements

Training programs

Penetration testing

Code inspection

Validation frameworks

 One generally has to target both .Net and Java, as large organisations will tend to use both.

Secure coding requirements seem to be continuously written over and over again at one organisation after another. A good basis for Microsoft products is the Building Secure Asp.Net Applications document, and Improving web application security This guidance can be used, with company specific guidance appended. Java documentation gives less of an integration overview, but this is because it will be more implementation specific. However, the Microsoft patterns are quite generic.

Once these documents are written, they will then feed into the development process, and end up being part of the specific non-functional requirements for the application.

Training programs are another essential part of the process. I have worked with a global client recently, creating a training program that was based on the secure coding requirements, and the processes involved in getting security sign-off. This training was computer based, so that all technology-based employees could learn how to integrate security.

Penetration testing may take place, depending on the criticality and vulnerability of the application. For instance, an internet facing application with extremely sensitive data would certainly need a pen test. This will usually reveal discrepancies, which then have to be prioritised and fixed. Let the development team know early on whether this will be necessary, as it will have to be budgeted for.

Code inspection can take many forms. An audit based approach, taking a sample and manually checking, is useful. Also, there are many code checking tools, such as CAT.Net.

From the cat.net code download site:

CAT.NET is a snap-in to the Visual Studio IDE that helps you identify security flaws within a managed code (C#, Visual Basic .NET, J#) application you are developing. It does so by scanning the binary and/or assembly of the application, and tracing the data flow among its statements, methods, and assemblies.

I’m planning to produce an article on this tool soon.

Finally, validation frameworks are becoming more popular. There are lots of types of invalid input, such as

Mistyped entry – simply something which is misspelled or wrongly formatted, such as a date

Broken business rules – Perhaps the email field for your external-facing web site needs more validation than just a regex to check the formatting. What if someone were to enter an internal email address, from within the organisation? This could perhaps be fraudulent.

Request manipulation – querystring manipulation to access the wrong data is common

Validation frameworks are libraries that are geared to checking for all of the above, and more, so that they can be plugged into an application, giving a reliable, tested implementation. They have to be lightweight (so that they don’t take up too much memory, especially in web applications) and efficient (many of the functions will be called repeatedly during a request). Unfortunately, due to the inability of .Net and Java to call each other’s libraries efficiently, two versions would have to be built and maintained.

The OWASP Enterprise Security API (ESAPI) Project is an attempt to produce a strong security framework. The ESAPI is the result of over a decade of code review and penetration testing of critical enterprise applications. At present, only the Java version is available. Efforts to build ESAPI in .NET and PHP are already underway.

Hopefully, this article will give you some clues where to start when introducing an application-level security regime to your organisation.