Secure Web

State of Application Security - Q2 Analysis

Cenzic will be releasing its Q2 Trends report on the state and trends of Web application security for Q2 on July 31st. Here's the executive summary from the report. You can download the full report from www.cenzic.com home page starting July 31st.

Facts around Web application security continue to surprise and alarm us. Fact – according to some estimates there are over 100 million Web applications facilitating transactions and collection information. Fact – less than 5% of applications have been tested for vulnerabilities. Fact – majority of companies who are doing anything about security are testing Web applications only while they are in development or Quality Assurance stage leaving 99% of the applications that are in deployed phase exposed at any given point. Fact – new vulnerabilities at the application layer continue to dominate. Fact – hackers continue to attack at the application layer because that’s where most of the vulnerabilities are. So, in spite of these glaring facts, why aren’t companies taking necessary steps to protect their critical information? We find that lack of awareness continues to be a problem when it comes to application security. Most companies still don’t grasp the concept of securing applications. To these companies, network firewalls, Intrusion Detection Systems (IDS), and anti-virus software should be enough to protect them from hackers. As cyber attacks continue to rise against the applications, many companies are still unaware of the fact that they have been hacked. For every hack that’s been published, there are hundreds of hacks that go unreported – sometimes for months. Hackers are getting smarter and know how to keep secrets.

Similar to our Q1 Trends report, we have noticed that vulnerabilities at the application layer continue to dominate the overall published vulnerabilities. In Q2, we observed that of the 1,484 published unique vulnerabilities, 72% related to Web technologies including Web applications, Web servers, and Web browsers. This reflects over 7% increase from Q1 number of 67%. This comes to about 355 new application related vulnerabilities per month. What’s frightening is that 65% of these vulnerabilities were easily exploitable. In other words, hackers don’t have to be overly sophisticated to take advantage of these vulnerabilities.

In terms of the types of published vulnerabilities, the trend continues to mirror the previous trends with Cross-Site Scripting, SQL Injection, and File Inclusion as the major vulnerabilities. We also observed that there are new vulnerabilities being discovered in the newer technologies like Ajax and Web-services as developers are still trying to come up to speed on how to do secure coding with these new technologies. For browsers, Internet Explorer continues to lead with 33% of the browser vulnerabilities, followed by Firefox with 26% and Opera with 21% of the vulnerabilities.

Additionally, the number of probes and attacks continue their strong pace. Activity in Q2 was influenced by vulnerabilities in IBM Lotus, Adobe, Quicktime, Cisco, Apache Tomcat, and various Microsoft vulnerabilities.

Data from Cenzic’s ClickToSecure managed service that tests thousands of pages of Web applications for customers remotely for vulnerabilities shows that once again Cross-Site Scripting vulnerabilities continue to dominate the most common vulnerabilities. Cross-Site Request Forgery, Information Leaks and Exposures, Session management types of vulnerabilities with session hijacking, authentication bypass, as well as various other Authorization and Authentication types of vulnerabilities also continue to play a major role.

With roughly 400 new application vulnerabilities arising every month just from the published vulnerabilities alone, we believe there are thousands more that are unpublished because no one reported them or because they were found in home grown applications. With a very small percentage of Web applications tested, most Corporations are highly exposed. Even the Corporations, including many large F1000, that have formal security testing in place, are testing a small fraction of their total applications. Most of the regulations around protection of consumers’ privacy information are vague at best and silent at worst when it comes to application security. Regulatory bodies need to start adding specific clauses in the various regulations that require securing of Web applications. Payment Card Industry (PCI) regulatory body has already taken some steps toward this and that’s helping increase the awareness and providing an impetus

for application security. Cenzic is also urging Corporations and Government entities to focus on a model of continuous testing of all applications whether they are in development or already deployed. By using virtualized environments, organizations can start testing all their applications not once a year but once a month and start taking action. Application security is no longer an issue of ad-hoc testing as a check box but more of a risk-management issue. We need to take action and start implementing initiatives which plug in the holes in our applications. Consumer confidence and the future viability of our e-commerce depend on it.

