I wonder why the discussion section for each topic tries so hard to be funny:

"Buffer overflows are Mother Nature's little reminder of that law of physics that says: if you try to put more stuff into a container than it can hold, you're going to make a mess."

"Just as you should start your day with a healthy breakfast, proper initialization helps to ensure that your software will run without fainting in the middle of an important event."

'''Spider Man, the well-known comic superhero, lives by the motto "With great power comes great responsibility." Your software may need special privileges to perform certain operations, but wielding those privileges longer than necessary can be extremely risky.'''

This is a great list which any programmer should be familiar with if they are not already.

While the effort is well meant, I find it hard to respect a list that advocates the following (in section CWE-665: Improper Initialization):

"Requirements: Use a language that forces the programmer to explicitly initialize all variables before use."

Why? Uninitialized variable attacks are a fairly recent finding. If you're a C/C++ coder, that's not at all a meaningless suggestion.

Leave an integer on the stack uninitialized:

    int offset;

Have a conditional that usually determines its value:

    if(something) offset = packet[0];

Later, use it as an index:

    buffer[offset] = data;

The "offset" variable, when uninitialized, takes its value from whatever was left on the stack. Attackers very often control that value (for instance, any time you memcpy or strncpy something out of a packet into a fixed-size buffer to parse it, you're also splashing attacker-controlled data over the stack).

You're picking on one of the few cases where the CWE 25 is actually topical.

This is indeed a valid security issue. I am picking on the simplistic recommendation ("use a language that forces explicit initialization")

And you're right. More often than not you as a coder don't have a choice in what language to use.

Hard to believe the list is from 2009...

It's definitely from the 'Web 2.0' era:

"...because many paradigms carry data and commands bundled together in the same stream, with only a few special characters enforcing the boundaries. An example is Web 2.0 and other frameworks that work by blurring these lines."

Because Web 1.0 did not carry data and commands bundled together in the same stream?

Yeah, and I'm not sure what the alternative is. Why is "a few special characters" more of a problem than anything else? Is active FTP, maybe the best example of commands and data on completely different channels, all that secure, especially considering the ability to trick the server into connecting someplace else?

This list is correct but mostly obsolete and heavily dependent on your technologies of choice (and how well you use them).

For example, half of the first bunch (Insecure Interaction) are automatically covered for if you use (properly) a framework like Rails. The resource management bunch is also pretty much irrelevant if you're using a dynamic language like ruby.

The last bunch is the most relevant today, but those are hardly "programming errors". They are security design shortcomings... i.e. things that a security-minded application architect will be aware of, but that you need to think long before you write any code.

Most of "Insecure Interactions" is still a serious issue with Rails. It's very easy to wind up with XSS, SQL Injection, and XSRF in Rails apps; to avoid them, you not only have to be using Rails, but using Rails right.

The simple cases for all of these are automatically eliminated with Rails; for instance, searching for "O'Malley" in a search box isn't going to trigger SQLi. But somewhere in any large-ish application, someone is going to do a custom join or a complicated conditional, and that brings SQL input validation along to the party.

Same deal with XSS. Rails gets rid of XSS, if you (a) default to h() style filtering and never override it, or (b) rigorously audit your code. But most large applications have code paths where something other than Erb is generating HTML (for instance, some library may use HAML to generate a report), and those code paths often escape output filtering.

I'm not trying to stick up for the CWE 25; I think most of these lists are pretty silly. What they're really intended to do is to help enterprise programmers feel like they have their minds wrapped around the software security problem, so that they have a place to start. Other lists, particularly the (equally outmoded) OWASP Top 10, have succeeded spectacularly at that.

Could one use this list to evaluate an implementation stack? Maybe someone should evaluate LAMP, Ruby on Rails, and Django with regards to this list?

Rails: problem - who takes care of it - how

1) Input validation - programmer - validates_* and attr_accessible in the models

2) Output validation - programmer - HTML::Sanitize

3) SQL injection - rails - use ? or named_scope to construct complex queries

4) XSS - programmer - do not forget <%= h

5) Command injection - programmer - do not do it

6) Cleartext - programmer - requires_ssl module

7) CSRF - rails - uses authentication_token in all forms

8) Race conditions - rails - single threaded

9) Error info leaks - rails - use production mode

10) Memory - ruby - safe language

The rest are all on programmer - just do not do it.

First, this is like saying C takes care of buffer overflows:

1) buffer overflow - programmer - count

Conservatively, that action item cost the industry over 5 billion dollars. So, generally, "bad programming: use good programming" is not an effective answer to security.

Second:

(3) Fails on complex queries and query builders all the time; there are situations where you can't parameterize everthing that varies in a query.

(5) Would have precluded Github, which used `` expansion in its first revs to invoke git.

(8) First, Rails isn't single-threaded anymore, and second, you can end up with race conditions at the database layer if you aren't careful with transactions and isolation levels.

(9) Is only true if you not using any unaudited C extensions; quick, tell me how many of the gems you brought in have an ext/ directory with code in it?

3) Have you tried named_scope? It solves most of the query building pain for me...

I knew it!

There had to be a way to spin #8 into something positive.

spin is charged in this context