In this chapter, you will learn how to

   Describe the functioning of the SSL/TLS protocol suite

   Explain web applications, plug-ins, and associated security issues

   Describe secure file transfer options

   Explain directory usage for data retrieval

   Explain scripting and other Internet functions that present security concerns

   Use cookies to maintain parameters between web pages

   Examine web-based application security issues

The World Wide Web was invented by Tim Berners-Lee to give physicists a convenient method of exchanging information. What began in 1990 as a physics tool in the European Laboratory for Particle Physics (CERN, the acronym for the original French name) has grown into a complex system that is used by millions of computer users for tasks from e-commerce, to e-mail, to chatting, games, and even the original intended use—file and information sharing. Before the Web, plenty of methods were used to perform these tasks, and they were already widespread in use. File Transfer Protocol (FTP) was used to move files, and Telnet allowed users access to other machines. What was missing was the common architecture brought by Berners-Lee: first, a common addressing scheme, built around the concept of a Uniform Resource Locator (URL), and second, the concept of linking documents to other documents by URLs through the Hypertext Markup Language (HTML).

Although these elements might seem minor, they formed a base that spread like wildfire. Berners-Lee developed two programs to demonstrate the usefulness of his vision: a web server to serve documents to users, and a web browser to retrieve documents for users. Both of these key elements contributed to the spread of this new technological innovation. The success of these components led to network after network being connected together in a “network of networks” known today as the Internet. Much of this interconnection was developed and funded through grants from the U.S. government to further technological and economic growth.

Current Web Components and Concerns

The usefulness of the Web is due not just to browsers, but also to web components that enable services for end users through their browser interfaces. These components use a wide range of protocols and services to deliver the desired content. From a security perspective, they offer users an easy-to-use, secure method of conducting data transfers over the Internet. Many protocols have been developed to deliver this content, although for most users, the browser handles the details.

From a systems point of view, many security concerns have arisen, but they can be grouped into three main tasks:

   Securing a server that delivers content to users over the Web

   Securing the transport of information between users and servers over the Web

   Securing the user’s computer from attack over a web connection

This chapter presents the components used on the Web to request and deliver information securely over the Internet.

Web Protocols

When two people communicate, several things must happen for the communication to be effective: they must use a language that both parties understand, and they must correctly use the language—that is, structure and syntax—to express their thoughts. The mode of communication is a separate entity entirely, because the previous statements are important in both spoken and written forms of communication. The same requirements are present with respect to computer communications, and they are addressed through protocols, agreed-upon sets of rules that allow different vendors to produce hardware and software that can interoperate with hardware and software developed by other vendors. Because of the worldwide nature of the Internet, protocols are very important and form the basis by which all the separate parts can work together. The specific instantiation of protocols is done through hardware and software components. The majority of this chapter concentrates on protocols related to the Internet as instantiated by software components.

Encryption (SSL and TLS)

Secure Sockets Layer (SSL) is a general-purpose protocol developed by Netscape for managing the encryption of information being transmitted over the Internet. It began as a competitive feature to drive sales of Netscape’s web server product, which could then send information securely to end users. This early vision of securing the transmission channel between the web server and the browser became an Internet standard. Today, SSL is almost ubiquitous with respect to e-commerce—all browsers support it as do web servers, and virtually all e-commerce web sites use this method to protect sensitive financial information in transit between web servers and browsers.

The Internet Engineering Task Force (IETF) embraced SSL in 1996 through a series of RFCs and named the group of RFCs Transport Layer Security (TLS). Starting with SSL 3.0, in 1999, the IETF issued RFC 2246, “TLS Protocol Version 1.0,” followed by RFC 2712, which added Kerberos authentication, and then RFCs 2817 and 2818, which extended TLS to HTTP version 1.1 (HTTP/1.1). Although SSL has been through several versions, TLS begins with an equivalency to SSL 3.0, so today SSL and TLS are essentially the same, although not interchangeable. Recent attacks have left SSL vulnerable, and the consensus is that SSL is dead and TLS is the path forward, although everyone calls it SSL.

SSL/TLS is a series of functions that exists in the OSI (Open System Interconnection) model between the application layer and the transport and network layers. The goal of TCP is to send an unauthenticated, error-free stream of information between two computers. SSL/TLS adds message integrity and authentication functionality to TCP through the use of cryptographic methods. Because cryptographic methods are an ever-evolving field, and because both parties must agree on an implementation method, SSL/TLS has embraced an open, extensible, and adaptable method to allow flexibility and strength. When two programs initiate an SSL/TLS connection, one of their first tasks is to compare available protocols and agree on an appropriate common cryptographic protocol for use in this particular communication. As SSL/TLS can use separate algorithms and methods for encryption, authentication, and data integrity, each of these is negotiated and determined depending on need at the beginning of a communication.

Browsers from Mozilla (Firefox) and Microsoft (Internet Explorer 11) allow fairly extensive SSL/TLS setup options (see Figure 17.1).

• Figure 17.1   IE 11 security options

How SSL/TLS Works

SSL/TLS uses a wide range of cryptographic protocols. As of 2014, SSL is no longer considered secure, with SSLv3 falling victim to the POODLE attack. Throughout the book, all references to SSL should be considered to be for TLS only. It will take a generation or longer for the term SSL to fade in favor of TLS, if ever.

The questions asked and answered are which protocol and which cryptographic algorithm will be used. For the client and server to communicate, both sides must agree on a commonly held protocol (SSL v1, v2, v3, or TLS v1, v1.1, v1.2). Commonly available cryptographic algorithms include Diffie-Hellman and RSA. The next step is to exchange certificates and keys as necessary to enable authentication.

