2011 CWE/SANS Top 25 Most Dangerous Software Errors

The list can be found here.  The following is my take on what we (meaning society as a whole) should be doing to reduce the risks; remember, I (almost) never care about backwards compatibility so not all of my suggestions are very practical. 🙂

1CWE-89: Improper Neutralization of Special Elements used in an SQL Command (‘SQL Injection’)

Developers need to stick to parametrized queries.  Programming languages and database interfaces should be designed so as to prohibit the construction and execution of ad-hoc query strings.  Programming languages should be developed that mix SQL (or SQL-like) functionality with traditional code, to make parametrized queries (or the equivalent) more natural.

Also, I suspect that putting the back-end code in the database itself (rather than, for example, on a web server) would prove a safer programming model; this can already be done to some extend with SQL stored procedures, but the language is clunky and you’re still using SQL procedure calls as the interface.

2CWE-78: Improper Neutralization of Special Elements used in an OS Command (‘OS Command Injection’)

This is all about software that uses subprocesses to run command-line OS tools, although the same issue applies to the use of third-party software via a subprocess.  This one is easy: developers shouldn’t do that, ever.  Operating systems should ensure that there is always an alternative; future operating systems (if unencumbered by backwards compatibility issues) should eliminate exec and similar functions.  (Instead, a well-defined plugin mechanism should exist to allow software to cooperatively interact.)

3CWE-120: Buffer Copy without Checking Size of Input (‘Classic Buffer Overflow’)

Programming languages should be updated and/or modified to provide for safe pointer arithmetic.  It would be preferable if this was supported by the CPU.  Safe integer arithmetic is also essential.  In the meantime, developers need to do their best to be very very careful when dealing with buffers; the CWE discussion covers this in some detail.

4CWE-79: Improper Neutralization of Input During Web Page Generation (‘Cross-site Scripting’)

HTTP and HTML need to go.  They aren’t even close to adequate for the way we use the web nowadays.  I’d like to see a new protocol, www://mysite.com, with all the obvious changes (and perhaps a few not so obvious ones).  During the (no doubt extended) migration period, sites could be available in both flavors via automated conversion in one form or another.

5CWE-306: Missing Authentication for Critical Function

Not much to say about this one; it mostly boils down to developer common sense.  It could be helpful if future internet protocols (i.e., either a hypothetical replacement for TCP or a replacement for or variant of SSL) came with built-in multiplexing functionality.

6CWE-862: Missing Authorization

Much the same as #5, except that I suspect it is most prevalent in web applications, in which case my comments for #4 apply as well.

7CWE-798: Use of Hard-coded Credentials

