Application Security: We Still Have A Long Way To Go

The past decade shows only trivial progress in improving web app security, according to new vulnerability guidelines in the OWASP Top Ten 2013.

Application security problems are not only the most common type of vulnerability, they also lead to the majority of breaches. In 2003, I wrote the first Top Ten Application Security Risks for the Open Web Application Security Project (OWASP). Our goal at the time was to raise awareness and improve software security through the establishment of free and open industry standards.

In case you are wondering, OWASP is an open-source community comprised of software developers from corporations, educational organizations, and other interested individuals from around the world.

The first Top Ten was based primarily on our members' experiences -- we didn’t have much data to support our choices back then. Today, there’s serious analysis backing the standard in the OWASP Top Ten 2013. The data comes from eight leading security firms specializing in application testing and verification. Collectively, the data is comprised of over half a million vulnerabilities, across hundreds of organizations, and thousands of applications.

The Top 10 items are selected and prioritized according to their prevalence and consensus estimates of exploitability, detectability, and impact. It’s been translated into dozens of languages and is implemented in most application security tools. There are three major updates this year:

Using Known Vulnerable Components. Modern applications frequently leverage hundreds of libraries. All of this code runs with the full privilege of the application, so vulnerabilities can be devastating. A recent study by Aspect Security of over 113 million library downloads by developers in 60,000 organizations, showed that 26 percent of those downloads contain known vulnerabilities. The new OWASP Top Ten has suggestions for finding and eliminating these problems.

Missing Function Level Access Control. When developers create web interfaces, they have to restrict which users can see various links, buttons, forms, and pages. Developers usually get this right because it is very visible. Unfortunately, making it pretty doesn’t make it secure. Developers often forget that they also have to put access controls in the business logic that actually performs business functions. The new OWASP Top Ten expands this category and provides helpful guidance.

Sensitive Data Exposure. The importance of encrypting both web traffic and sensitive data in storage cannot be underestimated. This new combined Top Ten item is intended to focus development teams on creating a unified strategy to identify sensitive data and encrypt it wherever it goes. You can refer to the new OWASP Top Ten for guidance on storing credentials safely, encrypting backups, caching, autocomplete and other often overlooked topics.

Important work is still aheadOver the last 10 years, the OWASP Top Ten has been used by millions of people, referenced by the Federal Trade Commission, and the OWASP Foundation has grown immensely. We’re very proud of our efforts to date, but we still have a long way to go.

Initially, our principal goal was to raise the floor every few years, but we haven’t been able to do that, as evidenced by what I consider to be essentially trivial results in improving application security. In the decade between the 2003 and 2013 editions, we haven’t been able to stamp out even one category of application security problem. For example, SQL Injection appeared in 1998 and is still a huge problem that accounted for 83 percent of breaches over the last 15 years and resulted in the compromise of hundreds of millions of people’s credit card numbers, financial information, and healthcare information.

One reason for these disappointing results is because the OWASP Top Ten is only an awareness document -- just one tiny first step towards cultivating a culture that generates application security. To be sure, there’s no better first step for raising IT industry awareness of the application security issues that drive security managers to focus on cost-effective defense strategies.

To that end, I encourage you to pick just one of the Top Ten, create sensors in your development and test organizations, and establish a real-time dashboard across your application portfolio. Then expand your program to cover other risks. There is no "right" way to create an application security program, so don’t measure yourself against what others are doing.

If you know a developer, take a second and send them a copy of the OWASP Top Ten. It’s time to eliminate simple vulnerabilities like Cross-Site Scripting and SQL Injection forever.

Now it’s your turn. What are the application security problems that are keeping you up at night? Let’s chat about them in the comments and brainstorm ways we can make faster progress in improving application security.

The companies still do not allocate enough time for app level security review and testing. HealthCare.gov is one recent example. It would useful if you could write a high-level review of the app security tools that allow projects to address app security issues.

@irakov raises two great points about 1. companies not giving developers the time they need for security review and testing and 2. guidance about the best tools available to perform those test. For example, what are the steps you recommend to make headway against SQL Injection?

Not providing developers with ample time has always been a problem, at least in my experiences. The reason is usually because developers have to deal with deadlines and demands that management doesn't always know impacts the software development lifecycle. Doesn't anyone else here agree with that assessment?

Thanks for article Jeff, and your presentations at AppSecUSA! It's great to see that OWASP has recognized the prevalence of components in today's applications. Sonatype has done research that indicates that the average application consists of 80% or more open source components. While using components like web frameworks, logging utilities, database access routines, etc., speed development, if organizations don't manage the use of components, they can put the organization at risk.

We published a whitepaper that addresses the A9 requirement and application components -

@ danielcawrey, I strongly agree with you on this. It is a problem developers have always been complaining about that they are not given sufficient time to do their job thoroughly and their own way. When you are tightly running against time, you are sure to miss out on some minor things which in case of application development don't prove to be that minor vulnerabilities.

This is quite understandable that when developers have to leverage their app with other sources like libraries which are not under their control they are dealing with danger. What could possibly be done about it? Should they be selective about giving access to libraries considering potential vulnerabilities which come with them? Or they can actually do something about those vulnerabilities?

You're right that developers are often put into the very difficult position of being blamed for security problems without the proper process/tools/time/etc... to actually make that happen. I gave a talk recently "Application Security at DevOps Speed and Portfolio Scale" that presents a new approach to this dilemma. I'll be writing more about this, but I'd love to hear your thoughts. youtube.com/watch?v=cIvOth0fxmI

Published: 2015-03-03Off-by-one error in the ecryptfs_decode_from_filename function in fs/ecryptfs/crypto.c in the eCryptfs subsystem in the Linux kernel before 3.18.2 allows local users to cause a denial of service (buffer overflow and system crash) or possibly gain privileges via a crafted filename.

Published: 2015-03-03** REJECT ** DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: none. Reason: This candidate was withdrawn by its CNA. Further investigation showed that it was not a security issue in customer-controlled software. Notes: none.

How can security professionals better engage with their peers, both in person and online? In this Dark Reading Radio show, we will talk to leaders at some of the security industry’s professional organizations about how security pros can get more involved – with their colleagues in the same industry, with their peers in other industries, and with the IT security community as a whole.