Web Vulnerabilities

One primary area of network security involves the use of a public Web server. Web security includes client-side vulnerabilities presented by ActiveX or JavaScript code running within the client's browser, server-side vulnerabilities, such as CGI scripting exploits as well as buffer overflows used to run undesirable code on the server, and other forms of Web- related security vulnerabilities, such as those involving the transfer of cookies or unsigned applets.

Although this section focuses on Web-based vulnerabilities, it should be noted that many of these vulnerabilities also affect HTML-enabled clients of other types, including many modern email clients .

Java and JavaScript

Many Web sites utilize a scripting language created originally by the Netscape Corporation known as JavaScript. JavaScript code is transferred to the client's browser, where it is interpreted and used to control and manipulate many browser settings. Java, on the other hand, is a server-side compilation language created by Sun Microsystems. We discuss Java and JavaScript in more detail in the following sections.

Java Vulnerabilities

Because Java is a precompiled language, a Java-based mini-program, called an applet , may present many security risks to the client, including those identified in Table 5.1.

Table 5.1. Identified Java Vulnerabilities

Vulnerability	Description
Buffer overflow in the Java Virtual Machine (JVM)	The client-side environment supporting Java applets is referred to as the JVM . Improperly created applets can potentially generate a buffer overflow condition, crashing the client system.
Ability to execute instructions	Early versions of the JVM could be used to issue commands to the client system, allowing the manipulation of the file system and data files at will.
Resource monopolization	Improperly designed Java applets can easily consume all available system resources on the client system. It is possible to create applets that continue running within the JVM even after the applet is closed.
Unexpected redirection	Early JVM versions allowed Java applets to redirect the browser and create connections to other hosts without user interaction.

JavaScript Vulnerabilities

Unlike precompiled Java applets, JavaScript is interpreted within the client's browser environment. Because it must be compiled and executed within the client's environment, JavaScript vulnerabilities must be addressed based on the operating system and browser version used on each client. Although new JavaScript vulnerabilities are regularly discovered , many of the more common ones are identified in Table 5.2.

Table 5.2. Identified JavaScript Vulnerabilities

Vulnerability	Description
File access	JavaScript code may be used on unsecured systems to access any file on the client computer that the current user can access. These files may then be sent elsewhere, manipulated, or deleted.
Cache access	Properly designed JavaScript code can be used to read the URLs within a browser's cache, allowing the code to examine the user's browsing habits, preferences, email settings, site cookies, and information entered in Web forms.
File upload	It is possible to create JavaScript code that will cause access of a Web page to upload files from the client's system without the user's knowledge or input. The name of the file must be known for this to occur.
Email exposure	Early browser versions allowed JavaScript to send emails as if sent by the user.

Remember that Java is a compiled language that can lead to the execution of arbitrary commands or direct manipulation of data, whereas JavaScript is a client-side interpreted language that mainly poses privacy-related vulnerability issues.

ActiveX Controls

Microsoft developed a precompiled application technology that can be embedded in a Web page in the same way as Java applets. This technology is called ActiveX, and its controls share many of the same vulnerabilities present in embedded Java applets.

ActiveX controls may be digitally signed using an Authenticode signature, which is verified by its issuing Certificate Authority (CA). Unlike Java applets, where browser configuration settings control the possible behavior of the applet, ActiveX controls are restricted based on whether they are signed. ActiveX controls do not have restrictions on what forms of action they may enact.

If a user configures her browser to allow the execution of unsigned ActiveX controls, controls from any source performing any action may be enacted by visiting a Web site hosting such a control embedded within an HTML page.

Buffer Overflows

A buffer overflow condition occurs when the data presented to an application or service exceeds the storage space allocation that has been reserved in memory for that application or service. Poor application design might allow the input of 100 characters into a field linked to a variable only capable of holding 50 characters . Basically what happens is that the application doesn't know how to handle the extra data and becomes unstable. Because the overflow portion of the input data must be discarded or otherwise handled by the application, it could create undesirable results. This can be likened to cramming for an exam: If you give your brain more information than it can process, it will shut down! Buffer overflow attacks are often waged against applications such as Microsoft Outlook and against Internet-accessible services such as ToolTalk, Linuxconf, and many types of Web servers.

A buffer overflow could result in the following:

• An overwrite of data or memory storage

• A denial of service due to overloading the input buffer's ability to cope with the additional data

• The originator being allowed to execute arbitrary code, often at a privileged level

The reason buffer overflows are so prevalent throughout so many types of programming is that programmers often assume that presented data will conform to expectations. It is important for developers to plan for attempted or accidental overflows and set up preprocessing restrictions on data input to block this form of attack.

Cookies

To overcome the limitations of a stateful connection when scaled to global Web site deployments, the Netscape Corporation created a technology that uses temporary files stored in the client's browser cache to maintain settings across multiple pages, servers, or sites. These small files are known as cookies , and they may be used to maintain data (such as user settings between visits to the same site on multiple days) or to track user browsing habits (such as those used by sites hosting DoubleClick banner advertisements).

Privacy Issues

Many sites require that browsing clients be configured to accept cookies to store information such as configuration settings or shopping cart data for electronic commerce (e-commerce) sites. Cookies can be used to track information such as the name and IP address of the client system as well as the operating system and browser client being used. Additional information includes the name of the target and previous URLs, along with any specific settings specified within the cookie by the host Web site.

If cookies are accessed across many sites, they may be used to track the user's browsing habits and present the user with targeted advertising or content. Many users feel this is a violation of their privacy.