I think a mandatory death penalty for programmers who do this is probably the most reasonable approach.  Better programming models for database-backed applications (as per #1) may be of some help.

8CWE-311: Missing Encryption of Sensitive Data

Built-in encryption support in operating systems and perhaps in network protocols.  It needs to be easier for programmers to use encryption, and in particular for them to use it correctly.  Windows has done quite well in this regard, I think.  In particularly sensitive situations, though, nothing beats expert assistance.

9CWE-434: Unrestricted Upload of File with Dangerous Type

The underlying issue is lousy web server design, in particular the use of a general-purpose file system (rather than a dedicated one) for storing web content, including executable content.  This could be improved in combination with #4 or independently.

10CWE-807: Reliance on Untrusted Inputs in a Security Decision

Largely developer carelessness, I suppose.  Better languages could help.  So could banning PHP.  Relates somewhat to #4 in many cases.  (The hypothetical www: protocol would certainly include login sessions as a native concept.)

11CWE-250: Execution with Unnecessary Privileges

Operating systems (and perhaps languages) need to provide better support for reduced-privilege execution.  Future (backwards-compatibility-unencumbered) operating systems should run most applications with very limited privileges as a matter of course.

12CWE-352: Cross-Site Request Forgery (CSRF)

See #4.

13CWE-22: Improper Limitation of a Pathname to a Restricted Directory (‘Path Traversal’)

Again, the underlying problem here is the use of a general-purpose file system for storing potentially malicious data (or data that may be maliciously retrieved).  Either operating system support or good open-source code libraries would be helpful.  In the case where the content is part of the application, development tool support would be helpful.  (That is, development tools should allow programmers to easily incorporate read-only embedded file systems into an application.)

14CWE-494: Download of Code Without Integrity Check

Software shouldn’t usually be downloading code of its own accord. On the rare occasions when it is necessary, the developer needs to take great care.  Better operating system support for the appropriate cryptographic tools might help.

Operating systems should also include built-in mechanisms for third-party software to stay up to date.  This would help significantly with what is probably the most common scenario.

15CWE-863: Incorrect Authorization

I’m guessing this is only really common in web-based applications, so once again, see #4.

16CWE-829: Inclusion of Functionality from Untrusted Control Sphere

Partly developer laziness and/or carelessness, but better development tools could help.  In the case of a web application, see #4.

To expand on this a little: I’m not sure whether CWE/SANS consider DLL hijacking (aka Binary Planting) in this category but it’s certainly analogous; the proper solution to DLL hijacking is to use static libraries (preferably source code!) instead.  I imagine there is a similar option in most other scenarios in which this issue comes up, but better development tools may be necessary.

17CWE-732: Incorrect Permission Assignment for Critical Resource

Operating systems should provide better support for developers when it comes to storing critical resources.  Developers shouldn’t always need to assign permissions explicitly.  Better use of and support for embedded file systems could also help.  Ideally, all applications should contain only a single file (with an embedded file system or the equivalent if necessary) and operating systems and developer tools should assist programmers in this goal.  Data stores such as the Windows registry and application data stores should be automatically divided into segments that are only accessible by the application that created them.

18CWE-676: Use of Potentially Dangerous Function

Better languages and run-time libraries.

19CWE-327: Use of a Broken or Risky Cryptographic Algorithm

As per #8, operating system support can help.  Developer education is essential.

20CWE-131: Incorrect Calculation of Buffer Size

See #3, as this is the just same problem from the other end.

21CWE-307: Improper Restriction of Excessive Authentication Attempts

I don’t have anything more to suggest on this one.  (Shocking, isn’t it?)  Developer education (such as this list!) is the key.

22CWE-601: URL Redirection to Untrusted Site (‘Open Redirect’)

See #4.

23CWE-134: Uncontrolled Format String

Special case of #18, same solution.

24CWE-190: Integer Overflow or Wraparound

Already mentioned in #3, modifying languages (or providing new languages) to support safe integer arithmetic is essential to safe computing, and CPU support would be very helpful.  I’m planning to write more about this later.

25CWE-759: Use of a One-Way Hash without a Salt

Developer education.  Operating system support and good open-source libraries would help.  Since this is probably most prevalent on the web, the hypothetical www: protocol could probably help out as well by mandating authentication methods that don’t actually give the password to the web site in the first place.










3 Responses to “2011 CWE/SANS Top 25 Most Dangerous Software Errors”

  1. Aater Suleman Says:

    Interesting post Harry. #23 always bugs me a lot. It should be easier to fix than some other ones.

    Question: Why is #24 dangerous? Such overflows are detected already so why isn’t it a solved problem?

  2. harryjohnston Says:

    There’s a good example of #24 in action here:


    Now of course the x86 has flags that can be checked to see if an integer overflow has occurred, but I’m not aware of any compiler that actually does so. (I’ve just double-checked both MS Visual C++ and Sun Java, and both silently overflowed 1.5 billion * 2 to -1294967296.)

    It isn’t uncommon for code to depend on this behaviour, either. I’m not sure whether the C/C++ language standards *require* the compiler to silently overflow integer arithmetic, but it would break a fair bit of code if it didn’t. (And of course there would have to be some way to allow an overflow to occur whenever that is the desired behaviour.)

  3. Safe Computing: Integer Arithmetic « Harry Johnston's Blog Says:

    […] Harry Johnston's Blog Just another WordPress.com weblog « 2011 CWE/SANS Top 25 Most Dangerous Software Errors […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: