In association with heise online

Whitelisting

When creating filter functions, whitelisting (i.e. explicitly accepting) specific characters is always more secure than blacklisting (explicitly rejecting) characters since it is rarely possible to include all possible potential problem values. Whitelisting and blacklisting are useful not just for character sets. When entering the country of origin, for example, you can just as well use a list of countries.

If the data being entered cannot easily be restricted to a reasonable number of permissible values, it is at least advisable to 'escape' them, whereby special characters are stripped of their special function. This must, however, always be performed with an eye to the use intended for the data. Most scripting languages offer special functions for doing this.

PHP provides a whole raft of filter functions. htmlentities() replaces all HTML special characters with their HTML codes, for example, < with <. addslashes() defuses all apostrophes by preceding them with a backslash. mysql_real_escape_string() filters strings in accordance with the requirements of MySQL statements, escapeshellcmd() does the same for Shell commands and their parameters. For more detailed information on secure PHP programming, the "Security" section of the PHP manual is highly recommended [3].

Security problems can often arise in modular web applications when scripts, which are generally intended to be called by other application scripts only, can be started directly by the user - such as the previously mentioned phpBB plugins. Module scripts which are not intended to be executed autonomously should therefore be protected from being called directly. This can be done in PHP, for example, by preceding them with a line such as

defined ('_GLOBAL_VALUE') or die ('Direct call prohibited.');

A PHP script protected in this way can only be started by other scripts which have, for example, performed a

define ('_GLOBAL_VALUE', null);

before calling the module.

For SQL queries it is advisable to switch to 'prepared statements' [6]. This means pre-set SQL expressions containing wildcards. This means that scripts pass to the API SQL commands and the values entered for the wildcards neatly separated. With prepared statements the mixing required for SQL injection is no longer trivial. PHP versions 5 and above support prepared statements via the mysqli extension. Under Perl, they are available using the DBI module.

Root canal treatment

Simply by correctly configuring the scripting environment it is possible to prevent, or at least obstruct, a good proportion of potential attacks. By setting a handful of options and parameters, hazardous functions can be disabled and potential damage limited. It is therefore judicious to develop a web application in a scripting environment with the most stringent possible protection. The principle of minimum privileges applies - the fewer privileges and functions an application requires and receives, the fewer can go pear-shaped.

image 4 [439 x 400 Pixel @ 74,9 KB]
Zoom A typical company webpage subject to XSS attack, injecting Heisec content.

The notes on php.ini list the most important built-in security options in PHP. They can be set in the central configuration file php.ini. Unfortunately not all web applications can cope with every option. If the server provides multiple applications, the compatibility of each option will need to be checked individually. Unfortunately it is rarely simple to agree on a lowest common denominator or to move problem applications to a less restrictive server.

Shared web hosting is hardly to be recommended for secure use of a PHP application. The incompatibility of many PHP applications with tight security settings, which in PHP must be set globally, force most shared hosting operators to adopt an unsafe configuration.

There is a special PHP5 operating mode, which to some extent forces clean programming during script development, which can be script-activated. After calling error_reporting (E_STRICT); the interpreter issues warnings if, for example, uninitialised variables are used.

The scripting language Perl goes even further with its 'taint mode'. To activate taint mode for a script, the option -T is specified in the first line:

#!/usr/bin/perl -T

Simplifying slightly, in taint mode no files from outside of the script can be passed to script sub-processes. The Perl interpreter also considers, for example, all GET and POST variables as 'tainted'. If, for instance, the variable $formular{"eMail"} comes from form data supplied by the user, the program will abort as soon as a value compiled from that data is passed to a shell command call using system().

To some extent, Taint mode compels developers to deal properly with data from outside the application, as there are only two ways of obtaining clean data from tainted variables - by using them as the key in a hash, or by filtering them using a standard expression. Since Perl 5.8, it has been possible to define whether the interpreter should consider a variable to be tainted using the tainted() function in the Scalar::Util module. Further functions of taint mode are comprehensively documented in the perlsec manpage.

Battening down the hatches

An important component of web application security is the security of the server and the network on which it runs. If, for example, an attacker is able to obtain login data for a database server, this is pretty much useless if he is unable to gain access to the server. Access to this kind of back-end system should only be permitted to computers which, like for example the web server, actually require access. Here too, the principle of lowest privileges applies.

image 5 [439 x 400 Pixel @ 87,2 KB]
Zoom Another XSS example, the Daily Mail now carrying Heisec news!

Using application firewalls such as mod_security for the Apache web server [10], it is possible to control what data can be passed to the application at the server level. Certainly this should be seen as a supplementary measure only and is no substitute for proper programming of web applications.

There is no such thing as perfect security. Software developers often work under considerable time and cost pressure and the value of their work is generally measured in terms of rapid development, usability and layout. It is therefore necessary to consider security criteria right from the planning phase. Security specifications should be part of the list of requirements to ensure that they do not get left aside on cost grounds.

In addition, a comprehensive security concept should be developed, especially where personal data is being processed. Planning for fixing vulnerabilities always needs to start before they start to become apparent. One crucial factor for the security of a web application is the time between a security problem being discovered and being remedied. Security is an ongoing process, not a status. (cr)

See also:

Sub-topic: The PHP dilemma
Sub-topic: The most important security options in php.ini

Literature

[1] Phishmarkt: Online demonstration of known XSS vulnerabilities

[2] Advanced SQL injection and protection using prepared statements

[3] The PHP manual

[4] The suEXEC security extension for Apache

[5] Documentation for PHP's safe mode

[6] You can't Bank on Security - heise article on UK bank pages XSS vulnerabilities

Print Version | Permalink: http://h-online.com/-747201
  • Twitter
  • Facebook
  • submit to slashdot
  • StumbleUpon
  • submit to reddit
 


  • July's Community Calendar





The H Open

The H Security

The H Developer

The H Internet Toolkit