Application Security
11/21/2013
01:06 PM
Jeff Williams
Jeff Williams
Commentary
Connect Directly
Twitter
LinkedIn
Google+
RSS
E-Mail
100%
0%

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 ahead
Over 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.

 

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
<<   <   Page 2 / 2
danielcawrey
50%
50%
danielcawrey,
User Rank: Apprentice
11/21/2013 | 5:39:47 PM
Re: App security tools ?
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?
Marilyn Cohodas
100%
0%
Marilyn Cohodas,
User Rank: Strategist
11/21/2013 | 4:23:01 PM
Re: App security tools ?
@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?
irakov
50%
50%
irakov,
User Rank: Apprentice
11/21/2013 | 2:09:07 PM
App security tools ?
Jeff,


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.
<<   <   Page 2 / 2
Register for Dark Reading Newsletters
White Papers
Cartoon
Current Issue
Dark Reading Must Reads - September 25, 2014
Dark Reading's new Must Reads is a compendium of our best recent coverage of identity and access management. Learn about access control in the age of HTML5, how to improve authentication, why Active Directory is dead, and more.
Flash Poll
DevOps’ Impact on Application Security
DevOps’ Impact on Application Security
Managing the interdependency between software and infrastructure is a thorny challenge. Often, it’s a “developers are from Mars, systems engineers are from Venus” situation.
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2012-5485
Published: 2014-09-30
registerConfiglet.py in Plone before 4.2.3 and 4.3 before beta 1 allows remote attackers to execute Python code via unspecified vectors, related to the admin interface.

CVE-2012-5486
Published: 2014-09-30
ZPublisher.HTTPRequest._scrubHeader in Zope 2 before 2.13.19, as used in Plone before 4.3 beta 1, allows remote attackers to inject arbitrary HTTP headers via a linefeed (LF) character.

CVE-2012-5487
Published: 2014-09-30
The sandbox whitelisting function (allowmodule.py) in Plone before 4.2.3 and 4.3 before beta 1 allows remote authenticated users with certain privileges to bypass the Python sandbox restriction and execute arbitrary Python code via vectors related to importing.

CVE-2012-5488
Published: 2014-09-30
python_scripts.py in Plone before 4.2.3 and 4.3 before beta 1 allows remote attackers to execute Python code via a crafted URL, related to createObject.

CVE-2012-5489
Published: 2014-09-30
The App.Undo.UndoSupport.get_request_var_or_attr function in Zope before 2.12.21 and 3.13.x before 2.13.11, as used in Plone before 4.2.3 and 4.3 before beta 1, allows remote authenticated users to gain access to restricted attributes via unspecified vectors.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
In our next Dark Reading Radio broadcast, we’ll take a close look at some of the latest research and practices in application security.