Lesson 2: Web Security | Security+ Certification Training Kit (Pro-Certification)

Lesson 2: Web Security

As mentioned in Lesson 1, unencrypted communications on the Internet should not be considered safe. Almost anyone with a protocol analyzer and the inclination to use it could compromise unencrypted data exchanges.

Beyond packet sniffing, attackers can utilize several other methods to exploit an organization's network and computers. Often, these attacks focus on application vulnerabilities that are a result of programming errors. Attackers might also trick your users into downloading software that can be used to compromise your organization's systems.

After this lesson, you will be able to

Select appropriate encryption technologies for Web communications
Identify and select corrective action for active content vulnerabilities, buffer overflows, cookie vulnerabilities, and Common Gateway Interface (CGI) program vulnerabilities

Estimated lesson time: 60 minutes

SSL/TLS

The Secure Sockets Layer (SSL) and Transport Layer Security (TLS) protocols were developed to help secure client/server exchanges on the Internet. Most people wouldn't write their credit card number, expiration date, and billing address on a postcard to make a purchase through the mail because they know anyone who saw their postcard could use this information to make fraudulent purchases against their accounts. The same considerations apply to personal or confidential information such as medical records. If you wouldn't want to write something down on a postcard, you probably shouldn't send it across the Internet unencrypted.

In December of 1994, Netscape Communications Corporation released the SSL protocol. SSL is based on the asymmetric PKI encryption methods developed by RSA Corporation. In January 1999, the Internet Engineering Task Force (IETF) established RFC 2246, which documented a new protocol based on SSL version 3 called TLS protocol version 1. SSL and TLS gained wide acceptance in the late 1990s. TLS is different enough that it does not interoperate with SSL, but TLS does include a mechanism that allows it to back down to SSL 3. Today, many different software vendors' products support versions of SSL and TLS.

Because SSL and TLS were derived from the same protocol and supported by many of the same applications, the two protocols are often referred to simultaneously as SSL/TLS.

SSL/TLS provides protection against eavesdropping, tampering, and forgery of communications on the Internet. Clients and servers can authenticate one another over SSL connections and establish an encrypted communications link across the Internet. SSL/TLS is an application-independent layer that works between the Transport and Application Layers of the Transmission Control Protocol/Internet Protocol (TCP/IP) protocol stack, as shown in Figure 6-1. Consequently, any network application that can use TCP/IP can also use SSL/TLS. However, the application must be specifically programmed to include SSL/TLS compatibility.

figure 6-1 ssl/tls in the tcp/ip protocol stack

Figure 6-1. SSL/TLS in the TCP/IP protocol stack

SSL/TLS can provide the following services for client/server applications:

Authentication of the server to the client.
When a customer wants to buy a product from a merchant's Web site, the customer wants to know that he or she is actually communicating with a server owned by that merchant. SSL/TLS allows the customer's computer to verify that the server is indeed the merchant's server (and not a rogue server set up by a thief to steal credit card information). For this to work, the server must have a valid certificate from a certification authority (CA) trusted by the client.
Negotiation of a common cryptographic algorithm or cipher.
The client and the server can negotiate the type of encryption used for the connection. This enables the client and server to agree on an encryption technique that they both support.
Authentication of the client to the server (optional).
When there is a desire to limit access to the server, client computers can be installed with certificates that confirm their identity. Such authentication isn't always desirable or necessary. For example, in most e-commerce transactions, merchants do not verify their customer's identity using SSL/TLS or certificates because many potential customers would not have certificates. Therefore, vendors frequently choose to identify their customers by credit card number, expiration date, and billing address.
Use of asymmetric encryption to transfer shared secrets.
Asymmetric (or public key) encryption is difficult to break, but is also computationally intensive. Symmetric encryption is much more efficient for transferring data. SSL/TLS utilizes asymmetric encryption to transfer a shared secret (symmetric key) so that the actual data encryption is faster, but the method of establishing the encrypted communication is still highly secure.
Establish an encrypted connection.
Finally, and most important, all communication between the client and server is encrypted. SSL/TLS is also protected by a mechanism to detect connection tampering, such as data being altered during transit.

