Security of your PodHawk site
From podhawk
Contents |
Introduction
PodHawk 1.5 and later versions contain a number of important security improvements, as described below. Most of these features work automatically and unobtrusively. The only points which require your action are:
- set a strong password
- set a login name which is different from your screen name
- turn off error reporting
- consider moving your configuration file so that it cannot be accessed from the web
- for PodHawk 1.7 and later versions, add your ftp details in the backend settings page so that PodHawk can run without any "world writeable" (0777) directories.
A secure password is vital
Security features are useless if a hacker can guess your login name and password. PodHawk allows you to set a login name which is different from the screen name ('nickname') which appears on your web page. Please use this feature. Please also use a password which contains both letters and numbers and which is not a dictionary word. There are several online password checkers which will tell you how strong your password is.
PodHawk 1.5 sends your password in plain text to the server only once, when you first set up your site. After that, it uses an encrypted handshake procedure.
Database security
PodHawk 1.5 checks and 'escapes' all user-generated input before sending it to your database. This is to help prevent sql-injection attacks.
In addition, when you run the PodHawk 1.5 install programme:
- PodHawk creates a random prefix for your database tables. Instead of having names like 'lb_settings', they will have names like '9dGT4_lb_settings'. This makes it difficult for an attacker to know the names of your database tables. This is, of course, obfuscation rather than security, but obfuscation can be useful!
- PodHawk attempts to create a second database user to run the public web-pages of your site. This user has only the privileges needed for this purpose. An sql injection attack via, for example, a posted comment is likely to fail because the web-page database user will not have the privileges needed to execute the malicious code. More information here.
Your configuration file (config.php) contains information about how to connect to your database. It is important to protect it from hackers. PodHawk 1.5 allows you to locate the configuration file above the root of your web site, where it is inaccessible from the web. Further information here.
Podhawk 1.5 uses the Blowfish encryption algorithm to encrypt your FTP username and password in the settings database table. You need to have a Blowfish key in your configuration file. PodHawk 1.5 creates this automatically when you run the install programme. If you are upgrading from an earlier version of PodHawk you will need to add the key to the configuration file manually - more details here.
Web site security
To combat cross-site scripting attacks, PodHawk removes all html tags from user comments before inserting them in the database or displaying them on the web page.
PodHawk needs to write data into a number of directories in your PodHawk site (eg the audio directory). The normal way to permit this is to change the "permissions" on the directories concerned to "0777" so that they are "world-writeable". There are security risks in doing this however. In addition, PodHawk 1.7 and later versions have an 'FTP layer' which allows PodHawk to run without any "world writeable" directories You need to add your ftp username, password etc in the backend settings page. Details here.
Error messages (there shouldn't be any on a well-behaved PodHawk site, but accidents can happen!) can give a hacker important information about your site. Turn error messages off in the admin settings page.
Security of your admin pages
PodHawk 1.5 contains completely new arrangements for cookies and sessions. Cookie and session information is now stored in the database, and not in the cookie itself, or in the (frequently insecure) default location for session data. Cookies are regenerated with a new id each time they are used. Sessions are regenerated on successful login to counter possible session fixation attacks. Sessions expire after 20 minutes of inactivity (ie 20 minutes in which you do not click 'save' or ask for a new admin page.) If you receive an error message 'I could not find a valid authorisation key - POSSIBLE HACK ATTEMPT!' the probable reason is that your session has expired. Unfortunately, you will lose any changes which you wished to make. The solution, if for example you are composing a new post, is to save your work from time to time, so that you do not exceed the 20 minute limit. Session cookies and persistent cookies are rejected if the user-agent string of the browser sending them does not match the user-agent string recorded in the database.
PodHawk 1.5 places an authorisation code on most of your backend pages, and checks this code whenever you try to make changes to settings, postings, authors etc. The code is regenerated for each session. This ensures that all requests for changes come from one of your admin pages, and not from somewhere else (cross site request forgery). This feature also makes it impossible to log in to your admin pages except from the proper login page. Podhawk 1.5 delays for several seconds before sending a "wrong username or password" message, in order to limit the speed of any brute-force attack.
Disabling security features
I have tested all the new PodHawk 1.5 security features on my own PodHawk site and they run well and unobtrusively. If any of them cause unexpected problems, however, several of them can be disabled. Open the file podhawk/initialise.php and find the section headed "User Definable Constants" which contains more detailed information.
