Problems and solutions - The H Security: News and Features

In association with heise online

Problem cases

A php.ini containing a lot of restrictions can present problems. If, for example, allow_url_fopen = off is set, this prevents forum systems like phpBB from loading avatars from external servers. Therefore, extensive testing with the temporary setting of display_errors = on is vital. In case of disruption or unacceptable functional restrictions, security settings in the respective php.ini need to be relaxed. If the error messages don't give any clues about the cause of the problem, experimenting with individual options is the only way forward.

[bild3]

With some modern PHP applications, however, the installation routine itself offers advice about possible problems resulting from over- or underspecified security. The version 3 of phpBB, for example, tests for several PHP security options during initial setup and offers advice on them. The Joomla content management system, on the other hand, issues unequivocal warnings about unsafe server configurations, for example register_globals = on.

[bild4]

Less is more

In shared web hosting environments, files containing access data and passwords deserve special attention. Most web applications with a MySQL backend store their database passwords in the web directory in plain text. In Wordpress, for example, this file is called wp-config.php, and in phpBB it's called config.php. Ideally, these files should only be accessible to the owner, which can easily be achieved using file permission settings available from within most FTP programs.

However, the web packages of providers all-inkl and Server4u require all users to have read privileges for both PHP and include files. When the privileges are missing, the server issues an error message or sends empty documents to the web browser. Although we were unable to access other users' web homes and retrieve their database passwords with either of the two providers, setting unrestricted read access for these files does leave a bad taste in the mouth.

[bild5]

Those who want to be extra careful can remove write access from php.ini files as well as from the directories which contain them, and use disabled_functions to prevent PHP scripts from meddling with the access privileges via chmod(). A malicious PHP programme can then no longer inject specially crafted values into these files or delete them, thereby bypassing security measures.

However, write privileges will need to be temporarily reinstated to carry out updates, for example. This job is very time-consuming and error-prone and the strategy is, therefore, usually more trouble than it is worth. When chmod() is deactivated, systems like Wordpress will complain that they can't adjust the access privileges of files and upload directories automatically, which generates yet more manual work for the admin.

End in sight?

Even the user-side mechanisms we've discussed can't protect against every attack. In particular, they don't eliminate the web space user's responsibility for keeping on top of the latest security fixes for the installed PHP applications and regular updates. When sloppily programmed PHP scripts pass user input to an SQL database without the necessary filtering, attackers or their malware can manipulate application data despite all the security measures taken.

In addition, allow_url_fopen = off may be bypassed using streams ("php://input" and "data://"). This can so far only be prevented by deploying the Suhosin PHP extension. Once attackers manage to retrieve the database password they may be able to read files outside the open_basedir root via the MySQL server. It should also be noted that PHP restrictions do not apply to external programmes and other scripting languages.

However, even taking the few steps presented here can remove a web application from the front line of the daily onslaught of thousands of web attacks. Nearly all malicious access attempts are carried out by automated bot programmes, which mainly target the standard configuration, and which very rarely attempt to bypass special security measures. Even without elaborate tricks, internet villains and their mass exploits find plenty of vulnerable web applications to abuse for their own purposes.

The following table presents an overview of the PHP configuration of some commercial web space packages and of a stringently configured individual root server. (cr)