More on common weakness

Dan Quist writes in to point at that writing software is hard and we should expect errors. No doubt. Perfect software is not on the near horizon and good programmers using good tools will make stupid mistakes.

But the CWE compendium points to systemic problems in the field. Look at the problem of allowing unfiltered user input to go to a database engine that then executes unsafe commands.

  1. Not checking entered data is unacceptable programming practice.
  2. The programming language libraries that offer SQL commands have no reason to pass complex commands. Instead of “do database whatever this string says”, there should be a highly efficient “do a select on this field in this database table”.
  3. The databases should at least support some permission system so that databases are opened with read permissions only if no writes are expected or read+InsertRecord or read+ReplaceRecord.

These types of errors are to be expected in software created by unqualified programmers using badly designed software.

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!