Definition
All application software contains bugs. From a simple script to an operating system, no software program is capable of flawlessly performing all of its intended functions or able to correctly handle every possible input.

Not surprisingly, software bugs cause applications to behave in unexpected ways. Bugs can interrupt any normal operation or they can go unnoticed for a long time, eventually manifesting themselves as application crashes or other odd responses.

In eBusiness applications, these odd responses are essentially loopholes that may be exploited by an intruder to bypass the logic and flow of the application and break into the system. The consequences of loopholes in eBusiness applications go much further than crashes or �funny� behavior. A hacker can use them to gain access to private customer information (such as credit card numbers and personal financial or medical information), reveal sensitive business data (such as partnerships and trade secrets), deface the company web site, and/or perform numerous other attacks.

Preventing hacker exploitation by making an application resistant to attacks is known as Application security.

Exploiting Application Loopholes
When examining application level security in the eBusiness environment, it is important to recognize that hacking is accommodated by the browser, and therefore takes place within the HTML and URL�s communicated between the browser and web server. Described below are some common examples of how hackers may use this approach to undermine the integrity of an application.

Unexpected input

Modification of fixed data
Several types of data, such as hidden fields and form-field settings, are assumed by the application to be fixed. By changing fixed data before submitting the request the hacker may, for example:

• Buy Any Item For Any Price
  
  Many applications store price-related information in hidden fields. By modifying these hidden fields it is often possible to change the price charged for an item.
  
• Redirecting Application Output
  
  Many applications use hidden variables to store names of output files and recipient addresses. By changing the output file name, an application may be manipulated to write its output to a different file on the server file system. This can be used to clobber files, deface sites and install viruses or malicious software.
  
  Take, for example, an application that allows the user to enter a comment as part of a customer survey. Upon submission, this comment is appended to a collective comments file, which is identified in a hidden field. Changing this hidden field to point to the main page of the site may provide the hacker with the means to modify the home page contents, thus defacing the site.
  
  It may also be possible to reveal internal application information if the application sends the form via email to an internal recipient whose address is stored in a hidden field. By simply changing the recipient address, a hacker can send the form to his own account (along with any application-appended internal information).

Buffer Overflow
The buffer overflow technique involves sending large amounts of data that exceed the quantities expected by the application within a given field. When executed with precision and deliberation, such attempts may cause the application to abandon its normal behavior and begin executing commands on behalf of the attacker. This can be especially dangerous when the application is configured to have root (super user) permissions on the system. In this case, the attacker can operate as the system administrator of the web server and its environment.

Malformed Requests

• Abusing CGIs
  
  It is very common to find CGIs that are implemented using a script language. Since scripts involve runtime evaluation of expressions, it may be possible to modify evaluation results by manipulating variable values.
  
  For example, if a CGI named 'search' contains the statement:
  
  'echo $query', calling 'search?query=*'
  
  calling for it will result in displaying the directory contents. This happens because the interpreter performs variable expansion before filename glob-ing. Consequently, 'echo $query' will be first expanded to 'echo *' (variable expansion) and then filename glob-ing will replace the '*' with the contents of the directory.
  
  Another example is a script called 'user_info' which contains 'eval finger $user'. When called using:
  
  'user_info?user=%3B%0Acat%20/etc/passwd'
  
  this script will print the contents of /etc/passwd - the system password file.
  
• Putting HTML code in text fields
  
  This technique involves replacing a text field with HTML code containing JavaScript. If the content of this field is ever displayed back to the user, it will result in the execution of the JavaScript function on the user�s machine. This JavaScript can be used as an agent to collect valuable information, such as passwords entered by the user via the keyboard, and then returned to the hacker.
  
• Server side includes
  
  This is another use of embedding HTML code in a text field, this time with server-side includes. Server-side includes are directives to the web server that may be used to include the contents of another file in the page. This may enable the hacker to gain access to files that cannot normally be viewed in the web site.
  
  For example, let us assume a hacker created an account with the following server-side include directive as the name:
  
  '<!­­#exec/bin/cat/etc/passwd-->'
  
  When generating an account information page for this account, the application will embed this server-side include directive into the page, and then the web server will execute the command: '/bin/cat /etc/passwd' This will result in embedding /etc/passwd password file inside the HTML page that was suppose to contain the account information. The page will then be transmitted to the hacker.

Out-of-Bounds Data
Many "forms" use selection lists that allow the user to select one value from a pre-defined set. By sending values outside the boundaries of this list � for example sending 11 when the list is 1-10 � the hacker may cause the application to attempt to access data outside an array�s boundaries. This may have similar consequences to buffer overflow.

Poisoned Cookies
A hacker may tamper with a cookie stored on his computer, and send it back to the web site. Since the application does not expect changes to the cookie, it may process the poisoned cookie, with effects similar to those of changing fixed data fields, such as price changes or output redirection.

