Ask the Expert

SANS Top 25 programming errors: Application security best practices

The SANS Institute released the newest version of its Top 25 Most Dangerous Programming Errors list in February. What are some of the key takeaways from that list for application security professionals?

    Requires Free Membership to View

The CWE/SANS Top 25 Most Dangerous Programming Errors list is published every year. This and the OWASP Top 10 Most Critical Web Application Security Risks should be compulsory reading for anyone involved in developing computer software. They provide a great application security best practices checklist of key areas in an application that need particular attention. Project managers and developers need to ensure their code doesn't include any of the errors, while code reviewers should pay particular attention to the vulnerabilities listed.

Sadly, the SANS Top 25 shows us that application developers are still struggling to learn from past mistakes. The errors in the Top 25 are split into three programming error categories: insecure interaction between components (8 errors), risky resource management (10 errors) and porous defenses (7 errors).

Risky resource management errors highlight poor programming and a lack of security awareness among developers. I know most developers tend not to have security high on their priority list, concentrating instead on "features and functions," but to still be introducing buffer-overflow and path-traversal vulnerabilities into applications in 2010 shows that people new to the industry are not being taught how to code correctly, let alone with security in mind. While well-known vulnerabilities are still being coded into applications, systems and users will continue to suffer from attacks.

Porous application security defenses is a reflection of poor project management or underfunded projects. I can't think of any other reason why "missing encryption of sensitive data" would appear on the list. "Missing authentication of critical function" again shows that many developers do not have a grasp of how applications that run in the hostile environment of the Internet need to be built. Developers need to appreciate that they can't rely on a firewall and IDS for an application's security; they are also responsible.

Developers often don't realize the security implications of particular features and functions that they wish to incorporate into their applications. Threat modeling is a good way to resolve this problem of security versus usability. It not only raises security awareness among developers, but it also makes application security an integral part of the application design and development processes. It is a great way to help bridge the knowledge gap between security and development professionals.

Finally, I think the errors in the first category, insecure interactions between components, are often a direct result of many development teams being so big, and the different components that make up an application being written by different developers, often with little dialogue between them until the application is built and deployed. To reduce the occurrence of this type of error, it's vital that all code is well documented. This should include a description of what the code does, why and how, and what assumptions are made when the code is called.

Many flaws can be eliminated from an application by validating these assumptions and testing that they can't be violated. It's also important to list all other code that references a particular component. This cross-referencing helps ensure changes to the component won't break assumptions and logic elsewhere and makes it easier for a reviewer to see or understand where flow or business controls could be circumvented. To ensure this documentation and validation is carried out, I would mandate it as part of the design and build requirements. If every project manager ensures that their application has been checked for these 25 errors, we will be a lot further down the road toward enforcing good coding practices and reducing the number of easy attack vectors for hackers.

This was first published in March 2010

There are Comments. Add yours.

 
TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to: