5 big security mistakes coders make

Security errors are rife in application development. Here are five of the most egregious -- and common -- missteps

Hacks make headlines. But usually, the focus is on who did it -- notorious cyber criminals, hacktivists, or state-sponsored actors. Readers want to know who they are, where they're from, what they did, and why they did it. How they did it gets glossed over.

In fact, the "how" is the most important part -- and application vulnerabilities are common culprits. Subtle programming errors allow hackers to subvert security controls, steal user credentials, or run malicious instructions on a remote system. Programmers, like everyone else, screw up sometimes.

Screw up how, you ask? Here's a list of some of the most common (and egregious) security mistakes that coders make.

1. You trust third-party code that can't be trusted

If you program for a living, you rarely -- if ever -- build an app from scratch. It's much more likely that you're developing an application from a pastiche of proprietary code that you or your colleagues created, partnered with open source or commercial, third-party software or services that you rely on to perform critical functions. These functions could range from licensed presentation and graphical interface elements to user authentication and encryption (think OpenSSL).

Often, third-party components are poorly managed and rife with exploitable vulnerabilities that may have gone unnoticed. Yet most development organizations can't even say for sure what third-party components they're using, let alone whether they were audited for security holes.

What's a developer to do? Writing from scratch isn't an option, but neither is crossing your fingers and hoping for the best. At the least, review recent guidance on ensuring the reliability of third-party software. For example, check out the U.K.'s Trustworthy Software Initiative and the Financial Services ISAC's Appropriate Software Security Control Types for Third Party Service and Product Providers.

2. You hard-code passwords and backdoor accounts

We know, we know. You put it in there for testing and forgot to take it out. Or maybe that backdoor administrative account was (quietly) suggested by folks higher up. After all, who's going to find out about the account, anyway? The short answer: maybe nobody -- or maybe the wrong people. As with extramarital affairs, in the case of backdoor accounts, you could argue that only fools get caught and everybody gets caught, yet be right both times.

Earlier this year, Cisco Systems acknowledged the existence of undocumented backdoors in several of its routers that could give a remote attacker "root" access to an affected device. In 2012, Project Basecamp, a volunteer effort to audit software used in the industrial control sector, found that login credentials for administrative accounts were frequently written into the actual firmware running ICS devices like programmable logic controllers. Rather than rush to fix the problem, many vendors argued that the accounts were "features" designed to make their products easier to manage. Nice try -- the truth is you don't know who or what will take an interest in your application or its security features.

3. You don't check inputs

SQL injection and remote file inclusion are two of the most common and most dangerous security vulnerabilities around. SQL injection in particular is the common thread that ties together almost every major breach in the last 10 years, from Sony Pictures to MySQL to LinkedIn to the security firm Bit9. The cause: Application developers trust data input from an external source like a Web-based form or even a database. By manipulating the SQL query submitted, a malicious actor can cause the database to perform an action that the programmer did not intend, such as dropping database tables containing user logins and passwords, credit card numbers, and so on.

1 2 Page 1
Page 1 of 2