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.

The way forward
Over the past 10 years, many organizations have created a separate application security group that does scanning and testing. But in the past few years, software development has simply exploded, making the AppSec group a bottleneck and putting it under continual pressure to go faster and handle a larger portfolio, which lowers the bar and produces fewer results.

To find answers, let’s zoom in on a specific vulnerability -- clickjacking  -- where the attacker frames your web page, makes it transparent, and floats it over its own site. When users try to click on the buttons and links on the attacker’s site, they actually click on your transparent page, doing things the user didn’t intend. As long as the unwary victim is logged in, these hijacked clicks can cause real effects in your application. Fortunately, the defense is very simple: Just add an X-FRAME-OPTIONS: SAMEORIGIN header to all your pages.

Compare that to performing a penetration test or scan on every application in your portfolio for this problem, which would take forever. We’re looking for a continuous, real-time way to monitor the whole portfolio at once. Fortunately, there are a lot of ways to accomplish this. My suggestion is to use a passive tool (like OWASP’s ZAP) to verify that the X-FRAME-OPTIONS header is set on all your pages in a test environment. If you’re interested, you can check your website's headers for yourself using a free online tool I wrote called CheckYourHeaders (named after a great Beastie Boys album).

Here are three ideas that you can use to transform your organization to a continuous application security approach.  Remember, vulnerabilities are like termites -- every second they go undiscovered, they get more expensive.

Idea 1: Stop doing application security one-application-at-a-time. Instead, look to continuous, real-time, positive, portfolio-wide monitoring as described above. Over time, you can convert all of your security concerns into continuous, real-time monitoring and move away from the periodic tests. Instead of starting over from scratch each year, you can improve continuously 

Idea 2: Standardize defenses. Help your developers by giving them a great set of enterprise security defenses. Verifying applications at portfolio scale is considerably easier if you’ve adopted standard defenses. For example, you might adopt the OWASP ESAPI library for input validation, output encoding, and encryption. You could use log4j for logging. Or implement an authentication gateway that relies on LDAP.

Idea 3: Train in secure coding. Training works. One company I worked with had a 74 percent reduction in vulnerabilities on teams where at least half of the developers were trained. If you’d like to know what your development teams know and don’t know about application security, try the free tool, Secure Coder Analytics. It’s simple to sign up and invite a team of developers. Then, each developer takes a fully randomized and anonymized 20-question quiz drawn from hundreds of well vetted questions.

Please share your thoughts in the comments below. And remember: Nobody wants to see a naked app.

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
2 of 2
Next
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
<<   <   Page 2 / 2
Randy Naramore
50%
50%
Randy Naramore,
User Rank: Ninja
3/31/2014 | 3:05:39 PM
Re: Continuous application security approach
I work in the banking/finance industry and we test "all" web apps prior to being deployed, it is a necessity and any findings that are in the high or medium categories have to be fixed before going live. We test and code according to the OWASP secure coding practices which takes to time for developers to adhere to. This approach helps us.
WireHarborSec
50%
50%
WireHarborSec,
User Rank: Apprentice
3/31/2014 | 12:37:25 PM
Large-Scale AppSec Programs
In my previous role I managed the appsec team with a company who's portfolio spanned over 3K applications. The *only* way to scale appsec programs to this size is by using a continuous-type approach. Internal pen-testing teams cannot keep up. 

Add in agile development methodology and it gets even more chaotic. 
RyanSepe
100%
0%
RyanSepe,
User Rank: Ninja
3/29/2014 | 11:20:43 PM
Re: Continuous application security approach
I know from being in the Healthcare Industry that application security is a large concern. My team has not been able to test app security continuously because for us there are regulations that make it increasingly difficult. This is why continuous network security is the main focal point, but as the article delineates, this does not have much effect on the app vulnerabilities.

For my previous statement regarding regulations making this difficult, take into account the following healthcare scenario that happens quite often. An FDA approved device can perform a medical task. This device needs to be used and functionality is the biggest proponent when creating these devices. This device has a software counterpart that not "speaks" to the device to extract data. The computer software can be locked down via LDAP/ other authentication methods etc but what about any software direclty on the device. Currently, many devices can be considered "smart" devices in which they have their own software directly on the device to handle and transmit data through many mediums. Many FDA devices cannot not handle multiple security safeguards and are initally barely locked down at launch making them increasingly harder to secure. Has anyone had a similar situation in their line of work and how have they handled this situation?
Marilyn Cohodas
50%
50%
Marilyn Cohodas,
User Rank: Strategist
3/28/2014 | 12:51:23 PM
Continuous application security approach
Curious to know how common -- or uncommon -- it is for organizations to take a "continuous security approach." What are some of the biggest challenges? Who within the Dark Reading community has considered or attempted such a strategy? 
<<   <   Page 2 / 2
High Stress Levels Impacting CISOs Physically, Mentally
Jai Vijayan, Freelance writer,  2/14/2019
Valentine's Emails Laced with Gandcrab Ransomware
Kelly Sheridan, Staff Editor, Dark Reading,  2/14/2019
Making the Case for a Cybersecurity Moon Shot
Adam Shostack, Consultant, Entrepreneur, Technologist, Game Designer,  2/19/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
5 Emerging Cyber Threats to Watch for in 2019
Online attackers are constantly developing new, innovative ways to break into the enterprise. This Dark Reading Tech Digest gives an in-depth look at five emerging attack trends and exploits your security team should look out for, along with helpful recommendations on how you can prevent your organization from falling victim.
Flash Poll
How Enterprises Are Attacking the Cybersecurity Problem
How Enterprises Are Attacking the Cybersecurity Problem
Data breach fears and the need to comply with regulations such as GDPR are two major drivers increased spending on security products and technologies. But other factors are contributing to the trend as well. Find out more about how enterprises are attacking the cybersecurity problem by reading our report today.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-1659
PUBLISHED: 2019-02-21
A vulnerability in the Identity Services Engine (ISE) integration feature of Cisco Prime Infrastructure (PI) could allow an unauthenticated, remote attacker to perform a man-in-the-middle attack against the Secure Sockets Layer (SSL) tunnel established between ISE and PI. The vulnerability is due to...
CVE-2019-8983
PUBLISHED: 2019-02-21
MDaemon Webmail 14.x through 18.x before 18.5.2 has XSS (issue 1 of 2).
CVE-2019-8984
PUBLISHED: 2019-02-21
MDaemon Webmail 14.x through 18.x before 18.5.2 has XSS (issue 2 of 2).
CVE-2018-20122
PUBLISHED: 2019-02-21
The web interface on FASTGate Fastweb devices with firmware through 0.00.47_FW_200_Askey 2017-05-17 (software through 1.0.1b) exposed a CGI binary that is vulnerable to a command injection vulnerability that can be exploited to achieve remote code execution with root privileges. No authentication is...
CVE-2018-6687
PUBLISHED: 2019-02-21
Loop with Unreachable Exit Condition ('Infinite Loop') in McAfee GetSusp (GetSusp) 3.0.0.461 and earlier allows attackers to DoS a manual GetSusp scan via while scanning a specifically crafted file . GetSusp is a free standalone McAfee tool that runs on several versions of Microsoft Windows.