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-2011-4403
Published: 2015-04-24
Multiple cross-site request forgery (CSRF) vulnerabilities in Zen Cart 1.3.9h allow remote attackers to hijack the authentication of administrators for requests that (1) delete a product via a delete_product_confirm action to product.php or (2) disable a product via a setflag action to categories.ph...

CVE-2012-2930
Published: 2015-04-24
Multiple cross-site request forgery (CSRF) vulnerabilities in TinyWebGallery (TWG) before 1.8.8 allow remote attackers to hijack the authentication of administrators for requests that (1) add a user via an adduser action to admin/index.php or (2) conduct static PHP code injection attacks in .htusers...

CVE-2012-2932
Published: 2015-04-24
Multiple cross-site scripting (XSS) vulnerabilities in TinyWebGallery (TWG) before 1.8.8 allow remote attackers to inject arbitrary web script or HTML via the (1) selitems[] parameter in a copy, (2) chmod, or (3) arch action to admin/index.php or (4) searchitem parameter in a search action to admin/...

CVE-2012-5451
Published: 2015-04-24
Multiple stack-based buffer overflows in HttpUtils.dll in TVMOBiLi before 2.1.0.3974 allow remote attackers to cause a denial of service (tvMobiliService service crash) via a long string in a (1) GET or (2) HEAD request to TCP port 30888.

CVE-2015-0297
Published: 2015-04-24
Red Hat JBoss Operations Network 3.3.1 does not properly restrict access to certain APIs, which allows remote attackers to execute arbitrary Java methos via the (1) ServerInvokerServlet or (2) SchedulerService or (3) cause a denial of service (disk consumption) via the ContentManager.

Dark Reading Radio
Archived Dark Reading Radio
Join security and risk expert John Pironti and Dark Reading Editor-in-Chief Tim Wilson for a live online discussion of the sea-changing shift in security strategy and the many ways it is affecting IT and business.