Risk
7/11/2013
07:33 AM
Quick Hits
Quick Hits
Quick Hits
Connect Directly
RSS
E-Mail
50%
50%
Repost This

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
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2012-3946
Published: 2014-04-24
Cisco IOS before 15.3(2)S allows remote attackers to bypass interface ACL restrictions in opportunistic circumstances by sending IPv6 packets in an unspecified scenario in which expected packet drops do not occur for "a small percentage" of the packets, aka Bug ID CSCty73682.

CVE-2012-5723
Published: 2014-04-24
Cisco ASR 1000 devices with software before 3.8S, when BDI routing is enabled, allow remote attackers to cause a denial of service (device reload) via crafted (1) broadcast or (2) multicast ICMP packets with fragmentation, aka Bug ID CSCub55948.

CVE-2013-6738
Published: 2014-04-24
Cross-site scripting (XSS) vulnerability in IBM SmartCloud Analytics Log Analysis 1.1 and 1.2 before 1.2.0.0-CSI-SCALA-IF0003 allows remote attackers to inject arbitrary web script or HTML via an invalid query parameter in a response from an OAuth authorization endpoint.

CVE-2014-0188
Published: 2014-04-24
The openshift-origin-broker in Red Hat OpenShift Enterprise 2.0.5, 1.2.7, and earlier does not properly handle authentication requests from the remote-user auth plugin, which allows remote attackers to bypass authentication and impersonate arbitrary users via the X-Remote-User header in a request to...

CVE-2014-2391
Published: 2014-04-24
The password recovery service in Open-Xchange AppSuite before 7.2.2-rev20, 7.4.1 before 7.4.1-rev11, and 7.4.2 before 7.4.2-rev13 makes an improper decision about the sensitivity of a string representing a previously used but currently invalid password, which allows remote attackers to obtain potent...

Best of the Web