An outline of key test areas to identify security issues in a web application and provide measures to minimize them.
Web sites are moving away from static HTML to dynamic interactive web applications. It is the dynamic, interactive web application that is making the Internet the universal medium. Web applications bring a new level of risk to web sites. Security of these web applications is paramount to the security of the site.
Awareness of security threats from the Internet is increasing the adoption of secure technologies. Deploying firewalls is a standard first step adopted by many organizations. Firewalls protect against many attacks on the network and system infrastructure. In addition, some firewalls provide filtering capability and contain inbound malicious Java and Active-X applications. However, firewalls do little to protect against inbound malicious requests to legitimate applications. Web-based applications are very popular due to the ubiquity of the Internet. Providing access to customer information, user profiles, financial records and health records are common examples of services that web applications can provide. Most often, these applications access a back-end database to serve dynamically generated content to the users. Applications designed without security in mind may result in loss of data integrity, availability, confidentiality and privacy.
Most web application testing can be classified as static or dynamic. Static testing involves manually inspecting the source code and automatically testing for dangerous constructs. On the other hand, dynamic testing involves executing the web application to detect anomalous behavior on unexpected inputs. The focus of this article is on dynamic testing.
Some information seekers think maliciously. Hackers are sometimes able to anticipate inadequacies and the coding practices adopted by programmers. Often, the “speed to market” attitude pushes application developers to overlook standard and secure coding practices. This is especially true in the e-commerce environment, where standard practices such as Change Management are often overlooked. Security is thus usually an afterthought. Often, this results in a vulnerable first release of an application. The process of fixing the vulnerabilities is a fairly expensive one.
Code templates and examples in different development environments provide developers with an approach to implement the desired functionality. These code snippets may not, however, account for application security. The malicious user is sometimes able to identify the development environment just by viewing the HTML code generated by a web application. Comments and some HTML tags can provide information on the development environment. Upon identifying the development environment, a malicious user is able to exploit vulnerabilities where the example or template may have been used.
Another common area for exploitation is the way the application maintains session state information. The HyperText Transport Protocol (HTTP) by itself is stateless. Cookies are commonly used to maintain state information between subsequent HTTP requests. Cookies are simply sets of strings written to the browser by the web application server. They are used to maintain session state, remember passwords and user names, for personalization and configuration features. A malicious user could hijack applications that do not implement strong session controls.
Application vulnerabilities are important because they give access to confidential information such as credit card numbers, account numbers or names and customer lists, without having to break into the web server. The difference between a malicious user and a regular user is intent.
In a recent incident that stunned the on-line community, a hacker posted up to 25,000 stolen credit-card numbers on a public web site (see Resources). These numbers were stolen from the CD Universe web site. The hacker claims to be in possession of more than 300,000 credit card numbers from this site. Further, the hacker claimed that the credit card numbers were compromised due to a flaw in the software used to process credit card transactions. Are you at risk? It depends. You may be at risk if:
You are a large corporation that attracts many users to your corporate web site.
You have just released a statement boasting about the security of your site.
You are completing and releasing a new product in the marketplace.
You are a financial institution.
You are a government organization.
You are a provider of many knowledge-related or data services.
You are an e-commerce site.
If you do not fit any of the above categories, you may still be vulnerable. In the event of a compromise, only your organization's data classification policy and the value of the data lost will determine the extent of the damage. Just last year, the numbers of web site defacements rose over 900% (see Resources). This can result in embarrassment and unnecessary media exposure. Some publicly traded companies have seen their stock value go down as a result of a breach in the security of their web site.
Now we know in theory how a malicious user thinks. We also have some idea about who may be at risk. The remainder of this article will focus on security issues and measures that can be implemented by web site developers in protecting an organization's assets. This is important because the web site administrators cannot easily enforce the client-side security measures. What follows is a list and description of security-related exposures.
A cookie is a small piece of data which is sent from a web server to a web browser when that browser visits the server's site. The cookie is stored on the user's machine, but it is not an executable program and cannot do anything to that machine. However, cookies may allow a malicious user to hijack web sessions and view, modify or otherwise exploit the information related to another user's session. A hacker may obtain the cookie by various means, including physical access or network sniffing, as well as guessing the cookie's contents. Next, the hacker can try to impersonate the user by hijacking the user's sessions. This is an especially serious issue with shared workstations, cyber cafés and public kiosk environments.
Sometimes cookies are used to store information such as user host name, password, account ID, session ID and other user profile information. Cookies are often used to maintain session information between the user and his shopping cart. Two types of cookies exist:
Persistent cookies have an expiration date and are stored on a user's hard disk until that date. A persistent cookie can be used to track a user's browsing habits by identifying her whenever she returns to a site.
Non-persistent cookies are stored in the web browser's memory. They last only until the browser is closed and are then destroyed.
If a user is able to capture the cookies by sniffing on the network, or by any other means, he may be able to gain unauthorized access to personal information, including credit card number, passwords, user ID and mailing address.
The security measures you can take are:
Use non-persistent cookies instead of persistent cookies.
If you must use persistent cookies, then specify a short duration for the cookie's life. The longer the time until cookie expiration, the larger the risk.
Avoid application features that use persistent cookies to store privacy-related information. Example: “Please check to remember user name and password.”
Use the secure tag, so that the cookie is sent only if a secure channel (https) is being used.
Encrypt the information in the cookies. Some web sites split one cookie into many cookies that are further encrypted.
Very simply, form manipulation involves saving a web site's form and editing it off-line. Many times, this involves adding more entries to pull-down lists or increasing the size of text fields. The intent is usually to cause a buffer overflow on the server. In the past, client-side form validation has been used to offload the performance load from the server. While client-side validation is a good technique from a performance point of view, it is not the preferred solution from a security point of view. Poorly designed web applications may contain hidden fields that contain user IDs, account IDs or other key fields that define user sessions. Again, all this information can be manipulated off-line to gain access to another user's session.
Form manipulation is a simple technique and requires only a knowledge of HTML. Experienced programmers may be able to alter and submit forms by guessing the server-side code used to process the forms.
The following measures should be implemented to improve the security of an application against form manipulation:
Perform referrer checks on the server side. This will ensure that a given form was reached from the page that contains the hyperlink providing access to the form.
Do not rely on the form field-length checks or JavaScript to ensure form input integrity. Perform form input-length checks on the server as well.
Process and validate the form input field values entered by the user for range, expected input (e.g., numeric vs. alphabets), strange characters and any other associations specific to the user.
Do not store critical user information in hidden fields in the form.
Sometimes forms are filled out in sequence. This may be necessary because the information provided in one form is used to take the user to the next form in the web application. Additionally, the entire web application may be divided into multiple forms for ease of use.
Malicious users may be able to bypass the intermediate forms by typing out the entire form name in the browser URL field instead of using the navigation controls provided by the web site pages. This may result in unexpected application behavior, accessing a defunct application, incomplete database records or buffer overflow.
Security measures you can take are:
Ensure the user progresses to the next form only after all the required information requested in the preceding forms is provided. Furthermore, ensure the user visited all preceding forms.
Perform referrer checks on the server side. This will ensure a given form was reached from the page that contains the hyperlink providing access to the form.
Many times, form fields are used to send input provided by users to the back end web site for further processing. For example, a user may input their user ID or full name to list information pertaining to their user account. Once the web server receives this information, it will issue a query to a relational database. The results of the query are displayed to the user.
A malicious user may input field entries in such a way that the returned result provides additional information about other users as well. In addition, the embedded queries may run other SQL commands, such as pipe commands, which may result in disclosure of confidential information.
Security measures you can take are:
The web application must carefully examine the input fields used to create the database queries for illegal characters, for example an asterisk (*).
Validate and ensure that input fields contain only the relevant user-related information.
Ensure proper permissions exist on the database objects accessed by the web application.
Many site administrators feel secure simply because the site is using SSL for all its sessions. SSL provides for data transmission security between the web client and the web server. Once an SSL session is established, all information exchanged between the web server and the web client is encrypted. The session timeout specifies the “no activity” duration beyond which the user will have to re-authenticate himself to the web site. The session timeout is usually based on the type of application. Serious financial institutions may specify a very short session timeout period. Regular applications, such as web-based e-mail, may use longer timeout periods.
A malicious user may be able to hijack another user's session if session timeouts are too long. The implications of this are widespread, ranging from embarrassment to loss of confidentiality and integrity of user information. This is a major issue in kiosk, cyber café, laboratory and shared workstation environments.
Your security measure is to evaluate carefully the session timeouts for your application. If you are using multiple application servers, then ensure the session timeouts for the multiple applications are consistent with the timeouts determined for the entire web site.
Most servers are configured with automatic directory listing. This means any directory that does not contain any of the default files (for example, index.htm or default.htm) served by the server will display the contents of the directory. This is dangerous for directories where CGI program sources or executables reside. Further, these directories may contain other files (for example, files with the ~ prefix or the .bak suffix) that may provide more information on the web-site application.
Malicious users may be able to browse the directories and download key files. Files that contain source code may be examined to identify trap doors to gain access into the web server or applications.
The security measures you can take are:
Configure the web server to specify all default files that may be used and to disable directory browsing.
Establish proper procedures when adding the web-application files.
Ensure that unnecessary files are periodically removed.
Dynamic content on web sites will continue to enhance the business functionality of web sites; it is supported by a growing number of e-commerce sites. Also, these web applications are increasingly connected to databases that were previously accessible only through internally built custom applications. Malicious individuals can exploit these web-based applications to gain access to privileged information. Several simple methods, such as cookie poisoning and forms manipulation, can be used to exploit poorly designed web applications; most often, just a text editor and a browser are sufficient. The tools used to execute the exploits are easily available and require minimal knowledge. The very same tools and methods may be used to test the robustness of web applications.
An exhaustive testing of web applications will require building test scenarios to identify vulnerabilities. Proper web-application designs, web-server configuration, secure programming practices and good housekeeping are necessary for the security of any web site and a site's privileged resources. Due to the custom nature of web applications, they pose a challenge to the security of web sites. In the future, web applications are expected to be more secure, as certified components used to build applications gain support. For now, we will have to rely on both static and dynamic testing of web applications.