Once authentication is established, the channel is secured with symmetric key cryptographic methods and hashes, typically RC4 or 3DES for symmetric key and MD5 or SHA-1 for the hash functions.

At this point, the authenticity of the server and possibly the client has been established, and the channel is protected by encryption against eavesdropping. Each packet is encrypted using the symmetric key before transfer across the network, and then decrypted by the receiver. All of this work requires CPU time; hence, SSL/TLS connections require significantly more overhead than unprotected connections. Establishing connections is particularly time consuming, so even stateless web connections are held in a stateful fashion when secured via SSL/TLS, to avoid repeating the handshake process for each request. This makes some web server functionality more difficult, such as implementing web farms, and requires that either an SSL/TLS appliance be used before the web server to maintain state or the SSL/TLS state information be maintained in a directory-type service accessible by all of the web farm servers. Either method requires additional infrastructure and equipment. However, to enable secure e-commerce and other private data transactions over the Internet, this is a cost-effective method to establish a specific level of necessary security.

The use of certificates could present a lot of data and complication to a user. Fortunately, browsers have incorporated much of this desired functionality into a seamless operation. Once you have decided always to accept code from XYZ Corporation, subsequent certificate checks are handled by the browser. The ability to manipulate certificate settings is under the Options menus in both Internet Explorer (Figures 17.2 and 17.3) and Mozilla Firefox (Figures 17.4 and 17.5).

• Figure 17.2   Internet Explorer certificate management options

• Figure 17.3   Internet Explorer certificate store

• Figure 17.4   Firefox certificate options

• Figure 17.5   Firefox certificate store

Once a communication is in the SSL/TLS channel, it is very difficult to defeat the SSL protocol. Before data enters the secured channel, however, defeat is possible. A Trojan program that copies keystrokes and echoes them to another TCP/IP address in parallel with the intended communication can defeat SSL/TLS, for example, provided that the Trojan program copies the data prior to SSL/TLS encapsulation. This type of attack has occurred and has been used to steal passwords and other sensitive material from users, performing the theft as the user actually types in the data.

The Web (HTTP and HTTPS)

HTTP is used for the transfer of hyperlinked data over the Internet, from web servers to browsers. When a user types a URL such as http://www.example.com into a browser, the http:// portion indicates that the desired method of data transfer is HTTP. Although it was initially created just for HTML pages, today many protocols deliver content over this connection protocol. HTTP traffic takes place over TCP port 80 by default, and this port is typically left open on firewalls because of the extensive use of HTTP.

One of the primary drivers behind the development of SSL/TLS was the desire to hide the complexities of cryptography from end users. When an SSL/TLS-enabled browser is used, this can be done simply by requesting a secure connection from a web server instead of a nonsecure connection. With respect to HTTP connections, this is as simple as using https:// in place of http://.

The entry of an SSL/TLS-based protocol will cause a browser to perform the necessary negotiations with the web server to establish the required level of security. Once these negotiations have been completed and the session is secured by a session key, a closed padlock icon is displayed in the lower-right corner of the screen to indicate that the session is secure. If the protocol is https:, your connection is secure; if it is http:, then the connection is carried by plaintext for anyone to see. Figure 17.6 shows a secure connection in Internet Explorer, and Figure 17.7 shows the equivalent in Firefox. As of Internet Explorer 7, Microsoft places the padlock icon in an obvious position, next to the URL, instead of in the lower-right corner of the screen, where users might more easily miss it. To combat a variety of attacks, in 2006 the SSL/TLS landscape changed with the advent of extended validation certificates and high-security browsers. These changes provide visual cues to the user when high-assurance certificates are being used as part of a secure SSL/TLS connection. These improvements were in response to phishing sites and online fraud, and although they require additional costs and registration on the part of the vendors, this is a modest up-front cost to help reduce fraud and provide confidence to customers.

• Figure 17.6   High-assurance notification in Internet Explorer

• Figure 17.7   High-assurance notification in Firefox

The objective of enabling cryptographic methods in this fashion is to make it easy for end users to use these protocols. SSL/TLS is designed to be protocol agnostic. Although designed to run on top of TCP/IP, it can operate on top of other, lower-level protocols, such as X.25. SSL/TLS requires a reliable lower-level protocol, so it is not designed and cannot properly function on top of a nonreliable protocol such as the User Datagram Protocol (UDP). Even with this limitation, SSL/TLS has been used to secure many common TCP/IP-based services, as shown in Table 17.1.

Table 17.1 SSL/TLS-Protected Services

HTTPS Everywhere