Omissions and Additions of Parameters
In cases where an application calls a CGI in the following manner:

'/cgi-bin/perl.exe?subscribe.pl',

a request of the form:

'/cgi-bin/perl.exe?&-e+unlink+%3C*%3E'

will invoke a Perl command that removes files from the web server.

For example, normal usage of a CGI that retrieves files from the file system is:

'/cgi-bin/get?/html/customers'.

Another way of using this CGI is:

'/cgi-bin/get?../../../etc/passwd'

to retrieve a listing of the user accounts on the web server.

In most cases, the actual functionality of the eBusiness application is not limited to what is presented on the web site. By using a combination of information gathering and trial & error techniques, a hacker can uncover and exploit hidden functionality. For example, let us examine an application that presents billing details for a specific user. The request is formatted as follows:

'/bin-cgi/retrieve?userid=123&account;=11&sid=823647328'.

The CGI 'retrieve' translates this into an SQL request to retrieve the information from the database:

'SELECT * FROM acct WHERE userid=123 AND account=11'

A simple way to retrieve the entire database may be using:

'/bin-cgi/retrieve?userid=123&account;=11%20OR%201=1&sid=823647328'v

This will produce the SQL expression:

'SELECT * FROM acct WHERE userid=123 AND account=11 OR 1=1'

Which is logically equivalent to: 'SELECT * FROM acct'.

This functionality is not included in the application definition.

• One vendor�s web server treats a set of strings as file type information. Particularly, the suffix �::$DATA� indicates a data file that should be displayed rather than executed. This means that calling: �validate_user.asp:$DATA� will display the content of the CGI �validate_user� rather than executing it. Of course, with access to the source it is much easier for the hacker to find the loopholes within an application.
• A default behavior of another web server was such that sending a message containing the string: '/?PageServices' would provide a directory listing, even if the specific directory was configured to be protected.

Default CGIs
It is common for web servers to bundle debug and sample code in their default installation. One widely used server provided a CGI named �test-cgi�, which could be used to browse the file system. Another included a sample CGI named �showcode.asp� that could list the contents of files. Since these are standard parts of commercial web servers, it is very easy for hackers to gain access to their source and study them in great detail. This was the case with a CGI named �phf� that was bundled with a commercial web server. Source inspection revealed it contained a statement similar to �eval finger $user�, which is discussed above.

Another common hacking technique is to bypass certain stages of an application. For example, an application lets the user log in and execute a transaction in his account: '/cgi-bin/transfer_money?account=�". In many cases, by careful examination of the application a hacker may discover how to generate legal 'transfer_money' requests without going through the login process. The majority of the applications will allow such a legal request without enforcing proper login.

Application Flow Subversion

Another common hacking technique is to bypass certain stages of an application. For example, an application lets the user log in and execute a transaction in his account:

'/cgi-bin/transfer_money?account=�".

In many cases, by careful examination of the application a hacker may discover how to generate legal 'transfer_money' requests without going through the login process. The majority of the applications will allow such a legal request without enforcing proper login.

Using back doors and debug options

Debug Features
During the development of an eBusiness application, it is very common to use auxiliary CGIs for internal use. If accidentally left in the production environment, these CGIs can provide hackers with easy-to-exploit vulnerabilities. For example, an eBusiness store programmer may test a shopping cart mechanism by using a debug CGI to add any item for any price. If not removed by the programmer before the application is placed in a production environment, the CGI can be used by hackers to place real orders with false prices. In many cases, the debug features are actually embedded inside the application code, where they are likely to remain even after the application moves to production.

Back Doors
Back doors can be left inside the application by a corrupt developer, allowing him later to access the application and the ability to direct the application to perform illegal activities. Back doors have been found in many programs. In one particular case, banking software was made to route some of the bank customers' money to a developer�s account.

Directory Listing Files
It is common for web server file systems to contain directory listing files created by backup utilities and various log functions. These can be a valuable source of information for the hacker to learn about the structure of the system, its activities and resources. Further exploration often results in the exposure of files that can contain customer lists, business partners lists, log files with user passwords and other valuable information.

Backup Files
Backup files are the result of continuous application development. Old versions of CGIs are saved, both by the programmer and by the editor backup feature. The subsequent vulnerability involves the names of the backup files:

If, for example, the web server is configured to execute files of type �.pl�, calling �verify_account.pl� will cause the execution of this CGI. However, if the editor has created a backup version of this file under the name: �verify_account.pl~�, the suffix �.pl~� is not recognized by the server, and therefore this file is not executed, but rather sent to the user as is. Again, this will provide the hacker with the source code of the CGI, thus increasing the probability of a successful attack.

Impersonation

Breaking Encryption
Many sites encrypt sensitive information such as user names, passwords and session tokens using algorithms developed in-house. Such algorithms usually do not go through rigorous mathematical inspection making them more susceptible to breaking. Using iterative methods, a hacker can often reverse engineer the encryption algorithm and synthesize tokens at will.

Session Hijacking
Since the HTTP protocol does not have sessions, the application must maintain its own session, if required. This is usually done using tokens stored in a cookie or in the URLs. Many applications utilize unsafe tokens that can be stolen and used by another party for identification purposes. Since the token often provides the user id (or an equivalent), it enables the hacker to assume the rights of another person as long as this token is valid. Stealing the token can be done in any number of ways - such as tapping the communication, reading it from the cookies of history files, installing a Trojan horse on the client browser and so on.

Changing User ID
A very common and simple method used by eBusiness applications to identify a specific user is through a UID parameter submitted to the relevant CGIs. For example:

'/cgi-bin/get_user_info?uid=10001'.

Due to lack of additional protection, often getting other users' information is as simple as ebulleterating on various UIDs. Using this method a hacker may easily produce a list of the company's customer base, including credit cards, email addresses and sensitive personal information.

Summary

This is but a small sample of an infinite number of potential loopholes an eBusiness application must address. Nevertheless, it is enough to demonstrate the diversity and unpredictability of the security faults that an application can possess. It is evident that no part of the application is immune to flaws, starting from the application code, through third party modules, to the web server and finally its configuration.

Classic Approach to Application security

Overview

Attempting to overcome the problems and exploits described above places a tremendous burden on every stage in the development cycle:

• Design -- Designing application functionality with security in mind leads to a more complex application and extends development time. In addition, designing a secured application requires specific expertise as well as expanded resources.
• Implementation -- A more complex design also complicates implementation. Implementing a secured application requires the use of defensive coding, i.e. embedding checks and balances, to make sure an implementation error will not cause a security hazard.
• Testing -- Other than functionality testing, an entirely new category of stress testing needs to be implemented. The application should be placed in hostile environments and attacked with various tests and inputs designed to expose its loopholes.
• Deployment -- Careful attention to detail is crucial in this stage, as the configuration of each component should be checked and verified to disallow any exploit.

Examples

Preparing for unexpected input
Each application has multiple HTML pages associated with it and each can generate several URLs. Each URL that returns to the web server from the browser must be validated in several aspects, including among others: field length, field content and valid character sets.

This implies that each field on the page has been verified upon reentry to the web server. Verification must confirm that its length has not been modified, that the contents are valid and that no data is sent which could have a negative impact on the web servers' execution. In addition, certain fields may be mandatory while others are not and the rules must be coded by the programmer to verify their existence.

It is also necessary to check each returning field and validate that it is allowed to be sent and will not cause damage to the application.

In order to code Application security in an effective manner, a data dictionary must be developed which outlines all fields, length, description, and page relationship. This includes hidden fields as well as visible fields. A code to manage the validation of these fields must accompany each transaction, therefore requiring each page to be individually checked and validated. If the site has 40 pages there will be 40 checks associated with the site which validate the data input. Each page modification in the site subsequently requires modification to the validating CGI program and data dictionary.

Coinciding with the programmatic validation of fields sent to the web server, it is also necessary to validate cookies. Cookies are under the same constraints that fields are when considering validation. Each cookie must have a set of rules associated with it and have page associations that verify the possible combinations allowed upon receipt.

3rd Party Code Hardening
To effectively secure a web site, it becomes necessary to develop the same data validation routines for third party code as done for in-house developed pages. Such a task involves reviewing the source code of the 3rd party program in an attempt to identify any potential problems and making heavy modification to add the appropriate kinds of protection.

Web server related-loopholes

While it is impossible even to check for all problems that may exist at the web server, the known problems should be fixed, such as:

• Open directories need to be closed
• All patches should constantly be applied as they become available
• Dangerous features such as server-side includes should turned off
• Default CGIs should be deleted

All these solutions should be repeatedly applied to all web servers on a routinely basis. Forgetting even one problem on one web server can make all the difference to a hacker.

Constraining Application Flow

Since HTTP is stateless by nature, creating an application with good flow enforcement is a task that usually involves designing and maintaining a database of open sessions. Designing and implementing such a mechanism can turn into a project of its own, requiring handling sessions across multiple servers and other complex issues. Maintaining such a flow also requires eliminating any static pages, as no flow enforcement can be applied to such pages.

Closing Back Doors and Debug Options

This is a task that should be carefully performed prior to each release. For example:

• Remove the auxiliary CGI that allows the execution purchasing transactions while determining the item price.
• Disable all the 'QA accounts' used for testing the application.
• Disable/debug the flag that instructs the CGI to dump its environment variables.

top