Thursday, July 23, 2009

A common Apache .htaccess misconfiguration

If you want to restrict a directory on an Apache server to specific users, you will probably use an .htaccess/.htpasswd configuration. This allows you to add authentication to a directory or an entire site. The sad thing is, if I search for sample configurations on Google, five out of ten examples are insecure…

In fact years ago, I made the mistake of taking one of those sample configurations and used it on a site I had made. A typical .htaccess example you will find often looks like this:

AuthUserFile /var/www/.htpasswd
AuthName "My Private Files"
AuthType Basic
<limit GET POST>
require valid-user
</limit>

A rather straightforward example, so what is the problem? This configuration only partially restricts access to the ‘protected’ resource. The issue is in the <limit> tag. This tag restricts access to the resource if the request uses one of the specified HTTP methods, in this case GET and POST. Although these are the most popular methods, they certainly are not the only ones. RFC2616 (HTTP 1.1) lists eight methods: GET, POST, HEAD, OPTIONS, PUT, DELETE, CONNECT and TRACE. RFC2518 (WebDAV) adds a couple more. In other words, if you use one of the other one request methods, you can bypass the authentication. In some cases, using one of those methods will give you the protected page contents. You can also find plenty of examples (yes, the last one is nasa.gov) that don’t even limit GET and POST, but just GET, meaning a simple POST request will bypass authentication completely.

The solution? Simple, do not use the <limit> tag at all. If you omit it, all methods are restricted. If you are in a situation where you want to allow specific request methods, you should use <limitexcept>.

This is certainly not a new issue, it was documented in Apacheweek magazine in 1997. You can also find Bugtraq posts detailing instances of the issue, for example this one which describes an application that restricts only the GET method. If you want more details on this issue, Kernelpanik released a paper about it in 2004, you can find it here (pdf).

No comments: