They've been threatening on the horizon for some time.
First the Open Web Application Security Project (OWASP) Foundation, a not-for-profit charitable organization dedicated to creating free and open tools and documentation related to secure software, established in consultation with Aspect Security, a Secure Software Contract Annex here:
containing the template for a software development contract.
Then in January 2009, computer experts, from more than 30 organizations worldwide, released a consensus list of the 25 most dangerous programming errors leading to breaches of security. The list was championed then by the National Security Agency, and represented the first occasion on which such a broad cross-section of computer professionals reached formal agreement on the most common security-related pitfalls in programming.
In place of the traditional focus on mitigations, this consensus list concentrated on the programming errors that cause such vulnerabilities, offering concrete measures that might be taken by developers to avoid them. A press release at the time suggested that such a list would one day shift the responsibility for secure code development to software companies, by allowing their customers to require signed assurances that products are free of all such well documented error categories.
It Hasn't Happened Yet
That was over a year ago. Now they're at it again! The Register is all Experts reboot list of 25 most dangerous coding errors - Heal thy apps, while Slashdot has picked up on it too.
First the meh news. Quite unaccountably, the full list of 25 errors leading to vulnerabilities and exploits, has remained largely unchanged since last year. The update, driven by the not-for-profit MITRE Corporation, the Sans Institute, the National Security Agency, and the US Department of Homeland Security's National Cyber Security Division, shows XSS (cross-site scripting), SQL injection, and buffer-overflow bugs topping the list of the top 25 vulnerabilities, actually released via production code, and subsequently exploited.
For these are they:
- Failure to Preserve Web Page Structure ('Cross-site Scripting')
- Improper Sanitizing of Special Elements used in an SQL Command ('SQL Injection')
- Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')
- Cross-Site Request Forgery (CSRF)
- Improper Access Control (Authorization)
- Reliance on Untrusted Inputs in a Security Decision
- Improper Limitation of a Path name to a Restricted Directory ('Path Traversal')
- Unrestricted Upload of File with Dangerous Type
- Improper Sanitizing of Special Elements used in an OS Command ('OS Command Injection')
- Missing Encryption of Sensitive Data
- Use of Hard-coded Credentials
- Buffer Access with Incorrect Length Value
- Improper Control of File name for Include/Require Statement in PHP Program ('PHP File Inclusion')
- Improper Validation of Array Index
- Improper Check for Unusual or Exceptional Conditions
- Information Exposure Through an Error Message
- Integer Overflow or Wraparound
- Incorrect Calculation of Buffer Size
- Missing Authentication for Critical Function
- Download of Code Without Integrity Check
- Incorrect Permission Assignment for Critical Resource
- Allocation of Resources Without Limits or Throttling
- URL Redirection to Untrusted Site ('Open Redirect')
- Use of a Broken or Risky Cryptographic Algorithm
- Race Condition
But There's A Push On
Published on Tuesday (Feb 16), the list is headed by an introduction urging software consumers to hold software developers responsible for their products' security. Business customers "have the means to foster safer products, by demanding that vendors follow common-sense safety measures, such as verifying that all team members successfully clear a background investigation, and be trained in secure programming techniques."
"As a customer, you have the power to influence vendors to provide more secure products by letting them know that security is important to you," it states.
And this time, among various other terms and conditions that should be requested by customers, it also includes references to this draft contract,
based upon that groundbreaking OWASP Foundation work.
It was Peiter "Mudge" Zatko, the inventor of the buffer overflow exploit, who in February 2000 in a White House meeting of Internet and software experts, famously told President Clinton, "People write software sloppily. Nobody checks it for mistakes before it gets sold."
Despite many advances in computer security, when seen from an end-to-end perspective, little appears to have changed in those ten years. Perhaps now, with customers being mobilised and empowered by such potentially deal changing initiatives as this one, now might be a good time to stop relying on all those shrink-wrapped legalese disclaimers, advertising to your customers litle more than the fact that your software can be relied upon to do absolutely nothing with any degree of reliability.
Colleague update: Scottish Developers Secretary Barry Carr offers an hour on "Contractual Obligations: Getting Up and Running with Code Contracts" starting at 9:30am this coming Developer Day Scotland, May 8 2010, at Glasgow Caledonian University. Registration opens in literally half an hour, at 12:30 today (March 1). Full agenda here.