Programming: The Heart of Web Security II

July 2, 2005

Let us now consider several points that are essential for our reference architecture:

* php.ini Configuration File
Configuration of the PHP module is carried out using this file. The main configuration items to be taken into account are:
o expose_php = Off
The PHP banner will not display in the server banner.
o display_errors = Off
PHP error messages are not displayed. The least possible information is revealed to the user.
o error_log = /var/log/php
This is the PHP error log file. It allows for improved script monitoring.
o register_globals = Off
This prevents the direct insertion of URL arguments as variables. This necessary element may require the developer to modify the way that arguments are received by scripts.
* httpd.conf Configuration File

The second important point is to make sure not to divulge more information than necessary. To this end, it is important that directories not be accessible in listing mode (in which their contents are viewable). Every site directory, therefore, should include an index file that launches by default whenever a request for directory listing is made. This index file can redirect the user to a default page.

An alternative way to correct this problem, and which affects the server configuration, involves suppressing the Indexes option in the directory configuration options.

Replace:

Options Indexes FollowSymLinks MultiViews
AllowOverride None
Order allow,deny
Allow from all

with:

Options none
Allow Override None
Order allow,deny
Allow from all

Another basic precaution is to ensure that the user is unable to download files to which he or she theoretically does not have access (such as site archives, login/password files, and installation scripts). A common flaw, frequently observed in application audits, allows installation scripts to be downloaded, thereby revealing the database login and password. It is essential on a production server to remove sensitive files from the website tree structure.

2.1.2 Robust Authentication

The Web essentially is an open-access medium, which is what makes it so attractive. But this represents a danger for sites seeking strict confidentiality of user data. Authentication therefore is an essential element of any web application.

There are numerous authentication systems, some more robust than others. Some employ simple concepts, while other, more complex, approaches, may rely on external hardware components, as is the case with token-based solutions.

We will now describe a software authentication mechanism based on a double-cookie approach. This is an advanced application authentication system that, as we shall see, nevertheless contains certain security flaws.

The authentication system relies on a session cookie for each authenticated user and a second cookie that is refreshed with each new request, and which we shall call the state cookie. The objective of this system is to keep a hacker who tries to steal or view the session cookie from accessing a user’s account. Unfortunately, this approach is riddled with all manner of weaknesses.

First of all, in the case of cookie theft, the two cookies generally are stolen at the same time, so that the hacker gains access to the user account as long as the true user does not make a new request. When the user does make such a request, the session in progress is shut down automatically, and both the user and the hacker are disconnected. But this tactic does give the hacker a few moments to retrieve the information he or she wants. The only way to keep this from happening is to associate the user’s IP address with the session. By rejecting all calls from other IP addresses, it is possible to prevent third-party intervention attempts and also to preserve the sessions of legitimate users.

Another flaw sometimes observed in this authentication system arises from the predictability of the static session cookie. Depending on how it is implemented, this system can present major problems if the cookie is not generated in a truly random way.

2.1.3 Script Security
Generally, website script security is based on meticulous verification of arguments that are input by the user. Potential vulnerabilities often involve modification of script arguments so that they execute actions not intended by the programmer. Arguments must, therefore, be verified one by one and execution prevented if an argument appears to have been modified.

One of the best approaches is to build a library. This library should offer verification functions for the different kinds of vulnerabilities that exist. The programmer may invoke these functions as needed for each argument of each script. Such libraries exist and are available on the Internet. They are very easy to build and understand.

Let us look now at the functionality that such a library should support:

2.1.3.1 Cross-Site Scripting
The verification procedures associated with cross-site scripting should be made on every argument that, immediately or ultimately, may be included in a web page. Such arguments include information or data provided by the user, session information such as the login, and information returned on the web page following an error. Certain less-obvious arguments, such as the Header Referrer and session cookies, likewise may contain errors.

This type of verification ought to be performed frequently. Safe tags are database identifiers passed in arguments and, more generally, arguments intended to be compared with stored data.

The purpose of these verifications is to prevent the insertion of JavaScript or VBScript on the server. If you should decide to authorize HTML insertion on the site, you should also filter the functions that are able to execute that code. Otherwise, you should suppress all HTML tag insertions.

JavaScript execution:

Image: http://www.securitydocs.com/images/papers/WP%20Programming-2.png

JavaScript events contained in HTML tags:
onLoad, onMouseOver

