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?

One of the things that I constantly run into is that of security engineers trying to thwart web application attacks with network security equipment (such as IDS/IPS, AV signatures, etc).

A recent example regarded a SQL Injection attack on a web server. This particular entity has a very healthy multi-vendor network security perimeter, and felt that the gear in place was sufficient to both catch and stop a SQL Injection attack.

The really uncomfortable part about the whole thing was listening to the guy describe how he claimed to eventually stop it–by getting his IPS vendor to provide a “SQL Injection” signature. I was amazed….trying to deal with a Layer 7 issue using Layer 3 tools!!

This approach of course will not work (at least not for a determined hacker), what with the various encoding options, numerous ways to perform a SQL Injection attack, IPS signature evasion and the like.

The real issue at hand is how to address web application security attacks. Certainly, using a Web Application Firewall (WAF) in addition to the retro-firewall, but thats sort of like putting up an invisible dog fence to stop all dogs from crossing the line–its the wrong approach, and only deals with a portion of the issue (YOUR dog in this poorly-constructed example).

What was needed in this case was to address the issue of why a SQL Injection vulnerability was there in the first place–bad coding. User or URL-supplied input variables must be sanitized before injected into the SQL query, stored procedures used wherever possible, and -of course- DB permissions must be carefully handed out.

I rarely use the OSI model any more, but it has it’s value. Whether its real or made-up, the point is to address the security issue at the proper level. We need to start moving away from the idea that network security alone will protect our applications.

For a differing view, read RSnake’s post from way back in 2006 here. Although I agree with the viewpoint, the idea is to deal with the problem at the appropriate level. Most web attacks do occur at multiple theoretical OSI models, and -as such- require multiple defense strategies.

Perhaps we need a new model?

-Donwalrus