Common Weakness Enumeration

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!