String insertion to the site structure:
Image: http://www.securitydocs.com/images/papers/WP%20Programming-3.png

2.1.3.2 File Manipulation
These verification procedures are necessary for all arguments that can be passed using a file manipulation function such as the open and include functions in PHP. Because the associated risks are enormous, it may be wise to create, for example, a function that allows a file manipulation attempt to be isolated. This could incorporate into the argument the directory from which the file must be opened. Any attempt to open the file outside of that directory could thus be prevented.

It is likewise necessary to confirm that operations are carried out in a specific part of the system, as established by the programmer, and thereby prevent modification of other directories or websites.

In the case of files and/or directories:

Path modification: ; .. or ..
Root access: ; / at the start of the string
Prevent unintended directory access
Prevent calls over the Web: http://

2.1.3.3 SQL Insertion
These verification procedures must be carried out for all parameters that might be used to frame a database query. One solution is to escape out all special characters and ensure that query arguments appear within quotation marks. This solution prevents the SQL command interpreter from interpreting special characters as SQL elements.

These are the special characters to be monitored:
‘ ” , ; ( )

Key SQL characters:
FROM LIKE WHERE

2.1.3.4 XML Insertion
Within some application frameworks, the user is able to add XML tags into XML files generated by the application. A filter for user-inserted data is therefore useful to prevent any insertion of XML tags.

2.1.4 Secure Data Recovery
Data is stored in databases in accordance with an entity-relationship diagram which outlines the rights and memberships of the various entities. Each request should be able to certify that the user making the request is authorized to access data. SQL language is designed to perform this sort of verification through set comparison. Recovered data should not rely solely on identifiers passed in script arguments, but should also verify whether the user in fact has the right to access the entities to which the identifiers correspond.

2.2 Linking Security with Development
“An information system’s security is as good as the security of the weakest link in the system.” This statement implies that an information security policy involves global management of all of the elements comprising the system. It is important to ensure the security of every aspect of the site in order to be able to claim optimal security.

Image: http://www.securitydocs.com/images/papers/WP%20Programming-4.png
The first line of defense for a web application is established in the development phase. This means that the programmer should consider any data input by users to be potentially dangerous, and should analyze each kind of input and filter for it accordingly. This also means that the programmer should be familiar with the circumvention techniques used by hackers in order to guard against them.

Today, web applications still represent a young technology, in full sway but whose potential is still far from fully exploited. It is difficult to bring together the necessary development and security expertise, and many of the applications, scripts and libraries that have been written and are being written neglect certain indispensable elements of verification and security.

Intelliwall is a web firewall designed to detect and intercept application attacks using a learning-based artificial intelligence engine: the neural network. Intelliwall distinguishes between normal and malicious traffic. Located upstream from web servers, it constitutes an effective external defense against all attempts to manipulate web applications to perform tasks other than those for which they were written. It addresses the security flaws inherent in all web application development and alerts the developer to code vulnerabilities.

3 About Bee Ware

Bee Ware SAS is a software publishing company in France with a capitalization of 37,000 Euros. Founded by Nicolas DIRAND and Christophe GUYARD, BeeWare’s technical and commercial teams offer information security solutions for the protection of Web sites (Internet, intranet and extranet) from application attacks.

Image: http://www.securitydocs.com/images/papers/WP%20Programming-5.png

Based in France at Aix-en-Provence and Paris, and in Belgium at Bruxelles, Bee Ware serves the European market with the support of a network of partners.

Contact:
Bee Ware SAS
Company headquarters: 14, Impasse Carnot, F–92 240 MALAKOFF
Tel.: +33 (0)1 49 65 68 40 Fax. : +33 (0) 1 49 65 41 52
R&D: 19, Parc du Golf, F-13 793 Aix-Les Milles cedex
International Sales : 17 rue du nom de Jesus, 1000 Bruxelles, Belgium
Tel : + 32 2 219 87 68
E-mail: contact@bee-ware.net
Internet site: www.bee-ware.net
www.intelliwall.com

Copyright Bee Ware SAS, 2004. All rights reserved.
Copyright and intellectual property rights of this white paper belong to Bee Ware SAS. Copying, duplication, sale or use of this document without prior permission from Bee Ware SAS is strictly prohibited.
This product is based on a software solution developed by Bee Ware SAS.
All trademarks cited in this document are the property of their publishers.

October 2004 Edition
Version 1.0

Posted in WhitePapers