Session Values

Cookies may also be used to store session settings across multiple, actual connections to a Web server. This is very helpful when connecting to a distributed server farm, where each page access might be handled by a separate physical server, preventing the use of session variables to maintain details from one page to another.

This is very useful in e-commerce sites where a shopping cart application might add items from multiple pages to a growing total invoice before transferring it to a billing application. These cookies are also useful to provide custom user configuration settings on subsequent entries to Web portals whose content is presented in a dynamic manner.

The danger in maintaining session information is that sites may access cookies stored in the browser's cache that may contain details on the user's e-commerce shopping habits. In addition, these cookies may include many user details that could possibly contain sensitive information identifying the user or allowing access to secured sites.

Signed Applets

Java applets are popular for presenting textual, formatting, and graphical elements within Web pages. These small programs operate within the Java Virtual Machine (JVM), encapsulating their operation and limiting access to system resources. Applets may be digitally signed so that the client system can verify their origin and ensure that the applets have not been modified since being signed. If the local security policy allows it, a signed applet may then access resources such as the local file system and system variables.

To digitally sign an applet, a public/private key pair is obtained from a Certificate Authority (CA) such as VeriSign or Thawte. The private key is used to encrypt the hashed value of the applet's code, and the resulting digital signature is included with the applet along with the public key. When a client attempts to execute the signed applet, it uses the public key to decrypt the hashed value and compare this to a calculated hash of the applet to ensure that the code has not been modified. The client can also contact the CA to verify that the key and signature come from the proper origin and remain unchanged. If the signature is validated and the local security policy allows it, the applet can then access additional resources.

It is also possible for a user to configure his browser client to allow the execution of unsigned applets, which can result in the execution of many types of undesired code capable of accessing system resources. System administrators should prevent users from allowing the execution of unsigned applets by default.

Common Gateway Interface (CGI) Vulnerabilities

A server-side interpretation option includes the use of Common Gateway Interface (CGI) script, often written in the Perl language. Because these scripts are interpreted on the server system, generally utilizing user input values, they are highly subject to exploitation in many ways. Most exploits can be grouped into two general categories:

• CGI scripts may leak information about the server.

• CGI scripts used to process user input data may be exploited to execute unwanted commands on the server.

Because CGI scripts are executed on the server, they are particularly susceptible to exploit through user input. These exploits may allow the identification of server-configuration details that might be helpful to later unauthorized access attemptsa process often referred to as profiling .

Because any process that can execute functionality on the server has inherent access rights, improperly formed CGI scripts could be used to execute arbitrary commands on the server, change server-configuration settings, and even create unauthorized user accounts on the server that could later be used to gain greater control over the server. It is vital that an exposed service such as a Web server not run under a privileged account.

Buffer overflow and script abuse will execute in the same context as the Web server. CGI scripts used to present such items as Web site guest books or display counters can use an account that has very little privileges; therefore, it is possible to cause a buffer overflow or to run a script using an account that has very few privileges. To protect the server, you may want to disable scripting of objects marked as safe. Another option is to implement a proxy server along with a content-filtering solution to rid the network of unsafe coding embedded in Web pages.

Some processes constantly run on a system to provide access or monitoring of many types. These processes are called services in the Windows environment and daemons in the Unix environment.

CGI script creation requires many considerations for security, including the following:

• Poorly written CGI scripts may leak information about the server, such as the directory structure and any running applications and daemons.

• Data input should always include a default value and character limitations to avoid buffer overflow exploitation.

• Many standard scripts are installed in default Web server installations. These are in known folder locations and often contain sample code that is not designed for security and may include well-known exploits.

• It is possible for poorly written CGI scripts to pass user input data directly to the shell environment, which could allow a properly formatted input value to execute arbitrary commands on the Web server.

Simple Mail Transport Protocol (SMTP) Relay

Although not specifically a Web-related problem, the possible exploitation of Simple Mail Transport Protocol (SMTP) Relay agents to send large numbers of spam email messages is included in our list of vulnerabilities. This is because many Web servers include a local SMTP service utilized by server-side processes to perform mailto functions needed in the Web site.

The purpose of SMTP Relay is for a SMTP server to accept user connections to deliver email. The email, once received, is then sent or relayed until it reaches the intended recipient. The issue with this is that user connections are not authenticated with the SMTP server. This allows spammers to connect and send thousands of emails using someone else's server, thereby concealing their identity.

Most servers can block connections that are not warranted. SMTP servers that are not configured to check addresses within their domain are called open relays . Having an open-relay SMTP server can present huge consequences. Besides the fact that spammers can send thousands of unsolicited emails through your server, many companies maintain a list of servers from which spam originates. Those companies then refuse to accept mail from these servers. When this occurs, your capability to send mail becomes severely affected. As if this isn't bad enough, you also end up on a spammers' list. To be removed from the list, you have to prove that the open relay has been remedied. After this is done, the repair is tested . If it's satisfactory, you are removed from the list, and only then will your email be able to be sent to its final destination. Sometimes, by the time this occurs, the damage done to the company has become extremely costly. Many companies post addresses on their spammers' lists. The following links are worth looking at to get an idea of the scope of spam-related sites:

• mail-abuse.org

• www.spamprimer.com

• abl.v6net.org

• www.dgraph.com/spammers.html

Because spammers search for unprotected SMTP Relay services running on public serversthese services can be used to resend SMTP messages to obscure their true sourceit is extremely important that the SMTP server is properly secured.