web notes - a blog

Many web applications can be configured through the application. This is extremely valuable, especially for users that don’t have SSH access and don’t want to use FTP. The danger is that in order for web access to work, the web server must have write privileges into the directories. This creates a security risk.

Set the file permissions to 644, and the owner to the account owner, not the web server. This has an added benefit of limiting write privileges for configuration files to people with SSH/FTP access, not just application administration.

Try to set up the web server such that requests for files in compiled or cached template directories are denied for all users. In many cases, this will work, because template files are often included into other files at runtime. In the event that malicious files are placed in the directory, they cannot be served.

Remove the application name and version data from the page source. Suppress the delivery of detailed web server headers. The less information delivered, the better.

Change the admin access URLs from the default or standard names (such as admin), to something else. Delete or rename the installation directory or files. Be sure to use secure passwords.

Always disable directory display, to prevent people from browsing through the file system.

Be sure the server software is up to date, use mod_security (modsecurity.org), keep PHP up-to-date, and especially, the applications. Monitor the access and error logs. Backup the database and filesystem frequently (automate it). Periodically, SSH in to check the filesystem.

Graceful error trapping and display is important, both during development and after deployment. It is also good to have debug control that is manageable through environment variables. One nice solution is to use SetEnv in .htaccess or a .conf file.

Regardless of the trap and display code, be sure to log all errors, so you can resolve them if they occur. Check the error log (usually /etc/httpd/logs/error_log) frequently.

Along those lines, although using isset in Smarty template will not cause an error, if the Smarty variable inside the call is not set, a PHP will be thrown (http://smarty.net/manual/en/language.modifier.default.php). Possible solutions:

• Do nothing - disk space is cheap and the logs get rotated (this is the wrong answer)
• Initialize all Smarty variables for the templates in the PHP (a good answer)
• Use PHP to initialize the template variables within the template, using {php} tags (also a valid approach)
• Use AJAX to populate forms (may be much more difficult and take longer)

The best approach depends on the application architecture, and may vary by template within the application.

It is good to look at the compiled templates to see how they are constructed.

If you are developing code for interpretive languages such as PHP & Perl, consider the use of the scripts carefully.

As a rule, you should strive to write code which evaluates only the code required for execution. Files should be as small as possible. This is especially important for scripts that run frequently or must be fast.

Key areas to check:

• Use of ‘library’ files - large files with a collection of unrelated functions that support several types of scripts. These almsot always require the including files to read code that won’t be executed. Better to break them up by related functionality.
• Common functions should be placed in a single, small, common file. Good components include database connection functions, simple error reporting, and constants.
• Logging levels should be managed through environment variables. This allows adjustments without modifying code.
• OOP architectures should probably be avoided for files that require high speed performance.

This is a very simple translation of a Drupal .info file into an RPM .spec file. It may be useful in identifying methods to assemble complex Drupal installations on dedicated servers or VPSs where the modules can be managed as RPMs. This would not be useful for casual users. It also assumes the modules will not be modified, and requires careful composition of the .info files by contributors.

I had difficulty posting the script in the blog, so the link provided must be used.

To run it, pass the URL of the module to download, for example: ./info2spec.sh http://ftp.drupal.org/files/projects/annotationfield-5.x-1.x-dev.tar.gz

It was tested with the annotationfield module.

Be sure to set up an .rpmmacro file at the account level.

* CAUTION *

• Hasn’t been (and isn’t going to be) tested with an actual RPM build
• Does not (and probably won’t) handle intermodule dependencies or conflicts

A Drupal RPM generator module could scan the modules installed and extract the following information:

• Source file (full URL)
• Requires - the modules required to support each module
• Provides - the name of the service/capability/feature provided by each module
• Conflicts with - modules which cannot be installed with each module

The standard BUILD, SPECS, SOURCE, RPM, SRPM directories can be used for the build process. The Drupal RPM generator would write .spec files to the SPECS directory for each module. .rpmmacros would indicate the target directory, and other common constants.

This allows a development environment to be quickly converted from a .tgz installation to an RPM managed production server.