Programming: The Heart of Web Security

{LANG_NAVORIGIN} Web Security
By: Johan Brissaud, 01/05/2005



1 The Vulnerability of Web Applications

Information and data transmission system security holds a place of ever-growing importance in today’s world. The expansion of the Web has provided businesses with an ideal platform for introducing and promoting their products and services.

The Web is accessible to all, being both easy to use and widespread. It frequently supplies the responsiveness necessary in today’s business environment. The emergence of portal sites, which bring together professionals in a given sector or industry, provides an essential tool for decision- making and communication among partners.

But to the extent that companies conduct their strategic activities (communication, promotion, commercialization, organization) on the Internet, they expose their actions, and the risks of being hacked become significant. The range of possibilities open to hackers is expanding to the point that certain business fundamentals, in particular confidentiality and integrity, are being challenged.

Let us now review the reasons why such security problems have arisen, the stakes involved, and some examples of possible security flaws.

1.1 Why Are There Web Security Flaws?
Web security flaws may be caused by server configuration problems, poor design, and/or poor programming of web site scripts.

The Web as we know it today is quite recent. The probability of programming errors has expanded with the profusion of programming languages and with the growing functional demands for commercial websites that are rich in content and constantly seeking to add variety and new services. Moreover, the pace of new development in this medium shows no signs of slowing. Companies must be quick to recruit information specialists, often with the result that they hire personnel who have little experience, and even less knowledge, of security problems.

In fact, few professionals today have both development competence and security expertise.

A host of factors accounts for the frequency with which security flaws are encountered.

1.2 The Stakes and the Risks
Many different types of flaws may be found on a website, and they are equally diverse in terms of the dangers that they represent. But all of them merit attention, because each can contribute to major problems.

Let us now turn to a review of the various types of security flaws, ranging from the least to the most severe:

Flaws that reveal information
Such flaws constitute the least of the problems that one might encounter, but their consequences can become extremely serious. An error of this type returns more information to the hacker than is appropriate. The hacker then uses that information as a basis to discover other, potentially more severe, problems.

Flaws of this type include directory displays (within an error returned on a page, for example), and errors returned by a script (which help the hacker to understand how the targeted script functions).

This category also includes certain Web server configuration errors, such as access to certain site directory listings (which reveal a great deal of information and which also allow sensitive files to be downloaded directly).

Flaws in Site Functionality
These flaws, which are by nature very serious, place web site functionality at risk. A hacker exploiting them can direct an application to his or her advantage. The seriousness of such flaws depends basically on the nature of the site. The risk to a simple Internet storefront may not be great, and frequently is limited to website defacement. But a very rich application may suffer more severe and varied consequences, such as access to the business’s customer files, espionage by competitors and prospective clients, and taking of unfair competitive advantage.

Many types of security problems can give rise to this type of risk. These include insertion of JavaScript, PHP or VBScript code into the website (thus allowing actions unintended by the site designers to be executed against other clients of the site), problems related to authentication (affecting the privacy of site users, with all of the legal ramifications that one can imagine) and retrieval of theoretically inaccessible information (as a result, for example, of SQL injection).

Flaws that Place the Website Host Server at Risk
These flaws can have the most profound consequences. In effect, a hacker who succeeds in taking control of a server that hosts a site has an unlimited field of action, being able to modify the site, access any confidential information desired, and use the server as a base for other illegal actions. Flaws that grant access to all of the server files (or to many of them) or which allow commands to be executed on the server can lead rapidly to such consequences.

1.3 Potential Application Flaws
The nature of flaws that can be hidden in a web application depends basically on the languages, development techniques and external programs employed on the site. Web applications can quickly become very complex and very diverse, both in terms of functionality and the components deployed. It would be a long, tedious, and ultimately impossible task to attempt to list all of the potential flaws associated with each of the languages and components in use today.

In order to represent current reality as close as possible, we will focus on analyzing the vulnerability of websites that are based on an archiin common use today. The analysis and proposed measures presented in the remainder of this paper assume these basic and primary characteristics.



1.3.1 Error Searching and Configuration Flaws
Problems with Website Configuration and Structure
Web server configuration problems frequently give rise to other vulnerabilities. An essential first step for a minimal first level of security, then, is to define an optimal configuration that limits the possibilities for external manipulation.

Classic configuration and structural problems include allowing certain directory listings to be obtained (and, therefore, certain files to be downloaded) and allowing archives and documentation to be accessed directly on the site.

Certain flaws can allow even more extensive access, to the point that files on the site can be created and deleted.

