The common weakness enumeration is an amazing document. Imagine if there was such a document for architecture/construction. That document would contain admonitions like – “remember to put in structural supports for upper floors” and “don’t lay floors on dirt” or “make sure there are no free unterminated wires left hanging out of walls.”  Here is the first entry in the CWE

The software, when constructing file or directory names from input, does not properly sanitize absolute path sequences such as “/path/here.”

Here’s another one

Without proper access control, executing a SQL statement that contains a user-controlled primary key can allow an attacker to view unauthorized records.

Ok. And you thought I was exaggerating. Just a few down we see:

The accidental addition of a data-structure sentinel can cause serious programming logic problems.

This means something like “don’t put an end of record marker in the middle of a record and don’t put a 0 in the middle of a C string.”

The next one comes with a great example.

An algorithm in a product has an inefficient worst-case computational complexity that may be detrimental to system performance and can be triggered by an attacker, typically using crafted manipulations that ensure that the worst case is being reached.

The example is here. It’s an example of a security feature that can be misused.

And here is a weakness that appears in many guises

The software fails to adequately filter user-controlled input for alternate script syntax.

The example is here.

Here we are in 2008, and, in desperation, organizations are being asked to certify that their software is developed in such a way that user commands are not passed directly to data base engines that do not check permissions!

Common Weakness Enumeration

2 thoughts on “Common Weakness Enumeration

  • May 26, 2008 at 1:40 pm
    Permalink

    Writing software is hard. As a person who breaks software for a living, it is pretty surprising when I find a product that does not have some critical flaw. The game is largely in my favor, however. The software developer has to fix every flaw where I only have to find one. Fixing the problem typically depends on developer education, or getting people to write better code, which is fundamentally flawed. People make mistakes. Mistakes result in security flaws. People are not going to get any better.

  • Pingback:keeping simple » More on common weakness

Comments are closed.