Risk
7/11/2013
07:33 AM
Dark Reading
Dark Reading
Quick Hits
50%
50%

The Five Most Common Security Pitfalls In Software Development

How can software developers build more secure applications? Here are five pitfalls to avoid

[The following is excerpted from "Five Most Common Security Pitfalls In Software Development," a new report posted this week on Dark Reading's Application Security Tech Center.]

Security tends to be a touchy subject for software developers under pressure to produce a finished product. It's hard enough to code a well-performing application that meets all functionality requirements, but it's infinitely harder to code sof tware that addresses the most common security vulnerabilities. No developer wants to see his or her application taken out by an unforeseen exploit or vulnerability.

If project managers had the luxury of time and money, much more attention could be devoted to coding practices that put security at the forefront. But the reality is that coding for security is expensive, complex and can drag out the software development lifecycle. Doing it well just takes time, and for every internal IT and commercial software development shop, time is money.

With all that said, failing to address a potential vulnerability during the software development lifecycle can be very costly -- much more so, in many cases, than the price of weaving best security practices in from the beginning.

Security pros and developers alike know you simply can't anticipate, predict or prevent each and every attack that may be lobbed at your software application. However, they also know that the vast majority of attacks can be mitigated through sound coding practices.

According to a recent vulnerability trends report released by Cenzic, 99% of software applications that Cenzic tested in 2012 had at least one vulnerability, with an average of 13 vulnerabilities in the pool of software applications that the firm tested in 2013.

Some of the vulnerabilities that Cenzic discovered could be attributed to the infrastructure side of the house, such as Web server configuration issues, authentication weakness or patch management issues. But the application-specific vulnerabilities discovered were the same old, predictable and preventable SQL injection, XSS and code execution attacks that we have been seeing for years.

Developers mindful of application security know that there are things you can control, and there are things you can't control. For example, you likely can't control the way that your company's Web servers are managed and patched. However, you can control your application logic; you can control API calls; and you can control the methods and functions you use in your code. For that matter, you can control how you process and store data, and you can likely control the way your applications interact with a back-end database.

In general, addressing the overall security of an application is best left in the hands of a developer. Yes, Web security proxies and other network security tools will filter out potentially damaging attacks, but these tools are not bulletproof. Developers must make sure that their applications are as close to unhackable as possible when, invariably, an attacker does make it past other defenses. There are many ways to do this, but in this report we recommend the five that will have the biggest impact against the most damaging attacks you're likely to see.

1. Validate All User Input and Escape Output
The vast majority of vulnerabilities in database-driven Web applications can be attributed in some way to the way we process user-supplied input. So why don't developers implement proper validation all the time? The real truth is that validating all user-supplied input can be costly--both in terms of the complexity of the additional code required to make it work and longer development and testing cycles. And, from a technical perspective, validating all user-supplied input isn't exactly an easy task.

As with many things related to software development, there are several different ways to approach this problem.

To read more about validating user input -- and to read the other four most common security pitfalls in software development -- download the free report.

Have a comment on this story? Please click "Add a Comment" below. If you'd like to contact Dark Reading's editors directly, send us a message.

Comment  | 
Print  | 
More Insights
Register for Dark Reading Newsletters
White Papers
Cartoon
Current Issue
Flash Poll
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2013-2184
Published: 2015-03-27
Movable Type before 5.2.6 does not properly use the Storable::thaw function, which allows remote attackers to execute arbitrary code via the comment_state parameter.

CVE-2014-3619
Published: 2015-03-27
The __socket_proto_state_machine function in GlusterFS 3.5 allows remote attackers to cause a denial of service (infinite loop) via a "00000000" fragment header.

CVE-2014-8121
Published: 2015-03-27
DB_LOOKUP in nss_files/files-XXX.c in the Name Service Switch (NSS) in GNU C Library (aka glibc or libc6) 2.21 and earlier does not properly check if a file is open, which allows remote attackers to cause a denial of service (infinite loop) by performing a look-up while the database is iterated over...

CVE-2014-9712
Published: 2015-03-27
Websense TRITON V-Series appliances before 7.8.3 Hotfix 03 and 7.8.4 before Hotfix 01 allows remote administrators to read arbitrary files and obtain passwords via a crafted path.

CVE-2015-2157
Published: 2015-03-27
The (1) ssh2_load_userkey and (2) ssh2_save_userkey functions in PuTTY 0.51 through 0.63 do not properly wipe SSH-2 private keys from memory, which allows local users to obtain sensitive information by reading the memory.

Dark Reading Radio
Archived Dark Reading Radio
Good hackers--aka security researchers--are worried about the possible legal and professional ramifications of President Obama's new proposed crackdown on cyber criminals.