Top 25 coding defects listed, surprising nobody with a clue

TalkBack 1 of 7:: Next »

Thread View
Flat View

A list . . .: Humm, it did a little digging to find the actual list, but I think this is it:

http://cwe.mitre.org/top25/#CWE-20

So, a list and some advice:

The first broad category is interaction between components. Basically, it means you forgot to filter stuff entering and leaving your software.

-The first items are generally "insecure interaction between components." There are some ways to alleviate this:

--Test driven development, clear interfaces, and even use a language that supports contracts such as Spec #.

--Anywhere where an application interfaces with anything from the outside world should be clearly and minimally defined and thoroughly tested. Both humans and other software are not to be trusted to always give valid data.

--I hate to say this, but use large meta languages such as XML as little as possible. 99% of the time the problems arise from working with structures that, although nicely generalized and easily extended, are too large to secure.
---This is one of the great failings of the Internet: It's become too large for its own good. Too many languages, too many unmatched interfaces, too much translation. Too many ways for developers to make mistakes.
---In addition, be *VERY* clear about the difference between code and data. This is another area where the Internet messed up. Javascript inside HTML. SQL data that can execute itself. A terrible, terrible mess. Always, always make sure your data isn't passed to anything that will attempt to execute, run, interpret, or otherwise handle the data as if it were code.

-One of the areas they mention is "Error Message Information Leak" - this should never, ever happen. No, it's not fun to write error handling code - but it has to be done, and it has to be done right. Error messages should be for the user, not for the developer. If the developer needs more info to debug the error, then care should be taken that the developer obtains the information in a secure fashion and with as little inconvenience as possible to the user.
--The best example of how error messages should be handle is how Microsoft has been doing it: They tell the user that a crash has occurred, they attempt a best effort recovery, and they hide all of the messy details from the user. The debug info is sent via the internet (encrypted, I hope) to the developers.

The next broad category is dealing with resource management. This is where a lot of the buffer overflows happen.

-Always, always filter and check incoming data from an outside source, be it human or machine.

-Always assume that limits will be pushed. Somebody will overflow that data structure you think nobody could ever possibly fill. Prepare for that.

-Always check newly allocated memory. Always check when you create new objects. Never assume that allocating more memory or creating new objects is successful. Always be prepared for low memory conditions.

-Use a garbage collected language if possible.

The last broad category is perhaps the hardest to prepare for. Few developers are experts in security, and fewer want to know the fine details of cryptography, authentication, and secure computing in general. But it is absolutely necessary in today's world of serious, profit driven hackers.

-Any communication outside the computer, be it a local network or the Internet, should be secured. It there is private or confidential information being communicated or stored, encrypt it.

-Passwords should have as few length and complexity restrictions as possible. In fact, greater lengths and complexities should always be encouraged. It drives me crazy when I get some site that asks for "8 characters max, letters only," knowing full well that it's trivial to create a brute force guesser that could solve it in seconds.

-Limit how fast passwords can be guessed. A human will never know that they can only guess a password once a second, and will never care that you've limited the number of guesses to 100 a day. It will, however, thwart automated password guessers.

-Always hash passwords. Always encrypt passwords sent over a network or the internet. Passwords should never be plaintext.

-If you're going to encrypt, always encrypt end to end. Encrypt as soon as possible and delay decryption until the last possible moment. Never leave anything in plaintext if it can be avoided.

-Keep on top of security news and best practices. Know what's broken, know what's not. In the world of wireless, WEP is broken (one minute to crack). WPA is still secure. I still see people making the mistake of setting up WEP. They might as well have a cable to curb with a sign saying "free internet!"

-Be aware of how encryption is implemented. Poorly implemented encryption might as well be no encryption at all. Get an expert if you are unsure.

-Try to keep security as simple as possible while keeping it secure. It's hard enough to understand and implement by itself, don't confuse anybody even further by offering extra arbitrary options.

-Be secure by default. Most users aren't interested in a lot of tweaking and generally don't do much beyond the default setup.

-Layered security. Don't trust one line of defense.

-Don't give out trusted privileges easily. Always authenticate, always check.

Most of all, this is the best advice:

*Always write software to be secure from the ground up. It is far more difficult to fix poorly written software than to make adjustments to software that is already secure.; Posted by: CobraA1 Posted on: 01/13/09 (Edited: 01/13/2009 @ 08:03) You are currently: a Guest | Members login | Terms of Use