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 1 / 2   >   >>
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
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
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.
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
Marilyn Cohodas
50%
50%
Marilyn Cohodas,
User Rank: Strategist
4/1/2014 | 4:05:14 PM
Re: Large-Scale AppSec Programs
@wire and @planetlevel - The Dark Reading community would also be interested in hearing about your appsec scaling experience, so please share your experience on the message boards if you can!
planetlevel
100%
0%
planetlevel,
User Rank: Author
4/1/2014 | 3:38:06 PM
Re: Large-Scale AppSec Programs
@wire - I'd love to find out more about how you scaled up your appsec program continuously.  I think there are many organizations that could benefit from your experiences.  Would you be willing to discuss with me for a few minutes? If so, please reach out at [email protected] and we can set something up.  I'm gathering data for a future blog.  Thanks --Jeff
Randy Naramore
50%
50%
Randy Naramore,
User Rank: Ninja
3/31/2014 | 3:32:37 PM
Re: Continuous application security approach
Not really on the back burner but the decision has been made to push back "go live" date until app is fixed and retested. This makes all involved with deployment pay attention to details. 
Marilyn Cohodas
50%
50%
Marilyn Cohodas,
User Rank: Strategist
3/31/2014 | 3:25:10 PM
Re: Continuous application security approach
thanks. I can see how important app security must be in the financial sector! How often in the last couple of years have you actually put a web app on the back burner until insecure coding is fixed. 
Randy Naramore
50%
50%
Randy Naramore,
User Rank: Ninja
3/31/2014 | 3:18:22 PM
Re: Continuous application security approach
We have been doing this for the last 10 years at least, one challenge is to make sure developers use secure coding techniques it helps the security testers to develop a best practices approach to their whole web app program. This approach must have buy in from management because when vulnerabilities are found the decision must be made to not go live until remediation is complete. The business reputation depends on it.
Marilyn Cohodas
50%
50%
Marilyn Cohodas,
User Rank: Strategist
3/31/2014 | 3:09:48 PM
Re: Continuous application security approach
Thanks, Randy. How long have you been folloowing these practices? What has been your biggest challenges and successes?
Page 1 / 2   >   >>
13 Russians Indicted for Massive Operation to Sway US Election
Kelly Sheridan, Associate Editor, Dark Reading,  2/16/2018
From DevOps to DevSecOps: Structuring Communication for Better Security
Robert Hawk, Privacy & Security Lead at xMatters,  2/15/2018
Air Force Awards $12,500 for One Bug
Dark Reading Staff 2/15/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
How to Cope with the IT Security Skills Shortage
Most enterprises don't have all the in-house skills they need to meet the rising threat from online attackers. Here are some tips on ways to beat the shortage.
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-2017-0290
Published: 2017-05-09
NScript in mpengine in Microsoft Malware Protection Engine with Engine Version before 1.1.13704.0, as used in Windows Defender and other products, allows remote attackers to execute arbitrary code or cause a denial of service (type confusion and application crash) via crafted JavaScript code within ...

CVE-2016-10369
Published: 2017-05-08
unixsocket.c in lxterminal through 0.3.0 insecurely uses /tmp for a socket file, allowing a local user to cause a denial of service (preventing terminal launch), or possibly have other impact (bypassing terminal access control).

CVE-2016-8202
Published: 2017-05-08
A privilege escalation vulnerability in Brocade Fibre Channel SAN products running Brocade Fabric OS (FOS) releases earlier than v7.4.1d and v8.0.1b could allow an authenticated attacker to elevate the privileges of user accounts accessing the system via command line interface. With affected version...

CVE-2016-8209
Published: 2017-05-08
Improper checks for unusual or exceptional conditions in Brocade NetIron 05.8.00 and later releases up to and including 06.1.00, when the Management Module is continuously scanned on port 22, may allow attackers to cause a denial of service (crash and reload) of the management module.

CVE-2017-0890
Published: 2017-05-08
Nextcloud Server before 11.0.3 is vulnerable to an inadequate escaping leading to a XSS vulnerability in the search module. To be exploitable a user has to write or paste malicious content into the search dialogue.