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.
.gif)