Poor Authentication Strategy
Problems can arise from a poorly designed authentication system that allows, for example, both unregistered and registered persons to be authenticated. This is the most common kind of problem, due to the fact that client passwords can be guessed and because applications may have default passwords. In some cases, cookie manipulation can also produce results of this nature.

A similar, but greater, danger lies in the possibility that, once authenticated, a legitimate but malicious client may be able to make the server believe that it is a different legitimate client, and thereby gain access to information relating to other registered accounts.

1.3.2 Strategies for Attacking Applications
Code Insertion
Code insertion is a major strategy for attacking websites today. The principle is to insert external source code into a database or into other files on the targeted site. In this way, the hacker is able to reprogram a part of the website and cause clients of the site, or of the host server, to experience actions unintended in the original site design. The consequences of this type of flaw vary a great deal, depending basically on the type of programming language inserted into the site. Within the framework of the reference web server that we have defined, three types of insertion are possible:

• Insertion of JavaScript Code JavaScript is a language interpreted by the browser of the client accessing an application. This language provides few opportunities to hackers, but it does allow access to certain types of sensitive information, such as the client’s authentication ID’s, which could permit a hacker to access an application by appearing to be the client.
• Insertion of PHP Code PHP is a language interpreted by the server hosting the application. Given that PHP language presents nearly infinite possibilities, an insertion of this type irremediably compromises the server and, thus, the application.
• Insertion of XML Code XML code is used to format certain types of data. An XML insertion allows the data display seized by the hacker to be hijacked, and can also lead to numerous other illicit activities.

Opening of Files and Execution of Commands
To exploit this kind of flaw, the hacker modifies the arguments of certain PHP-specific functions, forcing the script to invoke actions that were not intended by the programmer.

The functions affected by this problem are mainly those related to file opening and inclusion, which can be hijacked to give the hacker access to files present on the server hosting the application (files containing script sources, configuration files, logs, password files, etc.).

Moreover, the include function authorizes inclusion of PHP code in a script. It also permits remote inclusion, meaning the ability to call, via the Web, web functions that are coded and located elsewhere. This makes it possible to execute external PHP code on the server, which seriously compromises the server’s security.

SQL Insertion
SQL is a language that allows databases to be queried by external elements. When a website script performs an SQL query, arguments supplied by the user are inserted. The user can try to modify these arguments, reprogramming the SQL query to access data that theoretically is prohibited.

With the widespread use of databases, and above all the ease of designing and integrating them using languages such as PHP and MySQL, this technique has become increasingly widespread and is at the heart of site hacking.

Email Relay
Enabling a web server to direct email is a technique that can be used for malicious purposes. If the user is able to designate the destination address, as is the case with many web applications, he or she can use this functionality to spam (send anonymous promotional email) or to unleash a Denial of Service (DoS) attack, which operates by overloading the mailbox. The hacker can also use this technique to gain the confidence of other users (by passing as the site administrator, for example).


2 Solutions for Increased Security

Having examined the various security problems that can or do affect applications, let us now consider the techniques and essential precautionary measures that must be taken to guarantee users an optimal level of privacy. This is a holistic response aimed at protecting the interests of the business in several respects:

• Availability of systems and applications
• Protection of critical data and client information
• Confidentiality of application source code

2.1 A Step-by-Step Response
An authentication system, even a very elaborate one, will not provide much protection to user data if it is possible to access the entire base of user accounts because of a structural flaw in the way that the application and the database work together.

Even the slightest details are important. A security problem, even a slight one, can give rise to other flaws that are very serious. It is therefore essential to assure a sufficient level of security across all of the layers and components of the web application.

2.1.1 Web Server Security
Before all else, web server security begins with an examination of the configuration file. The server configuration file allows user rights to be delimited and the manner in which they function to be defined. It is necessary to find the optimal configuration that allows the application to function without compromising rights or supplementary services Add-on modules (which provide functionality that is supplementary to the server) may have their own configuration files that also need to be optimized.

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:
  • expose_php = Off
    The PHP banner will not display in the server banner.
  • display_errors = Off
    PHP error messages are not displayed. The least possible information is revealed to the user.
  • error_log = /var/log/php
    This is the PHP error log file. It allows for improved script monitoring.
  • 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:
       <Directory “directory to be protected">
         Options Indexes FollowSymLinks MultiViews
         AllowOverride None
         Order allow,deny
         Allow from all
       </Directory>

with:
       <Directory "directory to be protected">
         Options none
         Allow Override None
         Order allow,deny
         Allow from all
       </Directory>

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:



JavaScript events contained in HTML tags:
       onLoad, onMouseOver

String insertion to the site structure:



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.



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.



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















Your IP address will be sent with this e-mail

From e-mail to e-mail