web notes - a blog

The link above is a link to Secunia, which tracks security issues for many products.

Interpreting the data is definitely subjective, for the following reasons:

• If an application is constantly being tested and reviewed for security issues, problems will be found more quickly.
• Applications with reports of many issues may simply be tested better than others.
• Applications which are very popular will also have a greater presence, as this implies greater testing.
• Development teams that are very concientious and report issues frequently will cause a greater quantity of reports than more reserved teams.
• Development teams that refrain from reporting security issues may consider that a valid approach, by reducing the information available for malicious users.
• Some applications have fundamental issues that make them more vulnerable than others.

After reviewing the reports for an application, there are several courses of action.

• Check if the application has been compromised on your server. Immediately apply any recommended upgrades or patches.
• Review the application documentation and the site/forum for additional tips on securing the application.
• Review any appropriate server security practices.
• Determine the value of any data or content involved, with an eye toward the cost of replacement or porting to a different application. Be sure to include the cost of training, learning curve (both for users and developers), administration issues, etc.
• Consider a web application firewall such as mod_security (http://modsecurity.org).
• If you have sensitive data or ecommerce, consider a hosted solution.
• Repeat

An application that can power multiple sites can greatly reduce maintenance.

Allowing users to run regular expression (REGEXP) searches through a web interface provides excellent search capabilities with very little engineering. One need only change WHERE `field`=’value’ to WHERE `field` REGEXP ‘regex’.

A problem arises if the regex entered is invalid. MySQL will report an error.

One solution that works well is to wrap the mysql_query string in a function or class method. Then, when testing for an error, check (use stristr) to see if the error was a regex error. Regex errors should be handled as user errors, not application errors. They should be logged to allow later analysis (if there are alot of regex errors, help should be provided).

Another approach is to use the PREPARE STATEMENT (see link above). This will throw an error if there are any invalid regexes.

Pay particular attention to the site visitor IP addresses in the web stats.

Any IP address that has a significant amount of requests for unknown reasons should be suspect.

Use the link above, or its overseas equivalent to determine who the IP address belongs to. If you don’t think they should be using your site heavily, use an .htaccess file to block them. Be sure to block the entire block reported by the whois system.

Apache allow,deny directives allow you to block requests: http://httpd.apache.org/docs/2.2/howto/access.html

These requests will show up as Forbidden in the stats later, and should eventually stop, since they aren’t being served.

In addition - if you are seeing alot of unexplained requests, from unknown sources, you should check your server for unauthorized content.

The following steps can be taken to make an existing eZ publish installation run more quickly:

• Empty the trash
• Clear the collected information
• Clear the search stats
• Delete all the drafts, especially those of the administrator

These steps remove unused information from the database and can really help the system run faster.

By default, PHP manages sessions during requests. This simplifies installation, because no cron job is required. To allow performance tuning, several configuration settings are allowed to adjust the frequency of the session cleanup checking and execution.

In the default php.ini, there is the following line:

cd /path/to/sessions; find -cmin +24 | xargs rm

Added as a cron job, this can be executed at set intervals (every one to five minutes is probably good), to clear the session file storage directory of files older than 24 minutes. Once implemented the find command can replace the default PHP session cleanup, so those configuration variables can be set to never check for session timeouts. This will speed PHP processing, although it may be imperceptible. It will also improve your control of session length, because the checking and clearing are executed based on time, not PHP requests.

Name any temporary files required to support the session with the session id, plus an extension to indicate the type and use. For example 4365kh2kj54dfg2kjh12.wav, 4365kh2kj54dfg2kjh12.rpt.txt, 4365kh2kj54dfg2kjh12.rpt.html. This allows a second session cleanup script to check for the presence of the session file based on the temporary file’s basename, and delete the temporary files. The second session cleanup script can be included in the main PHP script, or run as a separate cron job, unless the contents of the temporary files could be considered protected data, in which case they should be removed as soon as the session is terminated.

If authentication (logout) is also used to destroy sessions, a mechanism should be provided to clear any related, sensitive, files.