An interesting article published earlier this week on Information Week’s website here called “Web Applications: Achilles’ Heel Of Corporate Security” discusses the tremendous rise in web-application breaches and attacks this past year.

IBM’s 2008 X-Force Trend and Risk report which was released Monday states:

“Certain types of corporate applications, namely custom-built software like Web applications, remain a highly profitable and inexpensive target for criminal attackers. The sheer number of new vulnerabilities, the majority of which have no available patch, coupled with the hundreds of thousands of custom Web applications that are also vulnerable (but never subject to a vulnerability disclosure, much less a patch), continue to be the Achilles’ heel of corporate security.”

Since CIOZone.com is currently running a poll regarding what is considered the largest security threat, and since ‘Poorly coded web applications’ is rightly on the list, I thought this a good topic for this week’s article. By the way, you can view the poll results here.

So should you be worried about your web applications and should it be a top priority? The answers are “yes” and “maybe”. You should be worried about your organization’s web applications, but it may not be your biggest risk. In combing through the data breaches listed at www.privacyrights.org the overwhelming majority of breaches are due to human error, via either incompetence or malice. Simple things like throwing sensitive hard-copy paperwork in the garbage dates back to before the computing industry dominated the workforce.

What does this say about the state of affairs in many organizations in relation to their information security posture? It’s tough to say for sure, but there is certainly evidence that many organizations are simply not preparing their employees properly with regular Security Awareness Training. While working on a Social Engineering assessment for a client late last year, we found more damaging, earth-shattering information in the company’s dumpster than email phishing and other impersonation attacks. In fact, the 10 minutes it took us to go through their trash yielded 90% of the total data collected during the engagement…and this isn’t exactly an isolated incident.

So what’s my point? Basically that although Web Applications are certainly the current target of choice, this is not a new issue, and wont be solved by focusing on the specific issue. Rather, focusing on Information Security as a whole, from the top down, in any organization continues to be the best approach to minimize the impact to any organization. No problem in Information Security has ever been solved by a product, a process or a policy, rather the combination of all 3 and a commitment to security-minded thinking in daily operations and planning initiatives.

There has been a lot of press, effort and money focused on Web Application Security over the past year–and rightly so. The attack footprint for many publicly-facing web applications has been growing as new web and browser-based vulnerabilities are being discovered at a scary pace. The PCI DSS push has helped primarily with the escalation of the press given, but we really haven’t crossed the bridge of minimizing the impact yet, and many security experts don’t yet see the light at the end of the tunnel.

What I want to discuss in this article is the trend observed over the past year, taken from data collected from hundreds of Pen Tests performed by myself and my peers. The results are indeed interesting.

Although web services take the cake, it’s not the web application vulnerabilities we hear about so much (such as XSS, SQL Injection and CSRF) that tops the list. In fact, the Top 8 of the Top 10 (although may contribute in some cases to things like XSS) are configuration and deployment errors.

The List (Organized by Number of Occurrences):

1. Weak, Insecure and Deprecated SSL Ciphers
2. TRACE Debugging Method Enabled on Web Server
3. Private IP Address of Web Server Leaked Through Headers (IIS)
4. Form Credentials and Confidential Information Transmitted over Clear Text (no SSL)
5. Default, Vendor Supplied Directories and Files (Mainly Apache/Tomcat Installations)
6. Poorly Configured Apache Servers, Including Directory Indexing and User Home Directories
7. Default ASP.NET Errors on IIS Installations
8. Unpatched IIS Installations Vulnerable to Remote Exploit
9. Presence of phpinfo() pages on Apache/PHP Installations
10. Cross-Site Scripting (XSS) Vulnerabilities

So at least one of the media-worthy vulnerabilities hits the list (XSS), but what is surprising to me is that common configuration errors and poor judgment calls by far takes the cake. In fact, when looking at the following graph, it is apparent just how bad this situation is.

This data is taken from raw pen testing data, is not specific to web servers and web applications only, and does not in any way correlate to things such as the OWASP Top 10 and the CWE Top 25 Programming Errors lists.

Food for thought: has the focus on web application security completely blinded us to the standard level of due care that should be exhibited in activities such as server deployment and patch management?

Several weeks ago I stumbled on a client’s e-commerce site that had (what appeared to be) a non-vulnerable SQL Injection pathway on a search form. I used the standard calls to determine if it was vulnerable, determined (or so I thought) that it wasn’t and moved on to test for XSS.

While testing for XSS with the de-facto

alert('xss')
script that we all know and love, turns out the vulnerable field was in fact prone to SQL Injection (I just had to mod my testing methods a little bit).

Throughout the course of running the concept of utilizing XSS to perform SQL Injection past colleagues and other forums, it quickly became apparent that the biggest use would be in targeting sites with known persistent XSS vectors, to amass a distributed SQL Injection attack towards a vulnerable 3rd party system.

So, why is this important? Well, there are many SQL Injection automated tools (many listed in my Pen Testing Tools section) that can perform brutal SQL Injection attacks, but can be traceable by source IP address. You could run through a series of proxies, but that too is eventually traceable.

This means that a potentially insignificant XSS on your website/portal could be used as a launching point via Javascript to perform an unwitting SQL Injection attack against a third party…all the more reason to close even those tiny XSS flaws in your site

- Donwalrus