Application Security

3/28/2014
09:00 AM
Jeff Williams
Jeff Williams
Commentary
Connect Directly
Twitter
LinkedIn
Google+
RSS
E-Mail
50%
50%

Flying Naked: Why Most Web Apps Leave You Defenseless

Even the best-funded and "mature" corporate AppSec programs aren't testing all their web applications and services. That leaves many applications with no real security in place.

Imagine for a moment a major airline only checking 10 percent of its fleet for safety problems. Now imagine that when they do check an aircraft, they find 22 safety problems (some major, some minor). That would represent a crazy business risk for any airline. Roughly 90 percent of the fleet wouldn’t be checked for safety and mechanical problems. That would never fly. But yet, I am here to tell you that 90 percent of applications in most organizations are naked -- since they have no application security defenses in place.

When I say "application security" I’m not talking about infrastructure, operating systems, firewalls, intrusion detection systems, etc. I’m talking about the custom code you wrote for your business, internal and external. The defenses we have for these custom applications don’t work. Not surprisingly, this is where 54 percent of the breaches come from. Here’s why they aren’t protecting us:

Network security products work because they know what’s behind them. They know that they’re defending Windows, MacOS, Internet Explorer, and Google Chrome so they know how to identify attacks on those products and stop them. Custom application code is different. Every custom application is a beautiful and unique snowflake; you can’t identify attacks on these snowflakes by looking at network traffic. Period. Only the application knows what defenses are in place and what input will allow an attack to succeed. The trick is knowing how to get this knowledge out.

The image below is an attack on one of those snowflakes that happens to process Morse code.

In fact, this is a Cross Site Scripting (XSS) attack encoded using Morse code. To state the obvious, there is no product on the planet that stops attacks in Morse code. I use this exaggerated example to make a very serious point. The attack could be a number, a short string of any characters, a null byte, anything... There is no way to know what an attack is unless you know the application itself.

Application security programs aren’t working
I’ve been in the application security field for a few decades now, and I’ve worked on AppSec programs at almost a hundred companies and federal agencies. What I see is that most organization have hundreds or thousands of web apps and web services. Yet even the best funded and "mature" programs are only really testing 10 percent of their applications. That leaves 90 percent naked, with no real security. And many of the breaches you read about are against the 90 percent. The 10 percent are in pretty bad shape, too, averaging 22.4 serious vulnerabilities per application.

These stunning numbers come from Aspect Security’s "2013 Global Application Security Risk Report." We used a combination of manual code review, manual penetration testing, and automated tools to analyze thousands of critical applications. The most prevalent vulnerabilities are: Identification and Authentication, Input Validation and Encoding, Session Management, Sensitive Data Protection, and Access Control. Compare these results with similar results from tool vendors, and you’ll see a striking difference -- because tools alone can’t effectively test for at least three of the top five categories.

 Click to continue to page 2: The Way Forward

A pioneer in application security, Jeff Williams is the founder and CTO of Contrast Security, a revolutionary application security product that enhances software with the power to defend itself, check itself for vulnerabilities, and join a security command and control ... View Full Bio

Previous
1 of 2
Next
Comment  | 
Print  | 
More Insights
Comments
Oldest First  |  Newest First  |  Threaded View
<<   <   Page 2 / 2
planetlevel
100%
0%
planetlevel,
User Rank: Author
4/1/2014 | 4:10:18 PM
Re: Large-Scale AppSec Programs
All, you might find the talk I did at OWASP AppSecUSA this year interesting. It's called "AppSec at DevOps Speed and Portfolio Scale."  There are a lot more ideas about how to create a scalable, realtime, and most importantly CONTINUOUS appsec capability.  --Jeff
bamchenry
100%
0%
bamchenry,
User Rank: Apprentice
4/2/2014 | 11:48:22 AM
Re: Large-Scale AppSec Programs
I have seen the "continuous" approach to AppSec be addressed by the DevOps model for IT, by creating a format for security teams to have input into the software development lifecycle (SDLC). At a scale of hundreds, much less thousands, of web applications, the challenge is balancing security with manageability, usability, and development velocity. Tailoring your application security practice at an app-by-app level is only tenable if there are few apps, so there are going to be some compromises in the name of manageability, usability, and dev velocity.
lazydogtown
100%
0%
lazydogtown,
User Rank: Apprentice
4/6/2014 | 2:18:03 PM
> To state the obvious ... a decent waf would have blocked the morse-attack
> To state the obvious, there is no product on the planet that stops attacks in Morse code.

nope; a decent WAF like  naxsi would have blocked at least the morsecode-request with its core-ruleset

/know-it-all-mode off :D

 

yes, i know, a WAF is less than a plaster for insecure webapps and cannot protect from stupidity.

--ld
AnhT053
50%
50%
AnhT053,
User Rank: Apprentice
9/5/2014 | 11:18:07 PM
http://www.playkix.net/
I enjoyed your article .. thank you for allowing her to share comments
<<   <   Page 2 / 2
Want Your Daughter to Succeed in Cyber? Call Her John
John De Santis, CEO, HyTrust,  5/16/2018
New Mexico Man Sentenced on DDoS, Gun Charges
Dark Reading Staff 5/18/2018
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: This comment is waiting for review by our moderators.
Current Issue
Flash Poll
[Strategic Security Report] Navigating the Threat Intelligence Maze
[Strategic Security Report] Navigating the Threat Intelligence Maze
Most enterprises are using threat intel services, but many are still figuring out how to use the data they're collecting. In this Dark Reading survey we give you a look at what they're doing today - and where they hope to go.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2018-11354
PUBLISHED: 2018-05-22
In Wireshark 2.6.0, the IEEE 1905.1a dissector could crash. This was addressed in epan/dissectors/packet-ieee1905.c by making a certain correction to string handling.
CVE-2018-11355
PUBLISHED: 2018-05-22
In Wireshark 2.6.0, the RTCP dissector could crash. This was addressed in epan/dissectors/packet-rtcp.c by avoiding a buffer overflow for packet status chunks.
CVE-2018-11356
PUBLISHED: 2018-05-22
In Wireshark 2.6.0, 2.4.0 to 2.4.6, and 2.2.0 to 2.2.14, the DNS dissector could crash. This was addressed in epan/dissectors/packet-dns.c by avoiding a NULL pointer dereference for an empty name in an SRV record.
CVE-2018-11357
PUBLISHED: 2018-05-22
In Wireshark 2.6.0, 2.4.0 to 2.4.6, and 2.2.0 to 2.2.14, the LTP dissector and other dissectors could consume excessive memory. This was addressed in epan/tvbuff.c by rejecting negative lengths.
CVE-2018-11358
PUBLISHED: 2018-05-22
In Wireshark 2.6.0, 2.4.0 to 2.4.6, and 2.2.0 to 2.2.14, the Q.931 dissector could crash. This was addressed in epan/dissectors/packet-q931.c by avoiding a use-after-free after a malformed packet prevented certain cleanup.