

Most Dangerous Programming Errors - petercooper
http://cwe.mitre.org/top25/

======
anuraggoel
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.'''

------
anuraggoel
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."

~~~
tptacek
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.

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

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

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

------
swombat
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.

~~~
stcredzero
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?

~~~
gaika
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.

~~~
tptacek
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?

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