When websites were first deployed, providing HTTPS was a resource cost issue, because it took processor cycles to encrypt all the connections. Today, with a variety of encryption technologies available, managing the resources for HTTPS connections is much easier, and a case has been made by many in security that all web connections should be HTTPS. This has resulted in the HTTPS Everywhere movement (https://www.eff.org/https-everywhere/), spearheaded by the Electronic Frontier Foundation (EFF).

If web sites everywhere would turn off HTTP in favor of using only HTTPS (with TLS in light of SSL vulnerabilities), this would not solve all the security problems, but it would raise the bar substantially for many attacks. HTTPS Everywhere would go a long way for privacy, because it would prevent data snooping. It would also prevent many man-in-the-middle attacks, such as SSL stripping.

HTTP Strict Transport Security

HTTP Strict Transport Security (HSTS) is an IETF standard and a mechanism to enforce rules to prevent browsers from downgrading security when accessing a site. The policy states that when a web server provides an HTTP response header field named “Strict-Transport-Security,” then the user agent shall comply by not issuing insecure requests. The header field has a time period associated with it, set in the header, during which the policy is in effect.

HSTS was created in response to a series of attack profiles, the most critical being the SSL stripping man-in-the-middle attacks first publicly introduced by Moxie Marlinspike. The SSL stripping attack works on both SSL and TLS by transparently converting the secure HTTPS connection into a plain HTTP connection, removing the transport layer encryption protections. Although an observant user might notice the drop in security, by then the damage may have been done, and this relies on users knowing whether or not a page should be secure. No warnings are presented to the user during the downgrade process, which makes the attack fairly subtle to all but the most vigilant. Marlinspike’s sslstrip tool fully automates the attack and is available on the Web.

Directory Services (DAP and LDAP)

A directory is a data storage mechanism similar to a database, but it has several distinct differences designed to provide efficient data retrieval services compared to standard database mechanisms. A directory is designed and optimized for reading data, offering very fast search and retrieval operations. The types of information stored in a directory tend to be descriptive attribute data. A directory offers a static view of data that can be changed without a complex update transaction. The data is hierarchically described in a treelike structure, and a network interface for reading is typical.

To enable interoperability, X.500 was created as a standard for directory services. The primary method for accessing an X.500 directory is through the Directory Access Protocol (DAP), a heavyweight protocol that is difficult to implement completely, especially on PCs and more constrained platforms. This led to the Lightweight Directory Access Protocol (LDAP), which contains the most commonly used functionality. LDAP can interface with X.500 services, and, most importantly, LDAP can be used over TCP with significantly less computing resources than a full X.500 implementation. LDAP offers all of the functionality most directories need and is easier and more economical to implement; hence, LDAP has become the Internet standard for directory services.SSL/TLS provides several important functions to LDAP services. It can establish the identity of a data source through the use of certificates, and it can also provide for the integrity and confidentiality of the data being presented from an LDAP source. Because LDAP and SSL/TLS are two separate independent protocols, interoperability is more a function of correct setup than anything else. To achieve LDAP over SSL/TLS, the typical setup is to establish an SSL/TLS connection and then open an LDAP connection over the protected channel. To do this requires that both the client and the server be enabled for SSL/TLS. In the case of the client, most browsers are already enabled. In the case of an LDAP server, this specific function must be enabled by a system administrator. Because this setup initially is complicated, it’s definitely a task for a competent system administrator.

Once an LDAP server is set up to function over an SSL/TLS connection, it operates as it always has. The LDAP server responds to specific queries with the data returned from a node in the search. The SSL/TLS functionality is transparent to the data flow from the user’s perspective. From the outside, SSL/TLS prevents observation of the data request and response, thus ensuring confidentiality.

File Transfer (FTP and SFTP)

One of the original intended uses of the Internet was to transfer files from one machine to another in a simple, secure, and reliable fashion, which was needed by scientific researchers. Today, file transfers represent downloads of music content, reports, and other datasets from other computer systems to a PC-based client. Until 1995, the majority of Internet traffic was file transfers. With all of this need, a protocol was necessary so that two computers could agree on how to send and receive data. As such, FTP is one of the older protocols.

FTP

File Transfer Protocol (FTP) is an application-level protocol that operates over a wide range of lower-level protocols. FTP is embedded in most operating systems and provides a method of transferring files from a sender to a receiver. Most FTP implementations are designed to operate both ways, sending and receiving, and can enable remote file operations over a TCP/IP connection. FTP clients are used to initiate transactions, and FTP servers are used to respond to transaction requests. The actual request can be either to upload (send data from client to server) or to download (send data from server to client).

Clients for FTP on a PC can range from an application program, to the command-line FTP program in Windows/DOS, to most browsers. To open an FTP data store in a browser, you can enter ftp://url in the browser’s address field to indicate that you want to see the data associated with the URL via an FTP session—the browser handles the details.

Blind FTP (Anonymous FTP)

To access resources on a computer, an account must be used to allow the operating system–level authorization function to work. In the case of an FTP server, you may not wish to control who gets the information, so a standard account called anonymous exists. This allows unlimited public access to the files and is commonly used when you want to have unlimited distribution. On a server, access permissions can be established to allow only downloading, only uploading, or both downloading and uploading, depending on the system’s function.

Because FTP servers can present a security risk, they are typically not permitted on workstations and are disabled on servers without need for this functionality.

SFTP

FTP operates in a plaintext mode, so an eavesdropper can observe the data being passed. If confidential transfer is required, Secure FTP (SFTP) combines both the Secure Shell (SSH) protocol and FTP to accomplish this task. SFTP operates as an application program that encodes both the commands and the data being passed and requires SFTP to be on both the client and the server. SFTP is not interoperable with standard FTP—the encrypted commands cannot be read by the standard FTP server program. To establish SFTP data transfers, the server must be enabled with the SFTP program, and then clients can access the server, provided they have the correct credentials. One of the first SFTP operations is the same as that of FTP: an identification function that uses a username and an authorization function that uses a password. There is no anonymous SFTP account by definition, so access is established and controlled from the server using standard access control lists (ACLs), IDs, and passwords.

FTPS

FTPS is the implementation of FTP over an SSL/TLS-secured channel. This supports complete FTP compatibility, yet provides the encryption protections enabled by SSL/TLS. FTPS commonly runs on port 990 but can also run on port 21. When FTPS runs on port 990, it is referred to as Implicit FTPS because the use of port 990 implies a secure connection. Conversely, FTPS running on port 21 is an Explicit FTPS connection. When a client connects to an FTPS server on port 990, the assumption is that the client intends to perform SSL/TLS. Therefore, the SSL/TLS handshake begins with the session. FTP clients who connect on port 21 and intend to use SSL/TLS for security will need to take an extra step to explicitly state their intentions by sending an AUTH SSL or AUTH TLS command to the server. Once the server receives this command, the two parties perform an SSL/TLS handshake and enable a secure channel.

Vulnerabilities

Modern encryption technology can provide significant levels of privacy, up to military-grade secrecy. The use of protocols such as TLS provides a convenient method for end users to use cryptography without having to understand how it works. This can result in complacency—the impression that once TLS is enabled, the user is safe, but this is not necessarily the case. If a Trojan program is recording keystrokes and sending the information to another unauthorized user, for example, TLS cannot prevent the security breach. If the user is connecting to an untrustworthy site, the mere fact that the connection is secure does not prevent the other site from running a scam.

Using TLS and other encryption methods will not guard against your credit card information being “lost” by a company with which you do business, as in the Egghead.com credit card hack of 2000. In December 2000, Egghead.com’s credit card database was hacked, and as many as 3.7 million credit card numbers were exposed. This resulted eventually in the loss of the firm, which is now known as Newegg. The year 2014 was a year filled with data breaches and the loss of customer information—including credit card numbers—from many high-profile merchants such as Target. In these cases, the security failure was internal to the data storage in the company, not during transfer to the firm. So even with secure web controls, data can be lost after being stored in a company database.

The key to understanding what is protected and where it is protected is to understand what these protocols can and cannot do. The TLS suite can protect data in transit, but not on either end in storage. It can authenticate users and servers, provided that the certificate mechanisms are established and used by both parties. Properly set up and used, TLS can provide a very secure method of authentication, followed by confidentiality in data transfers and data integrity checking. But again, all of this occurs during transit, and the protection ends once the data is stored.

Code-Based Vulnerabilities

The ability to connect many machines together to transfer data is what makes the Internet so functional for so many users. Browsers enable much of this functionality, and as the types of data have grown on the Internet, browser functionality has grown as well. But not all functions can be anticipated or included in each browser release, so the idea of extending browser functions through plug-ins became a standard. Browsers can perform many types of data transfer, and in some cases, additional helper programs, or plug-ins, can increase functionality for specific types of data transfers. In other cases, separate application programs may be called by a browser to handle the data being transferred. Common examples of these plug-ins and programs include Shockwave and Flash plug-ins, Windows Media Player, and Adobe Acrobat (both plug-in and standalone). The richness that enables the desired functionality of the Internet has also spawned some additional types of interfaces in the form of ActiveX components and Java applets.

In essence, all of these are pieces of code that can be written by third parties, distributed via the Internet, and run on your PC. If the code does what the user wants, the user is happy. But the opportunity exists for these applications or plug-ins to include malicious code that performs actions not desired by the end user. Malicious code designed to operate within a web browser environment is a major tool for computer crackers to use to obtain unauthorized access to computer systems. Whether delivered by HTML-based e-mail, by getting a user to visit a web site, or even delivery via an ad server, the result is the same: malware performs malicious tasks in the browser environment.

Buffer Overflows

One of the most common exploits used to hack into software is the buffer overflow. The buffer overflow vulnerability is a result of poor coding practices on the part of software programmers—when any program reads input into a buffer (an area of memory) and does not validate the input for correct length, the potential for a buffer overflow exists. The buffer-overflow vulnerability occurs when an application can accept more input than it has assigned storage space and the input data overwrites other program areas. The exploit concept is simple: An attacker develops an executable program that performs some action on the target machine and appends this code to a legitimate response to a program on the target machine. When the target machine reads through the too-long response, a buffer-overflow condition causes the original program to fail. The extra malicious code fragment is now in the machine’s memory, awaiting execution. If the attacker executed it correctly, the program will skip into the attacker’s code, running it instead of crashing.

Java

Java is a computer language invented by Sun Microsystems as an alternative to Microsoft’s development languages. Designed to be platform independent and based on C, Java offered a low learning curve and a way of implementing programs across an enterprise, independent of platform. Although platform independence never fully materialized, and the pace of Java language development was slowed by Sun, Java has found itself to be a leader in object-oriented programming languages.

Java operates through an interpreter called a Java Virtual Machine (JVM) on each platform that interprets the Java code, and this JVM enables the program’s functionality for the specific platform. Java’s reliance on an interpretive step has led to performance issues, and Java is still plagued by poor performance when compared to most other languages. Security was one of the touted advantages of Java, but in reality, security is not a built-in function but an afterthought and is implemented independently of the language core. This all being said, properly coded Java can operate at reasonable rates, and when properly designed can act in a secure fashion. These facts have led to the wide dependence on Java for much of the server-side coding for e-commerce and other web-enabled functionality. Servers can add CPUs to address speed concerns, and the low learning curve has proven cost efficient for enterprises.

Java was initially designed to be used in trusted environments, and when it moved to the Internet for general use, safety became one of its much-hyped benefits. Java has many safety features, such as type checking and garbage collection, that actually improve a program’s ability to run safely on a machine and not cause operating system–level failures. This isolates the user from many common forms of operating system faults that can end in the “blue screen of death” in a Windows environment, where the operating system crashes and forces a reboot of the system. Safety is not security, however, and although safe, a malicious Java program can still cause significant damage to a system.

The primary mode of a computer program is to interact with the operating system and perform functional tasks for a user, such as getting and displaying data, manipulating data, storing data, and so on. Although these functions can seem benign, when enabled across the Web they can have some unintended consequences. The ability to read data from a hard drive and display it on the screen is essential for many programs, but when the program is downloaded and run from the Internet and the data is, without the knowledge of the user, sent across the Internet to an unauthorized user, this enables a program to spy on a user and steal data. Writing data to the hard drive can also cause deletions if the program doesn’t write the data where the user expects. Sun recognized these dangers and envisioned three different security policies for Java that would be implemented via the browser and JVM, providing different levels of security. The first policy is not to run Java programs at all. The second restricts Java program functionality when the program is not run directly from the system’s hard drive—programs being directly executed from the Internet have severe restrictions that block disk access and force other security-related functions to be performed. The last policy runs any and all Java programs as presented.

Most browsers adopted the second security policy, restricting Java functionality on a client unless the program was loaded directly from the client’s hard drive. Although this solved many problems initially, it also severely limited functionality. Today, browsers allow much more specific granularity on security for Java, based on security zones and user settings.

JavaScript

JavaScript is a scripting language developed by Netscape and designed to be operated within a browser instance. JavaScript works through the browser environment. The primary purpose of JavaScript is to enable features such as the validation of forms before they are submitted to the server. Enterprising programmers found many other uses for JavaScript, such as manipulating the browser history files, which is now prohibited by design. JavaScript actually runs within the browser, and the code is executed by the browser itself. This has led to compatibility problems, and not just between vendors, such as Microsoft and Mozilla, but between browser versions. Security settings in Internet Explorer are done by a series of zones, allowing differing levels of control over .NET functionality, ActiveX functionality, and Java functionality (see Figure 17.8). Unfortunately, these settings can be changed by a Trojan program, altering the browser (without alerting the user) and lowering the security settings. In Firefox, using the NoScript plug-in is a solution to this, but the reduced functionality leads to other issues, as shown in Figure 17.9, and requires more diligent user intervention.

• Figure 17.8   Java configuration settings in Internet Explorer

• Figure 17.9   Security setting functionality issues

Although JavaScript was designed not to be able to access files or network resources directly, except through the browser functions, it has not proven to be as secure as desired. This fault traces back to a similar fault in the Java language, where security was added on, without the benefit of a comprehensive security model. So, although designers put thought and common sense into the design of JavaScript, the lack of a comprehensive security model left some security holes. For instance, a form could submit itself via e-mail to an undisclosed recipient for the purpose of eavesdropping, spamming, or causing other problems—imagine your machine sending death threat e-mails to high-level government officials from a rogue JavaScript implementation.

Further, most browsers do not have a mechanism to halt a running script, short of aborting the browser instance, and even this might not be possible if the browser has stopped responding to commands. Malicious JavaScripts can do many things, including opening two new windows every time you close one, each with the code to open two more. There is no way out of this one, short of killing the browser process from the operating system.

JavaScripts can also trick users into thinking they are communicating with one entity when in fact they are communicating with another. For example, a window may open asking whether you want to download and execute the new update from “http://www.microsoft.com…/update.exe,” and what is covered by the ellipsis (…) is actually “/attacker.org/”—the user assumes this is a Microsoft address that is cut short by space restrictions on the display.

As a browser scripting language, JavaScript is here to stay. Its widespread popularity for developing applets such as animated clocks, mortgage calculators, and simple games will overcome its buggy nature and poor level of security.

ActiveX

ActiveX is the name given to a broad collection of application programming interfaces (APIs), protocols, and programs developed by Microsoft to download and execute code automatically over an Internet-based channel. The code is bundled together into an ActiveX control with an .ocx extension. These controls are referenced in HTML using the <object> tag. ActiveX is a tool for the Windows environment and can be extremely powerful. It can do simple things, such as enable a browser to display a custom type of information in a particular way, and it can also perform complex tasks, such as update the operating system and application programs. This range of abilities gives ActiveX a lot of power, but this power can be abused as well as used for good purposes. Internet Explorer has several options to control the execution of ActiveX controls, as illustrated in Figure 17.10.

• Figure 17.10   ActiveX security settings in Internet Explorer

To enable security and consumer confidence in downloaded programs such as ActiveX controls, Microsoft developed Authenticode, a system that uses digital signatures and allows Windows users to determine who produced a specific piece of code and whether or not the code has been altered. As in the case of Java, safety and security are different things, and Authenticode promotes neither in reality. Authenticode provides limited accountability at the time of download and provides reasonable assurance that the code has not been changed since the time of signing. Authenticode does not identify whether a piece of code will cause damage to a system, nor does it regulate how code is used, so a perfectly safe ActiveX control under one set of circumstances may be malicious if used improperly. As with a notary’s signature, recourse is very limited—if code is signed by a terrorist organization and the code ruins your machine, all Authenticode did was make it seem legitimate. It is still incumbent upon the users to know from whom they are getting code and to determine whether or not they trust that organization.

Critics of Authenticode and other code-signing techniques are not against code signing, because this is a universally recognized good thing. What the critics argue is that code signing is not a panacea for security issues and that marketing it as doing more than it really does is irresponsible. Understanding the nuances of security is important in today’s highly technical world, and leaving the explanations to marketing departments is not the ideal solution.

Securing the Browser

A great deal of debate concerns the relative security issue of browser extensions versus the rich user interaction that they provide. There is no doubt that the richness of the environment offered by ActiveX adds to the user experience. But as is the case in most coding situations, added features means weaker security, all other things being constant. If nothing else, a development team must spend some portion of its time on secure development practices—time that some developers and marketers would prefer to spend on new features. Although no browser is 100 percent safe, the use of Firefox coupled with the NoScript plug-in comes the closest to fitting the bill. Firefox will not execute ActiveX, so that threat vector is removed. The NoScript plug-in allows the user to determine from which domains to trust scripts. The use of NoScript puts the onus back on the user as to which domain scripts they choose to trust, and although it’s not perfect from a security perspective, this at least allows a measure of control over what code you want to run on your machine.

CGI

The Common Gateway Interface (CGI) was the original method for having a web server execute a program outside the web server process, yet on the same server. CGI offered many advantages to web-based programs. The programs can be written in a number of languages, although Perl is a favorite. These scripted programs embrace the full functionality of a server, allowing access to databases, UNIX commands, other programs, and so on. This provides a wide range of functionality to the web environment. With this unrestrained capability, however, come security issues. Poorly written scripts can cause unintended consequences at runtime. The problem with poorly written scripts is that their defects are not always obvious. Sometimes scripts appear to be fine, but unexpected user inputs can have unintended consequences. CGI is an outdated, and for the most part retired, technology. It has been replaced by newer scripting methods.

Server-Side Scripts

CGI has been replaced in many web sites through server-side scripting technologies such as Java, Active Server Pages (ASP), ASP.NET, and PHP. All these technologies operate in much the same fashion as CGI: they allow programs to be run outside the web server and to return data to the web server to be served to end users via a web page. The term server-side script is actually a misnomer, as these are actually executable programs that are either interpreted or run in virtual machines. Each of these newer technologies has advantages and disadvantages, but all of them have stronger security models than CGI. With these security models come reduced functionality and, because each is based on a different language, a steeper learning curve. Still, the need for adherence to programming fundamentals exists in these technologies—code must be well designed and well written to avoid the same vulnerabilities that exist in all forms of code. Buffer overflows are still an issue. Changing languages or technologies does not eliminate the basic security problems associated with incorporating open-ended user input into code. Understanding and qualifying user responses before blindly using them programmatically is essential to the security of a system.

Cookies

Cookies are small chunks of ASCII text passed within an HTTP stream to store data temporarily in a web browser instance. Invented by Netscape, cookies pass back and forth between web server and browser and act as a mechanism to maintain state in a stateless world. State is a term that describes the dependence on previous actions. By definition, HTTP traffic served by a web server is stateless—each request is completely independent of all previous requests, and the server has no memory of previous requests. This dramatically simplifies the function of a web server, but it also significantly complicates the task of providing anything but the most basic functionality in a site. Cookies were developed to bridge this gap. Cookies are passed along with HTTP data through a Set-Cookie message in the header portion of an HTTP message.

A cookie is actually a series of name-value pairs stored in memory within a browser instance. The specification for cookies established several specific name-value pairs for defined purposes. Additional name-value pairs may be defined at will by a developer. The specified set of name-value pairs includes the following:

   Expires This field specifies when the cookie expires. If no value exists, the cookie is good only during the current browser session and will not be persisted to the user’s hard drive. Should a value be given, the cookie will be written to the user’s machine and persisted until this datetime value occurs.

   Domain Specifies the domain where the cookie is used. Cookies were designed as memory-resident objects, but because the user or data can cause a browser to move between domains—say, from comedy.net to jokes.org—some mechanism needs to tell the browser which cookies belong to which domains.

   Path This name-value pair further resolves the applicability of the cookie into a specific path within a domain. If path = /directory, the cookie will be sent only for requests within /directory on the given domain. This allows a level of granular control over the information being passed between the browser and server, and it limits unnecessary data exchanges.

   Secure The presence of the keyword [secure] in a cookie indicates that it is to be used only when connected in an SSL/TLS session. This does not indicate any other form of security, as cookies are stored in plaintext on the client machine. Cookie management on a browser is normally an invisible process, but most browsers have methods for users to examine and manipulate cookies on the client side. Chrome users can examine, delete, and block individual cookies through the interface shown in Figure 17.11. Internet Explorer has a similar interface, with just a Delete option in the browser under Browsing History (see Figure 17.12). Additional cookie manipulation can be done through the file-processing system, because cookies are stored as individual files, as shown in Figure 17.13. This combination allows easier bulk manipulation, which is a useful option, as cookies can become quite numerous in short order.

• Figure 17.11   Chrome cookie management

• Figure 17.12   Internet Explorer cookie management

• Figure 17.13   Internet Explorer cookie store

So what good are cookies? Disable cookies in your browser and go to some common sites that you visit, and you’ll quickly learn the usefulness of cookies. Cookies store a variety of information, from customer IDs to data about previous visits. Because cookies are stored on a user’s machine in a form that will allow simple manipulation, they must always be considered suspect and are not suitable for use as a security mechanism. They can, however, allow the browser to provide crucial pieces of information to a web server. Advertisers can use them to control which ads you are shown, based on previous ads you have viewed. Specific sites can use cookies to pass state information between pages, enabling functionality at the user’s desired levels. Cookies can also remember your ZIP code for a weather site, your ID for a stock tracker site, the items in your shopping cart—these are all typical cookie uses. In the final analysis, cookies are a part of the daily web experience, here to stay and useful if not used improperly (such as to store security data and to provide ID and authentication).

Disabling Cookies

If the user disables cookies in a browser, this type of information will not be available for the web server to use. IETF RFC 2109 describes the HTTP state-management system (cookies) and specifies several specific cookie functions to be enabled in browsers, specifically:

   The ability to turn on and off cookie usage

   An indicator as to whether cookies are in use

   A means of specifying cookie domain values and lifetimes

Several of these functions have already been discussed, but to surf cookie-free requires more than a simple step. Telling a browser to stop accepting cookies is a setup option available through an Options menu, but this has no effect on cookies already received and stored on the system. To prevent the browser from sending cookies already received, the user must delete the cookies from the system. This bulk operation is easily performed, and then the browser can run cookie-free. Several third-party tools enable even a finer granularity of cookie control.

Browser Plug-Ins

The addition of browser scripting and ActiveX components allows a browser to change how it handles data, tremendously increasing its functionality as a user interface. But all data types and all desired functionality cannot be offered through these programming technologies. Plug-ins are used to fill these gaps.

Plug-ins are small application programs that increase a browser’s ability to handle new data types and add new functionality. Sometimes these plug-ins are in the form of ActiveX components—the form Microsoft chose for its Office plug-in, which enables a browser to manipulate various Office files, such as pivot tables from Excel, over the Web. Adobe has developed Acrobat Reader, a plug-in that enables a browser to read and display Portable Document Format (PDF) files directly in a browser. PDF files offer platform independence for printed documents and are usable across a wide array of platforms—they are a compact way to provide printed information.

With Microsoft’s new browser, Edge, comes a new method of adding functionality. Extensions is the name for add-ons to Edge, and they are found in the Microsoft app store, accessible from all Microsoft platforms. Figure 17.14 shows the addition of a new extension in Edge.

• Figure 17.14   Extensions in Microsoft Edge

Figure 17.15 illustrates the various plug-ins and browser helper objects (discussed in the next section) enabled in Internet Explorer.

• Figure 17.15   Add-ons for Internet Explorer

The combination of a development environment for developers and plug-in-enabled browsers that can display the content has caused these technologies to see widespread use. The result is a tremendous increase in visual richness in web communications, and this, in turn, has made the Web more popular and has increased usage in various demographic segments.

Until recently, these plug-ins have had a remarkable safety record. As Flash-based content grew more popular, crackers have examined the Flash plug-ins and software, determined vulnerabilities, and developed exploit code to use against the Flash protocol. Adobe has patched the issue, but because Apple has decided not to use Flash on its iPhones and iPads, the death of Flash is on the horizon.

The move of add-ons to curated environments like Microsoft’s app store also provides a means for controlling malicious content. The safety record is unknown, and based on previous systematic attempts to curate content for safety, it is fairly safe to say that the record will not be 100 percent safe, as errors will creep in due to complacent moderators.

Malicious Add-Ons

Add-ons are pieces of code that are distributed to allow extra functionality to be added to an existing program. An example of these are browser helper objects (BHOs), which provide a means of creating a plug-in module that is loaded with Internet Explorer and provide a means of adding capability to the browser. The functionality can be significant, as in the case of the Adobe Acrobat BHO that allows PDFs to be rendered in the browser. A BHO has unrestricted access to the Internet Explorer event model and can do things such as capture keystrokes.

Other programs can have add-ons that utilize the permissions given the master program. You should only use add-ons from trusted sources, and you need to understand the level of interaction risk they pose. ActiveX is a technology implemented by Microsoft to enhance web-enabled systems through significant additions to user controls. For example, unless signed by a trusted authority using Authenticode, ActiveX content should not be allowed in browsers, as the nature of the code changes can present significant risk.

Signed Applets

Code signing was an attempt to bring the security of shrink-wrapped software to software downloaded from the Internet. Code signing works by adding a digital signature and a digital certificate to a program file to demonstrate file integrity and authenticity. The certificate identifies the author, and the digital signature contains a hash value that covers the code, certificate, and signature to prove integrity, and this establishes the integrity of the code and publisher via a standard browser certificate check. The purpose of a company signing the code is to state that it considers the code it created to be safe, and it is stating that the code will not do any harm to the system (to the company’s knowledge). The digital signature also tells the user that the stated company is, indeed, the creator of the code.

The ability to use a certificate to sign an applet or a control allows the identity of the author of a control or applet to be established. This has many benefits. For instance, if a user trusts content from a particular vendor, such as Microsoft, the user can trust controls that are signed by Microsoft. This signing of a piece of code does not do anything other than identify the code’s manufacturer and guarantee that the code has not been modified since it was signed.

A signed applet can be hijacked as easily as a graphic or any other file. The two ways an attacker could hijack a signed control are by inline access or by copying the file in its entirety and republishing it. Inlining is using an embedded control from another site with or without the other site’s permission. Republishing a signed control is done much like stealing a GIF or JPEG image—a copy of the file is maintained on the unauthorized site and served from there instead of from the original location. If a signed control cannot be modified, why be concerned with these thefts, apart from the issue of intellectual property? The primary security concern comes from how the control is used. A cracker may be able to use a control in an unintended fashion, resulting in file loss or buffer overflow—conditions that weaken a system and can allow exploitation of other vulnerabilities. A common programming activity is cleaning up installation files from a computer’s hard drive after successfully installing a software package. If a signed control is used for this task and permission has already been granted, then improperly using the control could result in the wrong set of files being deleted. The control will still function as designed, but the issue becomes who it is used by and how. These are concerns not addressed simply by signing a control or applet.

Application-Based Weaknesses

Web browsers are not the only aspect of software being abused by crackers. The application software written to run on servers and serve up the content for users is also a target. Web application security is a fairly hot topic in security circles, as it has become a prime target for professional crackers. Criminal hackers typically are after some form of financial reward, whether from stolen data, stolen identity, or some form of extortion. Attacking web-based applications has proven to be a lucrative venture for several reasons. First, the target is a rich environment, as company after company has developed a customer-facing web presence, often including custom-coded functionality that permits customer access to back-end systems for legitimate business purposes. Second, building these custom applications to high levels of security is a difficult if not impossible feat, especially given the corporate pressure on delivery time and cost.

The same programmatic errors that plague operating systems, such as buffer overflows, can cause havoc with web-based systems. But web-based systems have a new history of rich customer interactions, including the collection of information from the customer and dynamically using customer-supplied information to modify the user experience. This makes the customer a part of the application, and when proper controls are not in place, errors such as the MySpace-based Samy worm can occur. Different types of errors are commonly observed in the deployment of web applications, and these have been categorized into six logical groupings of vulnerabilities: authentication, authorization, logical attacks, information disclosure, command execution, and client-side attacks. A total of 24 different types of vulnerabilities have been classified by the Web Application Security Consortium (WASC), an international organization that establishes best practices for web application security.

The changing nature of the web-based vulnerabilities is demonstrated by the changing of the OWASP Top Ten list of web application vulnerabilities maintained by The Open Web Application Security Project. OWASP is a worldwide free and open community focused on improving the security of application software and has published a series of Top Ten vulnerability lists highlighting the current state of the art and threat environment facing web application developers. OWASP maintains a web site (www.owasp.org) with significant resources to help firms build better software and eliminate these common and pervasive problems. The true challenge in this area is not just about coding, but also about developing an understanding of the nature of web applications and the difficulty of using user-supplied inputs for crucial aspects in a rich, user experience–based web application. The errors included in the OWASP Top Ten list have plagued some of the largest sites and those with arguably the best talent, including Amazon, eBay, and Google.

Session Hijacking

For communication across the Web, it is common to create a session to control communication flows. Sessions can be established and controlled using a variety of methods, including SSL/TLS and cookies. It is important to securely implement the setup and teardown of a session, because if one party ends the communication without properly tearing down the communication session, an interloper can take over the session, continue after one of the parties has left, and impersonate that party. If you log into your bank to conduct transactions, but allow a session hijacker in, then the hijacker can continue banking after you leave, using your account. This is one of the reasons it is so important to log off of banking and financial sites, rather than just closing the browser.

There are numerous methods of session hijacking, from man-in-the-middle attacks to side-jacking and browser takeovers. Side-jacking is the use of packet sniffing to steal a session cookie. Securing only the logon process and then switching back to standard HTTP can enable this attack methodology.

The best defenses are to use encryption correctly (TLS, not SSL) and to log out of and close applications when done. When you’re using multitabbed browsers, it is best to close the entire browser instance, not just the tab.

Client-Side Attacks

The web browser has become the major application for users to engage resources across the Web. The popularity and the utility of this interface have made the web browser a prime target for attackers to gain access and control over a system. A wide variety of attacks can occur via a browser, typically resulting from a failure to properly validate input before use. Unvalidated input can result in a series of injection attacks, header manipulation, and other forms of attack.

Cross-Site Scripting

A cross-site scripting attack is a code injection attack in which an attacker sends code in response to an input request. This code is then rendered by the web server, resulting in the execution of the code by the web server. Cross-site scripting attacks take advantage of a few common elements in web-based systems. Cross-site scripting is covered in detail in Chapter 18.

Header Manipulations

When HTTP is being dynamically generated through the use of user inputs, unvalidated inputs can give attackers an opportunity to change HTTP elements. When user-supplied information is used in a header, it is possible to create a variety of attacks, including cache poisoning, cross-site scripting, cross-user defacement, page hijacking, cookie manipulation, and open redirect.

Autofill and Hidden Fields

Autofill is a browser mechanism designed to make it easier for users to submit common data to webpages. The mechanics of how this is done varies from browser to browser, but the basic idea is you identify what you wish to autofill and the browser prepopulates known fields by name for you. This is a convenience factor, but can also be a risk if the fields it is populating are hidden. Not all browsers will autofill hidden fields, but those that do can be giving away items such as email address, phone number, house address, credit card details, and so on. All based on previous entries and without the user seeing it as the field is hidden.

Web 2.0 and Security

A relatively new phenomenon known as Web 2.0 has swept the Internet. Web 2.0 is a collection of technologies designed to make web sites more useful for users. From newer languages and protocols, such as JSON and AJAX, to user-provided content, to social networking sites and user-created mash-ups, the Internet has changed dramatically from its static HTML roots. A wide range of security issues are associated with this new level of deployed functionality.

The new languages and protocols add significant layers of complexity to a web site’s design, and errors can have significant consequences. Early efforts by Google to add Web 2.0 functionality to its applications created holes that allowed hackers access to a logged-in user’s Gmail account and password. Google has fixed these errors, but they illustrate the dangers of rushing into new functionality without adequate testing. The fine details of Web 2.0 security concerns are far too numerous to detail here—in fact, they could comprise their own book. The important thing to remember is that the foundations of security apply the same way in Web 2.0 as they do elsewhere. In fact, with more capability and greater complexity come a greater need for strong foundational security efforts, and Web 2.0 is no exception.