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
Election Websites, Back-End Systems Most at Risk of Cyberattack in Midterms
Kelly Jackson Higgins, Executive Editor at Dark Reading,  8/14/2018
Intel Reveals New Spectre-Like Vulnerability
Curtis Franklin Jr., Senior Editor at Dark Reading,  8/15/2018
Australian Teen Hacked Apple Network
Dark Reading Staff 8/17/2018
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2018-15504
PUBLISHED: 2018-08-18
An issue was discovered in Embedthis GoAhead before 4.0.1 and Appweb before 7.0.2. The server mishandles some HTTP request fields associated with time, which results in a NULL pointer dereference, as demonstrated by If-Modified-Since or If-Unmodified-Since with a month greater than 11.
CVE-2018-15505
PUBLISHED: 2018-08-18
An issue was discovered in Embedthis GoAhead before 4.0.1 and Appweb before 7.0.2. An HTTP POST request with a specially crafted &quot;Host&quot; header field may cause a NULL pointer dereference and thus cause a denial of service, as demonstrated by the lack of a trailing ']' character in an IPv6 a...
CVE-2018-15492
PUBLISHED: 2018-08-18
A vulnerability in the lservnt.exe component of Sentinel License Manager version 8.5.3.35 (fixed in 8.5.3.2403) causes UDP amplification.
CVE-2018-15494
PUBLISHED: 2018-08-18
In Dojo Toolkit before 1.14, there is unescaped string injection in dojox/Grid/DataGrid.
CVE-2018-15495
PUBLISHED: 2018-08-18
/filemanager/upload.php in Responsive FileManager before 9.13.3 allows Directory Traversal and SSRF because the url parameter is used directly in a curl_exec call, as demonstrated by a file:///etc/passwd value.