Almost all Internet-based online purchases today are protected by SSL/TLS. SSL/TLS encryption gives consumers, merchants, and financial institutions confidence in the privacy of Internet transactions.

HTTPS

Web communications are conducted using HTTP. Web communications that are secured by SSL/TLS are referred to as HTTPS communications. Client Web browsers often indicate HTTPS connections by showing https:// (instead of http://) in the protocol field of the Web address.

Another less popular method for transmitting data securely over HTTP is Secure HTTP (S-HTTP or S/HTTP), which is documented in RFC 2660. Most vendors do not implement support for S/HTTP in their products.

Although HTTPS encrypts communication between the client and server, it doesn't guarantee that the merchant is trustworthy or that the merchant's server is secure. SSL/TLS is designed to positively identify the merchant's server and encrypt communication between the client and server. SSL/TLS cannot stop the merchant from doing something unethical with the credit card information once it is collected. SSL/TLS does not protect information stored on the merchant's server. Unfortunately, many merchants' Web servers have been compromised (and customer credit card information has been stolen). Consequently, many merchants do not store credit card information on their servers.

Buffer Overflows

A buffer is a data area that is shared by either hardware devices or program processes. In this section the focus is on program buffers, which allow programs to operate with different priorities. Each buffer has a defined area and boundary.

Buffer overflows occur when a program tries to store more data in the buffer than it was designed to hold. The data that does not fit into the designated buffer can overflow into an adjacent buffer. The overflowed data can overwrite and corrupt valid data of another program. Buffer overflows can be caused by a programming error or a specific attack against an application. An attacker can use a buffer overflow on the target system to exercise some type of control over that system. In an attack, the buffer overflow condition can be used to damage files, change data, acquire confidential information, or execute code on the target computer. The attacker might even be able to gain full control over the target system.

Buffer overflows have been exploited in almost every type of application, including Web applications. Web servers and clients from many different software vendors have been exploited by buffer overflows.

The best defense against buffer overflow attacks is having software developers follow secure coding practices. If you or people in your organization develop programs, these practices should be applied. Applying secure coding practices means designing programs with security in mind. Think about ways in which the application could be compromised or used to compromise another application, device, or the operating system. Some specific best practices for secure code development are as follows:

Run programs as the least privileged account possible. If your application doesn't have to be equivalent to root or administrator, don't make it run as such.
Use safe compilers to help minimize the impact of buffer overflows (for example, Stack Guard).
Design the program to check all user input for validity. If done properly and thoroughly, users won't be able to send invalid or out-of-bound strings that can overflow the buffer to your program.

More specific recommendations for secure code development can be found in software development kits (SDKs). SDKs are programming guides that explain the structures, functions, and methods for developing programs for specific platforms.

The best protection against buffer overflow conditions after a program is released is for the program vendor to produce a security patch. To protect existing systems, security administrators should test and apply all security patches as they are made available.

Active Content

In an effort to make browsing more exciting, functional, and useful, software vendors and Web developers created and enabled active content. Active content materials are small executables or script code that is rendered within the client's Web browser. For example, some banks offer mortgage calculators on their Web sites. These mortgage calculators are considered active content. Two of the most popular types of active content are JavaScript and ActiveX components. Active content (or dynamic content) is designed to run a script on a client system. Unfortunately, with this added capability comes an added security risk: some scripts could be used to perform harmful actions on a client machine.

Active content that is intended to cause harm, but is disguised as something valuable or desirable, is called a Trojan horse. This term is borrowed from the ancient Greek story about the large wooden horse that was presented as a gift to the city of Troy, yet secretly contained an army of Greek soldiers. The Trojan horse was used to get the soldiers inside the city to compromise its defenses. To a computer user, a Trojan horse is a seemingly useful program that when activated performs a malicious or illicit action, such as destroying files.

In this section the focus is on threats to, and protection of, Web clients. In Chapter 8 we provide recommendations for protecting Web servers from script exploits.

Java Applets

Java is a programming language developed by Sun Microsystems that has a number of features that make it well suited for use on the Web. Small self-contained Java programs, called Java applets, can be run on most client Web browsers. For example, Netscape Navigator and many versions of Microsoft's Internet Explorer support Java applets.

Java applets are referenced inside a Web page from an APPLET tag. The tag is used to load Java source code files. The Java source code is run through a client-side engine or Java Virtual Machine (VM). Java VMs exist for most operating systems, including UNIX, Macintosh, and Windows.

The Microsoft Windows XP operating system does not ship with a Java VM, which means it doesn't support Java applets. You need to download a Java VM before you can see Java applets in Windows XP.

Unfortunately, an attacker could use a Java applet to compromise client systems. To protect yourself and your organization from Java applet exploits, you can disable Java support on your system. Most widely used Web browsers (including Netscape and Internet Explorer) allow you to disable Java.

JavaScript

Netscape Corporation created JavaScript, a scripting language that shares many of the same structures and features of Java. However, Java and JavaScript were developed separately and are treated as two independent languages.

Most Web browsers, including Netscape and Internet Explorer, support JavaScript. JavaScript is typically embedded inside a Hypertext Markup Language (HTML) page and read by a client browser. A SCRIPT tag inside HTML coding is used to note the use of JavaScript. JavaScript is commonly used to communicate with other components (such as CGI programs, described later) or to accept user input.

JavaScript can be used to open Java applets. For example, JavaScript and Java applets might be used to create mortgage calculators, interactive maps, surveys, and much more.

An attacker could use JavaScript to compromise client systems. For example, there is a JavaScript exploit for Internet Explorer that can open up a command prompt window on a computer running Windows 2000 or Microsoft Windows Me. Such a script could be used in conjunction with additional code to send commands to the command prompt window that could potentially delete files, download viruses, or cause some other harm.

To protect yourself and your organization from malicious JavaScripts, you can disable JavaScript on your client Web browsers, as shown in Figure 6-2. Although disabling JavaScript can protect you from malicious code, it also disables useful active content. However, you can selectively enable JavaScript when visiting Web sites with useful applets that you trust. If you choose to enable JavaScript, you should keep up with the latest software patches for your client Web browser.

figure 6-2 java and javascript settings in netscape navigator

Figure 6-2. Java and JavaScript settings in Netscape Navigator

ActiveX

As previously mentioned, ActiveX components also provide dynamic content. ActiveX is a Microsoft technology targeted for Internet Explorer. Many versions of Internet Explorer support both ActiveX and JavaScript. Like JavaScript, ActiveX components (or controls) can communicate with other applications, receive user input, and provide useful application services to users. Also like JavaScript, ActiveX controls can be used to exploit a client system.

Internet Explorer is the only browser that currently supports ActiveX. To help protect systems from ActiveX exploits, Internet Explorer allows you to selectively control downloading and running of ActiveX controls, as shown in Figure 6-3. You can configure Internet Explorer to automatically download, prompt you for downloading, or disable the downloading of ActiveX components.

If you allow and use ActiveX controls, you should monitor vendor Web sites and security alert services for information about possible exploits. If you find out that a certain ActiveX control is vulnerable to an exploit, you should consider uninstalling it until a security patch is provided.

figure 6-3 activex settings in internet explorer

Figure 6-3. ActiveX settings in Internet Explorer

For information on how to remove an ActiveX control, see Microsoft Knowledge Base article Q154850, "How to Remove an ActiveX Control in Windows." Use the search feature at http://support.microsoft.com to locate the article by searching for Q154850.

Signing Active Content

In an effort to increase the security of dynamic content, some vendors have implemented processes to check for digital signatures before active content is installed. Active content creators are expected to digitally sign their active content before posting it for download. Content developers can obtain digital certificates for signing their applications from a third-party certificate authority such as Verisign or Thawte. The digital signature helps to ensure that the content is authentic and comes from a trustworthy vendor.

Microsoft employs a technology called Authenticode in Internet Explorer to check for digital signatures before downloading ActiveX components. Sun Microsystems has created a Java plug-in that works in Internet Explorer and Netscape to check for digital signatures before downloading Java applets. Signing active content increases security in several ways, including the following:

Users are notified in a pop-up dialog box that an applet or control is about to be installed.
The digital signature of the component is matched to the service provider, so that clients can verify they are downloading the control from the correct service provider (and not an attacker-modified control that could do terrible things to their systems).
The user is given a chance to cancel the installation of the ActiveX control through a pop-up dialog box.

Although the signed active content increases security in the ways mentioned earlier, it does not protect the user from what the actual component or applet can do or new security holes it might introduce. Therefore, it's important that you keep up with security alerts and security patches from the vendors from which you download active content.

A cookie is a small amount of data that a Web server stores about a user on the user's own computer. For example, a cookie might be used to record different advertisements that a client browser has loaded. This enables the Web server to display different advertisements (instead of showing the same advertisement repeatedly).

Client browsers must allow servers to store cookies on them. Most client browsers do allow this because cookies are so widely used and many sites do not function properly if cookie support is disabled. Cookies are stored in different locations, depending on the Web browser. For example, Netscape stores cookies in a file named Cookies.txt, Opera stores them in a Cookies.dat file, and Internet Explorer stores each cookie as a separate file in the %windir%\Temporary Internet Files directory by default.

Cookies can be used for many different reasons. For example, some cookies are used simply to store user preferences when they connect to a Web site. Other cookies are used to maintain state information (status of the connection between client and server, described in RFC 2965). Some servers also use cookies for client authentication purposes. Unfortunately, cookies can also be used to compromise Web clients and servers in the following ways:

An attacker could use a program such as Telnet to send a client browser any type of cookie the hacker wants. If a Web server relies on the information in the cookie to control access or services, the attacker could potentially formulate a cookie that bypasses that access control.
Cookies can be manipulated or stolen. An attacker can use cookies to acquire inappropriate information about network users, the organization, or the security of the internal network.
Attackers could use script injection (placing a script on the client's computer) to redirect cookies to the attacker's system. Hackers might also just eavesdrop on the connection reading cookies.

To learn more about cookie exploitation and management tools visit the following Web sites: http://www.codeproject.com, http://www.kburra.com, http://www.peacefire.org, and http://www.digizen-security.com.

To protect your organization and clients from cookie exploits consider the following advice:

Do not configure a Web server to rely on information stored in a client's cookie to control access to resources or provide any additional services that could be used to exploit your Web server.
Try not to store sensitive information, such as authentication credentials or bank account codes, in cookies.
If you must store sensitive information in a cookie, use SSL/TLS to protect the information inside the cookie. This should help prevent the information from being intercepted and exploited by an attacker.

CGI

CGI programs are commonly used on Web servers to produce dynamic content. CGI is a specification for transferring information between an application and a Web server. For example, CGIs are frequently used to perform data input, search, and retrieval functions on databases. CGI programs can be written in any programming language or format, such as C, C++, Visual Basic, Fortran, PERL, TCL, UNIX shell script, or AppleScript.

CGI programs can be targets of attack and avenues for exploiting your Web server. Unlike JavaScript or ActiveX controls, which run on client browsers, CGI programs run on the Web server. Just like any other program, a CGI program might contain security holes that allow an attacker to access your network or its systems. CGIs are typically a target for attackers because they are frequently used on public (Internet-facing) Web servers. Here are some exploits an attacker might try against your CGI applications:

Running the CGI program over and over again from multiple Web browsers. Each time a CGI program runs, a new process (executing program) is started. This can tie up the Web server's system resources, causing it to slow down considerably.
Exploiting default CGI programs that ship with Web servers. Many Web server products come with sample programs. If a sample program wasn't written with security in mind, an attacker could use it to exploit your Web server.
Exploiting free or popularly available CGI programs. Attackers often study popular programs for security holes.
Sending bogus data to CGI programs in an attempt to compromise the applications.
Exploiting hidden fields within your CGI programs. Hidden fields are sometimes used to pass data between CGI applications through the client browser. The browser itself never displays the data (hence the name hidden field). However, the client could potentially read the hidden field as it is passed and modify the information as it is returned to the server.
Using server-side includes (SSIs) to compromise scripts. SSIs can allow one document to be inserted into another. In addition, data can be fed into or out of another program if SSI is enabled where programs are stored. Attackers might be able to use SSI to compromise your scripts.

Check The World Wide Web Security FAQ maintained by the World Wide Web Consortium (W3C) at http://www.w3.org/Security/Faq for more information on potential Web server exploits.

For your Web server to be able to run CGI programs, you must allow the Web server read and execute permissions to your CGI directory. Be sure not to allow write permissions to this directory, because an attacker could use that permission to load a malicious CGI program to that directory and run it to compromise your Web server.

To protect your Web server and network from compromise from an attack involving CGI programs, consider implementing the following tips:

Limit the use of CGI programs. CGI programs increase the workload of your Web server, which can cause it to respond slowly. Wherever possible, limit the use of CGI programs.
Limit CGI programs to specific directories. This way you can control security permissions on those directories. Restrict access to those directories by configuring the fewest permissions possible for the fewest user accounts.
Configure CGI programs to run as the least privileged user possible.
Remove all default and sample programs from your Web server.
Check all CGI applications for security holes, especially if they are free or popularly available. Only use CGI applications that are thoroughly tested and quality checked.
Don't trust client applications to submit properly formatted data or the correct amount of data. Attackers might try to transmit bogus data or more data than you expect to exploit your CGI application. The CGI application must check the data returned and reject the data if it is invalid, too long, or improperly formatted.
Don't trust a client-side script (JavaScript, for example) to protect CGI applications from improperly formatted data. If you allow a client-side application to preprocess data for your CGI program, an attacker might find a way around the preprocessor. For instance, the attacker might try sending data directly to the CGI application through another client application like Telnet. Don't trust preprocessing; ensure that the CGI application checks its own received data.
Disable SSI. If your Web server must support SSI, turn them off on your script directories.

For additional tips on securing CGI applications, visit the National Center for Supercomputing Applications (NCSA) Web site at http://hoohoo.ncsa. uiuc.edu and read about writing secure CGI scripts.

Instant Messaging

Instant messaging (IM) is a popular method by which people communicate today. IM allows people to send pop-up messages, files, audio, and video between computers. IM programs are easy to download and install, but many IM applications present a significant security risk to users, networks, and organizations. Common problems with many IM applications include the following:

Unencrypted data transfer. People often send what they consider confidential or private information using IM, such as user names, passwords, or trade secrets. However, many popular IM applications transfer unencrypted data that can be easily collected and read by attackers with protocol analyzers. Msgsnarf (included with dsniff) allows for the interception of IM messages.
Transferred files might bypass virus scanners. Many IM applications allow users to transfer files directly. This often prevents virus scanners configured on the e-mail gateway from detecting viruses because the virus is in a file that was not transferred through e-mail.
Attackers could exploit IM vulnerabilities, such as buffer overflows. Like other applications, IM applications could have security holes, but these security holes are potentially more dangerous than those in other applications because connections are made directly from user to user through IM. If one of the IM users is an attacker, a security hole in IM can be exploited immediately. Problems were found in at least one IM application that allowed attackers to gain remote control of other IM users' computers.
Attackers could attempt to trick people into divulging private information or running malicious programs. A persuasive attacker might convince a user to perform an unsafe action during a chat session. This type of attack is called social engineering because the attacker uses a social situation (human interaction) to compromise your network or organizational security.

Some organizations protect themselves from potential IM application exploits by prohibiting the use of IM. Other organizations allow the use of IM, but define an IM application that they can support and secure. If removing IM completely from your organization's network is not an option, consider taking the following actions to secure IM:

Restrict the types of IM that are authorized for use. This prevents you from having to support, secure, and stay abreast of the security exploits of multiple types of IM applications.
If the data transmitted between IM clients should be private, obtain an IM application that encrypts communication. Some IM products allow you to implement PKI encryption, audit usage, and configure security settings centrally.
Create a written policy regarding the acceptable use of IM applications. Consider prohibiting the downloading of files over IM to protect your network users from potentially unsafe content.
Educate users on the dangers of IM. Explain that dangerous files might be transferred over IM. Also, tell them that attackers could try to get them to divulge confidential information.
Ensure that all IM users have updated virus scanners and that they use them.
Monitor IM vendor alerts and general security alerts for the discovery of security holes. Test and apply all vendor security patches immediately.
Internally (and between systems on trusted partner networks), you could use virtual private network (VPN) solutions to encrypt network traffic between hosts.
Install and configure an IM server, such as Microsoft Exchange Server 2000, for internal-only IM.

Top Secret Messenger and Message Inspector are two products that address IM security issues.

Exercise 1: Application Security Solutions

Match the security issues in the left column with the products or specifications that address those issues in the right column:

E-mail forgery
Clear text e-mail
Sniffing Web connection packets
Clear text IM
Buffer overflows
Cleartext cookie transmission

PKI-enabled IM applications
Secure coding practices
PGP
SSL/TLS
S/MIME
Security patches

Lesson Review

The following questions are intended to reinforce key information presented in this lesson. If you are unable to answer a question, review the lesson and then try the question again. Answers to the questions can be found in Appendix A, "Questions and Answers."

How might you secure communications between a Web browser and client?
What is a software developer's defense against buffer overflows? How should a security administrator handle buffer overflows?
What type of CGI exploits do attackers look for?
What types of security issues can arise from cookies?
What problems does signing active content seek to solve? What security issues might still exist in signed content?

Lesson Summary

SSL/TLS can be used to protect Web communications by encrypting them. SSL/TLS can also be used to identify and authenticate clients securely and protect the transfer of passwords across the Internet.
Active content is frequently used on the Internet to provide value-added services. Unfortunately, active content might be used to exploit systems. Users who interact with malicious active content might run programs that harm their systems and others on the network. To protect your organization from active content exploits, consider disabling the processing of active content. You should also warn network users of the potential for exploits.
Buffer overflows occur when an application receives more data than it was designed to handle in its buffer. A buffer that overflows could negatively affect other applications. Buffer overflows are frequently found and exploited by attackers. To protect your organization from buffer overflows, ensure that your developers use secure coding practices. As a security administrator, apply all security fixes as they are made available.
Cookies are sometimes used to store authentication information or other private data. Cookies can be stolen and packet sniffed during transfers. To improve the security of cookie data, use SSL/TLS encryption. Limit or prevent the use of cookies for authentication or private information.
CGI programs that are not created using secure coding practices are likely to have vulnerabilities. Buffer overflows are one of the most commonly exploited vulnerabilities of CGI applications. To secure CGI applications, ensure that they are developed using secure coding practices. On your Web server, you should remove all unused CGI applications. Also, inspect all CGI applications for security flaws.
Instant messaging (IM) programs typically transfer messages in cleartext between hosts. These communications can easily be intercepted and read by attackers with protocol analyzers. Further, buffer overflow security exploits have been discovered in several popular IM applications. Be sure to test and apply all security patches as soon as they are made available by software vendors.