Reference: infoworld.
http://www.infoworld.com/article/2608538/security/5-big-security-mistakes-coders-make.html1. Trusting third-party code that can't be trusted:
Programs rarely build an app from scratch. They are probably developing an application from a pastiche of proprietary code that someone created, partnered with open source or commercial, third-party software or services. 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.
The least, the programmers could do is to review recent guidance on ensuring the reliability of third-party software.
2. Hard-codeing passwords and backdoor accounts
It is usually being put for testing and then forgoten to take it out. Or maybe that backdoor administrative account was (quietly) suggested by clients thinking who's going to find out about the account? The short answer: maybe nobody -- or maybe the wrong people.
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.
3.SQL injection:
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.
Many fixes are available to mitigate these threats. At a practical level, programmers must make sure the applications they write to accept input run with the least amount of privileges needed to accomplish the task at hand. Queries or commands must use properly quoted arguments and escape special characters within those arguments.
4. Ensuring Data Security:
Insecure data handling takes many different forms and turns up on many different checklists of programming no-nos. Missing encryption comes in at No. 8 on the SANS Institute's list of the 25 most dangerous programming errors. On the OWASP list of the top 10 Web application security problems, "sensitive data exposure" is number six.
The sensitive data should not be used without encryption. But only encryption is not enough. It needs to be implemented properly, using robust encryption tools that are resistant to brute-force attacks and taking likely attack scenarios into account to prevent the protection that encryption provides from being subverted. Old encryption algorithms are vulnerable to brute-force attacks.
The rash of major data breaches in the last year familiarized a surprisingly large swath of the public to the nuances of encryption. In the course of trying to figure out whether or not their data was stolen, consumers had to wade through cryptography terms such as "symmetric algorithm," "hashing," and "salt." This exposed the fact that not every firm used due care in protecting the data they collected.
