HP Security Products Blog
From applications to infrastructure, enterprises and governments alike face a constant barrage of digital attacks designed to steal data, cripple networks, damage brands, and perform a host of other malicious intents. HP Enterprise Security Products offers products and services that help organizations meet the security demands of a rapidly changing and more dangerous world. HP ESP enables businesses and institutions to take a proactive approach to security that integrates information correlation, deep application analysis and network-level defense mechanisms—unifying the components of a complete security program and reducing risk across your enterprise. In this blog, we will announce the latest offerings from HP ESP, discuss current trends in vulnerability research and technology, reveal new HP ESP security initiatives and promote our upcoming appearances and speaking engagements.

".htaccess" for the win! Stomp overaccesible folder vulns.

All too often organizations are exposing themselves far too much due to lazy administration and the web applications they install aren't doing them any favors.

I doubt any one has the numbers, but websites that are just "installs" of some CMS, blog, or (insert open source app here) un(tar|zipped) into the default directory of an Apache web root are splattered across the Internet. That said, I remember appreciating this simplicity; it certainly allows any developer with any amount of tomfoolery/mad skillz in his/her bones (but mostly none) to create a webpage and have an Internet presence. The real reason these settings are default are probably due to either laziness or for parading their features (although it would be great if Apache was more secure from a default perspective). I'm off topic here, but it's not all Apache. The distributions need to take responsibility for distributing the default config themselves... why isn't there an "apache2-secure" overlay/package that would try and install a more secure set of defaults for the average user? (Answer: the maintainers are not the average user)

Whatever, I don't want to get knee deep into Apache politics and the reasons for feature X being enabled by default. Nothing changes the fact that most default installations of Apache have things like directory listings enabled as well as allowing any installed web programming modules to execute file extensions they register for inside the web root and any subdirectory. Like I said, this is great for the beginning user that doesn't know how to massage httpd.conf files, but it's scary how common these defaults are left enabled.

One of the features Apache users could probably do with out by default are Distributed configuration files (".htaccess" files). These files make it all too easy for people to forget about the root directory settings and allow their to further configure any specific settings it requires. The side effect here is that you are now also relying on the web application to remove the privileges of the web root to function securely. Of course I could come up with a bulleted list of why we need this functionality; I've used it and I'm about to advocate its use, but I challenge whether its necessary for a default installation. If you expect the Apache user to edit the httpd.conf file during the installation of Apache (to set the ServerName/IP/VirtualHosts), why not just expect that user to edit the httpd.conf file for any applications that require specific configurations? I dunno...maybe that's a little too draconian of me. But hopefully Apache doesn't make it more complicated by changing its config files to Lua...

Since we do have this feature though, how can OSS projects take advantage of it...

There is no excuse for open source apps to be distributed without ".htaccess" files limiting anonymous access to files that shouldn't be publicly accessible. There have been literally hundreds of vulnerabilities because some web applications internal files were exposed in some sub directory of the installed application.

The above is all you need to do for PHP. Just drop that ".htaccess" file in any folders your OSS project has that shouldn't be accessible publicly and voila! your done. No more information disclosure, variable overwriting, XSS, and other vulnerabilities.

In fact, if you want to take it to the next step, you should change your error reporting of 40's to the same response. Thus attackers won't be able to fingerprint your web application by the existence of your app's library files (like wafp does). Here is a snip-it to accomplish that:

Although the existence of your public files might be enough to fingerprint it, either way though your OSS project will be better off.

Of course even if you are an administrator of a web application, this is something that you can do as well. If you know certain folders are just for temporary storage by a web app or are part of a library, just create the aforementioned ".htaccess" files and stop random vagabonds from squatting on (some of) your vulnerabilities.


Top Five Web Application Vulnerabilities 7/20/09- 8/2/09

1) Hitachi Multiple Business Logic Products Unspecified Cross-Site Scripting Vulnerability

Multiple Hitachi Business Logic products are susceptible to a Cross-Site Scripting vulnerability. If successful, Cross-Site Scripting can be exploited to manipulate or steal cookies, create requests that can be mistaken for those of a valid user, compromise confidential information, or execute malicious code on end user systems. An advisory and updates which address this issue have been released. Contact the vendor for additional information.


2) IBM Tivoli Identity Manager Session Fixation Vulnerability

IBM Tivoli Identity Manager is susceptible to a session fixation vulnerability.  Victims who are enticed into visiting a malicious URI can have their session hijacked and give an attacker unauthorized access to the application. A fix has been released. Contact the vendor for further details.


3) Apache HTTP Server HTTP-Basic Authentication Bypass Vulnerability

Apache HTTP Server is susceptible to an HTTP-Basic authentication bypass vulnerability.  Successful exploitation will give an attacker access to protected resources, likely leading to more damaging attacks.  A fix has not yet been released. Contact the vendor more information.


4) WordPress Multiple Cross-Site Scripting Vulnerabilities

WordPress is susceptible to multiple instances of Cross-Site Scripting. These vulnerabilities can be exploited to execute code in the browser of an unsuspecting user and steal cookie-based authentication credentials.   A fix has not yet been released for the 'wp-comments-post.php' issue, while a patch that resolves the Comment Author URI issue is available. Contact the vendor for additional information.


5) Bugzilla 'show_bug.cgi' Information Disclosure Vulnerability

Bugzilla is susceptible to an information disclosure vulnerability. Successful exploitation would give an authenticated attacker access to sensitive information, and would likely lead to more damaging attacks.  A fix has been released. Contact the vendor for more details.


Showing results for 
Search instead for 
Do you mean 
About the Author(s)
Top Kudoed Posts
HP Blog

HP Software Solutions Blog


Follow Us
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation.