Top 25 Most Dangerous Programming Errors

Security has always been an issue in software development; mainly due to ignorance, laziness and a nonchalant attitude of programmers (I’m one of the guilty ones). ‘Security’ is the one section in a project scope that gets consistently ignored by not only the developers but also management. In defense of myself and other programmers I would have to say that writing secure software is hard work, and with all the pressure from management and clients to get the software delivered, its no wonder that programmers turn a blind eye towards security. But that is surely not an excuse to deliver a product full of security vulnerabilities.

CWE/SANS recently released a updated version of their Top 25 Most Dangerous Programming Errors list. The document lists the most common and significant programming errors which can lead to serious software vulnerabilities. The result of collaboration between the SANS Institute, MITRE, and other top software security experts in the US and Europe, the document can help you narrow down your security fixes to a important few.

According to the Mitre site:

The main goal for the Top 25 list is to stop vulnerabilities at the source by educating programmers on how to eliminate all-too-common mistakes before software is even shipped. The list will be a tool for education and awareness that will help programmers to prevent the kinds of vulnerabilities that plague the software industry. Software consumers could use the same list to help them to ask for more secure software. Finally, software managers and CIOs can use the Top 25 list as a measuring stick of progress in their efforts to secure their software.

The 25 vulnerabilities are divided into three main categories: Insecure Interaction Between Components, Risky Resource Management and Porous Defenses, details of which are listed below.

Insecure Interaction Between Components

These weaknesses are related to insecure ways in which data is sent and received between separate components, modules, programs, processes, threads, or systems.

* Improper Input Validation
* Improper Encoding or Escaping of Output
* Failure to Preserve SQL Query Structure (‘SQL Injection’)
* Failure to Preserve Web Page Structure (‘Cross-site Scripting’)
* Improper Sanitization of Special Elements used in an OS Command (‘OS Command Injection’)
* Cleartext Transmission of Sensitive Information
* Cross-Site Request Forgery (CSRF)
* Race Condition
* Error Message Information Leak

Risky Resource Management

The weaknesses in this category are related to ways in which software does not properly manage the creation, usage, transfer, or destruction of important system resources.

* 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 (‘Code Injection’)
* Download of Code Without Integrity Check
* Improper Resource Shutdown or Release
* Improper Initialization
* Incorrect Calculation

Porous Defenses

The weaknesses in this category are related to defensive techniques that are often misused, abused, or just plain ignored.

* Improper Access Control (Authorization)
* Use of a Broken or Risky Cryptographic Algorithm
* Hard-Coded Password
* Incorrect Permission Assignment for Critical Resource
* Use of Insufficiently Random Values
* Execution with Unnecessary Privileges
* Client-Side Enforcement of Server-Side Security

The SANS Institute proclaims that the document will have four major impacts on the industry.

* Software buyers will be able to buy much safer software.
* Programmers will have tools that consistently measure the security of the software they are writing.
* Colleges will be able to teach secure coding more confidently.
* Employers will be able to ensure they have programmers who can write more secure code.

However, it remains to be seen how fast the changes really occurs.

In practice

So as a PHP programmer what can you do to bring security into your development process.
The first is to acknowledge that the problem exists.
Second, convince management that spending time on security will be profitable to the company in the long term and will keep them from being sued by clients if a security breach occurs.
Third, get some good books on secure programming. I would personally recommend:
1. Pro PHP Security: by Chris Snyder, Michael Southwell
2. Essential PHP Security: by Chris Shiflett
3. php|architect’s Guide to PHP Security: by Ilia Alshanetsky
4. Web Security Testing Cookbook: Paco Hope, Ben Walther
5. Security Engineering: Ross J. Anderson