- Mandeep Khera, Cenzic Inc.

What are Google's intentions?

In contrast to most of the news regarding Google, which tends to focus on competition with Microsoft and Yahoo or anti-trust disputes, the company received some attention last week for an internal application security project code named Lemon.  Some details were provided from the Google security team’s blog:

                                 

http://googleonlinesecurity.blogspot.com/2007/07/automating-web-application-security.html.

                  

The internal initiative involves using fault injection techniques to detect cross site scripting vulnerabilities in Google applications.  The security staff discussed the need to have not only the ability to test many permutations of cross site scripting vulnerabilities, but also to reliably assess an application for injection points (spidering or crawling the application).  They noted that they had developed the capability in house because of the nature of the Google application development environment. 

                

Interestingly, one can speculate that this may be part of a broader initiative aimed at providing compliance services for corporate customers.  Google clearly envies the position that Microsoft holds with corporate customers, particularly the franchise in Microsoft Exchange.  Recent acquisitions of Postini and Green Border suggest that the company may be shaping a service aimed at providing a broad range of security compliance services, including application security.

    

Our take is that Google has chosen a viable approach in emulating the scanning, fault injection and assessment technology that we have been delivering for several years.  With a narrow focus on a specific vulnerability such as cross-site scripting and a particular development environment, it is likely that they will have success.   We applaud Google for taking an initiative to beef up security for its internal applications. Google needs to however, enhance this further by adding testing functionality from commercial risk-management solutions or services. Application security is not a trivial task and Google should take advantage of the expertise of the security vendors who do this for a living.  Some of the leading companies who have been fairly successful in securing their key applications have used a combination of internal and external resources. Google should adopt their model and leverage the expertise instead of trying to do everything with its own resources.

                                 

- John Reno

Defcon 15: Hacking the EULA

In preparation for DC15, the following domains have been registered. Thanks Marce!

reversebenchmarking.org

http://reversebenchmarking.com

I have invited two of my friends, Marce Luck and Webpriestess, to co-present with me. It is our goal to found the ORB Project, or the Open Reverse Benchmarking project, a collaborative and open source security consortium focusing on applying reverse benchmarking as a methodology to the research and study of false positives and scanner accuracy. Following Defcon I plan to submit talks on the ORB Project to security conferences around the globe. Beneath is an abstract of our talk. 

Each year thousands of work hours are lost by security practitioners as time is spent sorting through web application security reports and separating out erroneous vulnerability data. Individuals must currently work through this process in a vacuum, as there is no publicly available information that is helpful. Restrictive EULAs (End User License Agreements) prohibit examining a signature code-base for common errors or signature flaws. Due to the latter point, a chilling effect and has discouraged public research into the common types of false positives that existing commercial technologies are prone to exhibit.

Reverse Benchmarking is a new species of reverse engineering that involves running a security solution against an application designed to solicit false positives. Unlike testing scenarios that emphasize gathering valid or accurate data, Reverse Benchmarking involves exposing architectural or logical flaws within a web application scanner by employing techniques to trick simple rule-based mechanisms. Running a scanner against a Reverse Benchmark target quickly reveals faulty rules, flawed testing logic, or poorly written or implemented security testing procedures. Additionally, a Reverse Benchmarking application will expose patterns in the propensity of a scanner to report false results, making it easier to spot false positives when they occur in the future.

Reverse Benchmarking opens up new opportunities for studying and improving existing web application security technology by exposing common faults in testing logic that are often the culprit of massive false positives. In turn this facilitates research into a taxonomy of general false positive types, ideally, a schema for mapping particular security tests to a common, generic language. This can provide a framework around which public discussion, research, and documentation of such flaws can occur without violating EULA agreements. We will also discuss the formation of a open community initiative centered around the use of Reverse Benchmarking to study false positive types.

-tom