Clicky

Blosxom Security Measures

March 2, 2006

There has been a lot of discussion and concern over weblog security on SDF lately. Apparently there have been a few cases of weblogs being exploited to establish phishing sites.

Blosxom is the only weblog software I am familiar with but it seems to me that a vanilla blosxom setup should be more secure than other more complex systems. It consists of a single Perl script with no built-in write functionality. There are only two open() statements and both are for read-only access. Nevertheless, I have a few suggestions for increased security. Specifically, this applies to blosxom 2.0. There is an incomplete alpha version 3 around but I believe development on it has stalled.

  1. Use static rendering.

    This is probably the most foolproof way of securing your weblog but of course the downside is the loss of dynamic rendering. Dynamic rendering is the default mode, where blosxom generates each page on the fly by calling the CGI script. Static rendering allows one to generate all HTML content files from the command line and then the weblog can be managed and navigated like any other plain-HTML website. Basically, if no script is executed, the only potential security holes are those present in the web server software itself.

    See the blosxom website for more about static rendering.

  2. Avoid plugins.

    Vanilla blosxom is rather secure on its own but this may not be the case after you begin to install plugins, especially those that provide any sort of user input functionality. Allowing users to post comments necessarily requires blosxom to write something to the file system. Unfortunately, this leaves open the possibility of unintended uses such as storing a malicious web page on your site. Be selective about which plugins you install.

  3. Rename blosxom.cgi.

    All CGI scripts, not just weblogs, can create security weak points. The problem is that if someone knows you are using a well-known CGI script or weblog package, they may be able to take advantage of any known vulnerabilities it may have. If a blosxom vulnerability becomes known, a Google search for "blosxom.cgi" yields up a lot of potential targets. Simply renaming the script makes your site harder to find and therefore less likely to be exploited. If you rename blosxom.cgi to bar.cgi, you also have to change the value of $url in the header of the script.

  4. Use URL rewriting.

    Even if you rename the CGI script, someone may be able to determine what software it uses by looking at the page URLs. The default page URLs in blosxom look like http://foo.com/cgi-bin/blosxom.cgi/2005/01/01#title. If you rename the script, you will have something like http://foo.com/cgi-bin/bar.cgi/2005/01/01#title instead. This is better but the best case scenario would be to completely hide the fact that the page is being generated by a CGI script in the first place.

    If your host uses Apache with mod_rewrite (SDF does), you can use URLs of the form http://foo.com/weblog/2005/01/01#title and completely mask the name of the CGI script. Below is an example .htaccess file that achieves the desired effect. Place it in your web site's root directory.

    RewriteEngine on
RewriteRule ^weblog/?(.*)$ /cgi-bin/bar.cgi/$1

    Of course, the bar.cgi link will still be valid, but if you also rewrite the links on your site to reflect the new format, there should be no remaining references to the CGI script except in the .htaccess file, which is not accessible from the web, and any outside links which may use the old form.

    To rewrite the internal links, simply change the value of $url in bar.cgi (formerly blosxom.cgi) from http://foo.com/cgi-bin/bar.cgi to http://foo.com/weblog.

  5. Stay informed.

    Although there is no equivalent of a blosxom-security mailing list, there are several sources for information about blosxom that you can check. Hopefully, at least one of these would report any vulnerabilities that might arise, whether in a plugin or in blosxom itself.