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 used by millions of computer users for a range of tasks, from e-commerce to e-mail, 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 via URLs through the Hypertext Markup Language (HTML).

E-mail is one of the most popular applications on company networks. With over 4.3 billion e-mail users, more than 260 billion e-mails per year, and the average worker getting over 120 e-mails a day, the usage numbers are staggering. The split between business and personal e-mail is 55 percent to 45 percent, respectively. The total amount of spam is unknown, but even after extensive filtering, spam averages nearly 10 percent of inbox traffic.

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. It also covers web-mediated communication, such as e-mails and instant messages.

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, which are 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) was 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 the term SSL is almost ubiquitous with respect to e-commerce—all browsers supported it, as did web servers, and virtually all e-commerce websites used this method to protect sensitive financial information in transit between web servers and browsers. However, when speaking nowadays about SSL, we are generally referring to the TLS protocol. Today, SSL is completely deprecated. It has internal vulnerabilities and has been completely breached by multiple tools and attack methods, and thus has been replaced everywhere by TLS.

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. Because SSL has had all versions deprecated, only TLS remains secure, and wherever the term SSL is found in this book, it refers to TLS.

TLS is a series of functions that exists in the Open System Interconnection (OSI) model between the application layer and the transport and network layers. The goal of the Transmission Control Protocol (TCP) is to send an unauthenticated, error-free stream of information between two computers. 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, TLS has embraced an open, extensible, and adaptable method to allow flexibility and strength. When two programs initiate a 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. Because 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.

Tech Tip

How TLS Works

TLS uses a wide range of cryptographic protocols. At the initiation of the protocol, the questions asked and answered are which TLS version and which cryptographic algorithm will be used. For the client and server to communicate, both sides must agree on a commonly held version of the protocol (TLS v1.2 or v1.3). Commonly available cryptographic algorithms include Diffie-Hellman, AES, and AEAD. The next step is to exchange certificates and keys, as necessary, to enable authentication.

Tech Tip

Tech Tip

Once authentication is established, the channel is secured with symmetric key cryptographic methods and hashes–typically AES for symmetric key and SHA-256 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 it’s decrypted by the receiver. All of this work requires CPU time; hence, 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 a TLS appliance be used before the web server to maintain state or the 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. In the Chrome browser, the details for a certificate are found under the Security tab on the DevTools page, as shown in Figure 17.1.

• Figure 17.1 Viewing a certificate in Chrome browser

Once a communication is in the TLS channel, it is very difficult to defeat the TLS 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 TLS, for example, provided that the Trojan program copies the data prior to 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.

Tech Tip

The Web (HTTP and HTTPS)

The Hypertext Transfer Protocol (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 TLS was the desire to hide the complexities of cryptography from end users. When a 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 a 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 URL bar to indicate that the session is secure. If the protocol is HTTPS (Hypertext Transfer Protocol Secure), your connection is secure; if it is HTTP, the connection is carried by plaintext for anyone to see.

The objective of enabling cryptographic methods in this fashion is to make it easy for end users to use these protocols. 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. 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, TLS has been used to secure many common TCP/IP-based services, as shown in Table 17.1.

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 (www.eff.org/https-everywhere/), spearheaded by the Electronic Frontier Foundation (EFF).

If websites 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, making most of them impossible. 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 for enforcing 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,” 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.

Try This!

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 the functionality most directories need and is easier and more economical to implement; hence, LDAP has become the Internet standard for directory services. 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 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 a 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 a 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 TLS functionality is transparent to the data flow from the user’s perspective. From the outside, 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 data sets 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).

Tech Tip

Clients for FTP on a PC can range from application programs, to the command-line FTP programs in Windows, 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 TLS handshake begins with the session. FTP clients who connect on port 21 and intend to use 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 a 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. Protecting the communication channel is important, but it’s not enough. Many of the security failures that result in data breaches are due to internal security failures within the company; they do not occur during data 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 website, or even delivery via an ad server, the result is the same: malware performs malicious tasks in the browser environment.

Cross Check

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 offers a low learning curve and a way of implementing programs across an enterprise, independent of platform. Java is now owned and managed by Oracle and is one of the leading object-oriented programming languages.

Most browsers initially adopted a 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. Control of JavaScript functions in Chrome is found under Settings | Privacy and Security | Site Settings | Content (JavaScript), as shown in Figure 17.2.

• Figure 17.2 JavaScript configuration settings in Chrome

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/,” and you assume 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.

Securing the Browser

A great deal of debate concerns the relative security issue of browser extensions versus the rich user interaction they provide. There is no doubt that the richness of the environment offered by various browser extension mechanisms can add 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.

There is a wide range of activities one can do to increase browser security—from blocking scripts to invoking newer privacy-enhancing browsers such as the Brave browser. The Brave browser, built on top of the Chrome engine, gives users significant control over selected elements during browsing, including ads, trackers, and other elements used by servers as part of the browsing experience. Flat out blocking everything results in an unusable browsing experience in many cases, but offering control to the user over which elements are allowed provides balance, resulting in a secure browsing experience for the user.

Server-Side Scripts

The Common Gateway Interface (CGI) has been replaced in many websites 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 the “script” is actually an executable program that’s either interpreted or run in a virtual machine. 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 a 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.3.

• Figure 17.3 Chrome cookie management

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; they are here to stay and are 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 the following specific cookie functions to be enabled in browsers:

   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 an even finer granularity of cookie control.

Browser Plug-Ins

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

Plug-ins are small application programs that increase a browser’s ability to handle new data types and add new functionality. 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 newer browser, Edge, comes a new method of adding functionality. Browser 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.4 shows the addition of a new extension in the Microsoft Edge browser.

• Figure 17.4 Browser extensions in Microsoft Edge

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 distributed pieces of code that 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 as well as a means of adding capability to the browser. The functionality can be significant, as in the case of the Adobe Acrobat BHO, which allows PDFs to be rendered in the browser. A BHO has unrestricted access to the Internet Explorer event model and can perform actions such as capturing keystrokes.

Tech Tip

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.

Code Signing

To enable security and consumer confidence in downloaded programs, 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 program 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.

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 and 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.

Cross Check

The same programmatic errors that plague operating systems, such as buffer overflows, can cause havoc with web-based systems. However, 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, problems 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 from year to year. The Open Web Application Security Project, or OWASP for short, is a worldwide free and open community focused on improving the security of application software. OWASP publishes a series of Top Ten vulnerability lists highlighting the current state-of-the-art threats facing web application developers. OWASP maintains a website (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 of a rich, user-experience-based web application. The programming 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 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 in to 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 sidejacking and browser takeovers. Sidejacking 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 a browser with multiple tabs open, it is best to close the entire browser instance, not just the tab in question.

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 19.

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 web pages. The mechanics of how this is done varies from browser to browser, but the basic idea is that 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 your e-mail address, phone number, house address, credit card details, and so on—all based on previous entries and without you noticing because the fields are 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 websites 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 mashups, 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 website’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 comes a greater need for strong foundational security efforts, and Web 2.0 is no exception.

How E-mail Works

E-mail started with mailbox programs on early time-sharing machines, allowing researchers to leave messages for others using the same machine. The first intermachine e-mail was sent in 1972, and a new era in person-to-person communication was launched. E-mail proliferated, but it remained unsecured, only partly because most e-mail is sent in plaintext, providing no privacy in its default form. Current e-mail in its use is not different from its earlier versions; it’s still a simple way to send a relatively short text message to another user. Users’ dependence on e-mail has grown with the number of people accessing the Internet.

Tech Tip

Internet e-mail depends on three primary protocols: SMTP, POP3, and IMAP. Simple Mail Transfer Protocol (SMTP) is the method by which mail is sent to the server as well as from server to server. SMTP by default uses TCP port 25. POP3 stands for Post Office Protocol version 3, which by default uses TCP port 110. POP3 is a method by which a client computer may connect to a server and download new messages. POP3 has been partly replaced by IMAP, or Internet Message Access Protocol, which uses TCP port 143 by default. IMAP is similar to POP3 in that it allows the client to retrieve messages from the server, but IMAP typically works in greater synchronization; for example, e-mails are left on the server until the client deletes them in the client, at which time IMAP instructs the server to delete them. As e-mail services became more standardized, the methods of transmission became easier to attack because they were not strange proprietary protocols. Also, as the world became more connected, there were many more available targets for the malware and commercial e-mails.

Secure versions of the common communication protocols exist via the STARTTLS method. STARTTLS is a means of using Transport Layer Security (TLS) to secure a communication channel for text-based communication protocols. Table 17.2 shows the port assignments associated with STARTTLS.

E-mail appears to be a client-to-client communication, between sender and receiver. In reality, a lot of steps are involved, as shown in Figure 17.5 and described here:

• Figure 17.5 How e-mail works

1.   A user composes and sends an e-mail from the user’s client machine.

2.   The e-mail is sent to the client’s e-mail server. In an Internet service provider (ISP) environment, this could be via the ISP. In the case of web mail, it is the mail service (Gmail, Hotmail/Live, and so on). In a corporate environment, it is the corporate mail server.

3.   a. The receiving e-mail server scans the e-mail for viruses, malware, and other threats.

b. The mail server uses DNS to obtain the recipient e-mail server address via an MX record.

4.   The mail server prepares the e-mail for transit across the Internet to the recipient’s mail server.

5.   The e-mail is routed across the Internet.

6.   The receiving e-mail server scans the e-mail for viruses, malware, and other threats.

7.   The e-mail is passed to the recipient’s in-box, where it can be read.

This list of steps leaves out a lot of details, but it provides the main steps in e-mail transference. The steps are remarkably similar for instant messaging applications as well. Rather than in-boxes and e-mail as a medium, the instant messaging apps deliver the text messages directly to the screen of the app.

In technical terms, the application on the sender’s machine is referred to as a mail user agent (MUA), and the mail server is a mail transfer agent (MTA). The recipient’s mail server is referred to as a mail delivery agent (MDA). These terms are used when discussing mail transfers to provide accuracy in the conversation. For communication from the MUA to the MTA, SMTP (port 25) is used, and communication from MTA to MTA is also SMTP. The protocol used for communication from the MDA to the MUA on the recipient machine is typically POP3/IMAP.

E-mail Structure

E-mail is structured in two elements: a header and the body. The entire message is sent via plain ASCII text, with attachments included using Base64 encoding. The e-mail header provides information for the handling of the e-mail between MUAs, MTAs, and MDAs. The following is a sample e-mail header:

The specific elements shown in this header will be examined throughout this chapter. What is important to note is that the format of the message and its attachments are in plaintext.

MIME

When a message has an attachment, the protocol used to deliver the message is Multipurpose Internet Mail Extensions (MIME). This protocol allows the exchange of different kinds of data across text-based e-mail systems. When MIME is used, it is marked in the header of the e-mail, along with supporting elements to facilitate decoding. The following is an excerpt from a header that has MIME elements:

The e-mail text has been replaced with <HTML E-MAIL message goes here> and the JPEG image is truncated, but the structure of the sample shows how content can be encoded and included in an e-mail.

Security of E-mail

E-mail can be used to move a variety of threats across the network. From spam, to viruses, to advanced malware in spear-phishing attacks, e-mail can act as a transmission medium. Spam is the most common attack but is now just a nuisance; the majority of spam is now mostly cleaned up by mail server filters and software.

The e-mail hoax has become another regular occurrence; Internet-based urban legends are spread through e-mail, with users forwarding them in seemingly endless loops around the globe. And, of course, people still haven’t found a good way to block ubiquitous spam e-mails (a sampling of which is shown in Figure 17.6), despite the remarkable advance of every other technology.

• Figure 17.6 A typical list of spam e-mails

E-mail security is ultimately the responsibility of users themselves, because they are the ones who will actually be sending and receiving the messages. However, security administrators can give users the tools they need to fight malware, spam, and hoaxes. Secure/Multipurpose Internet Mail Extensions (S/MIME) and Pretty Good Privacy (PGP) are two popular methods used for encrypting e-mail, as discussed later in the chapter. Server-based and desktop-based virus protection can help against malicious code, and spam filters attempt to block all unsolicited commercial e-mail, also called spam. E-mail users need to be educated about security as well, however, because the popularity and functionality of e-mail is only going to increase with time.

Instant messaging (IM), while not part of the e-mail system, is similar to e-mail in many respects, particularly in the sense that it is commonly plaintext and can transmit files. IM’s handling of files opens the application to virus exploitation just like e-mail.

Spam

Spam is the industry trade name for unsolicited e-mails. There are a variety of reasons that spam is sent. For one, it is low to no cost to send. Also, about 3 percent of users click the links in spam, so bottom line, it works. Spam can be sent by legitimate companies, using a shotgun approach to drive sales. This is generally seen as annoying and is avoided by most companies with images to protect. Currently, the most common types of spam in the U.S. are pharmacy/healthcare spam and dating spam. Spam is also used by criminals to send malware, to get users to click items they normally wouldn’t, or to set a user up for a scam or fraudulent attack. There are entire botnets whose sole purpose is to spread spam for these causes, such as the Marina Botnet, Kraken, and Conficker.

Although spam levels are extreme, comprising as much as 60 percent of all e-mail traffic, the number of actual spam sources is remarkably lower. As few as 100 spammers account for nearly 80 percent of all spam. Details as to who these characters are, their ISPs, domains, and other technical details are publicized by the Spamhaus project (www.spamhaus.org/statistics/spammers/).

Malicious Code

Viruses and worms are popular programs because they make themselves popular. When viruses were constrained to only one computer, they attempted to spread by attaching themselves to every executable program that they could find. This worked out very well for the viruses, because they could piggyback onto a floppy disk with a program that was being transferred to another computer. The virus would then infect the next computer, and the next computer after that. While often successful, virus propagation was slow, and floppies could be scanned for viruses.

The advent of computer networks was a computer virus writer’s dream, allowing viruses to attempt to infect every network share to which the computer was attached. This extended the virus’s reach from a set of machines that might share a floppy disk to every machine on the network. Because the e-mail protocol permits users to attach files to e-mail messages, as shown in Figure 17.7, viruses can travel by e-mail from one local network to another, anywhere on the Internet. This changed the nature of virus programs—they once were localized but now could spread virtually everywhere. E-mail gave the virus a global reach.

• Figure 17.7 Viruses commonly spread through e-mail attachments.

When active content was designed for the Web, in the form of Java and ActiveX scripts, these scripts were interpreted and run by the web browser. E-mail programs also would run these scripts, and that’s when the trouble began. Some e-mail programs, most notably Microsoft Outlook, use a preview pane, which allows users to read e-mails without opening them in the full screen (see Figure 17.8).

• Figure 17.8 The preview pane on the right can execute code in e-mails without them being opened.

Tech Tip

Unfortunately, this preview still activates all the content in the e-mail message, and because Outlook supports Visual Basic scripting, it is vulnerable to e-mail worms. A user doesn’t need to run the program or even open the e-mail to activate the worm—simply previewing the e-mail in the preview pane can launch the malicious content. This form of automatic execution was the primary reason for the spread of the ILOVEYOU worm.

Tech Tip

All malware is a security threat, with the several different types having different countermeasures. The antivirus systems we have used for years have progressed to try and stop all forms of malicious software, but they are not a panacea. Worm prevention also relies on patch management of the operating system and applications. Viruses are launched by users, and because one of the most common transfer methods for viruses is through e-mail, the people using the e-mail system create the front line of defense against viruses. In addition to antivirus scanning of user systems, and possibly an e-mail virus filter, users need to be educated about the dangers of viruses.

Although the great majority of users are now aware of viruses and the damage they can cause, more education may be needed to instruct them on the specific things that need to be addressed when a virus is received via e-mail. These can vary from organization to organization and from e-mail software to e-mail software; however, some useful examples of good practices involve examining all e-mails for a known source as well as a known destination, especially if the e-mails have attachments. Strange files or unexpected attachments should always be checked with an antivirus program before execution. Users also need to know that some viruses can be executed simply by opening the e-mail or viewing it in the preview pane. Education and proper administration is also useful in configuring the e-mail software to be as virus resistant as possible—turning off scripting support and the preview pane are good examples. Many organizations outline specific user responsibilities for e-mail, similar to network acceptable use policies (AUPs). Some examples include using e-mail resources responsibly, avoiding the installation of untrusted programs, and using localized antivirus scanning programs such as AVG.

Another protection is to carefully create virus-scanning procedures. If possible, perform virus scans on every e-mail as it comes into the company’s e-mail server. This is actually the one place that spam may prove useful. The explosion in spam mail has driven the adoption of e-mail-filtering gateways designed to greatly reduce spam messages. These specialized e-mail servers have evolved to attempt to protect against virus threats as well as spam. Some users will also attempt to retrieve e-mail offsite from a normal ISP account, which can bypass the server-based virus protection, so every machine should also be protected with a host-based virus protection program that scans all files on a regular basis and performs checks of files upon their execution. Although these steps will not eliminate the security risks of malicious code in e-mail, they will limit infection and help to keep the problem to manageable levels.

Hoax E-mails

E-mail hoaxes are mostly a nuisance, but they do cost everyone, not only in the time wasted by receiving and reading the e-mails, but also in the Internet bandwidth and server processing time they take up. E-mail hoaxes are global urban legends, perpetually traveling from one e-mail account to the next, and most have a common theme of some story you must tell ten other people about right away for good luck or because of some virus that will harm your friends unless you tell them immediately. Hoaxes are similar to chain letters, but instead of promising a reward, the story in the e-mail is typically what produces the action.

Hoaxes have been circling the Internet for many years, and many websites are dedicated to debunking them, such as Snopes.com (see Figure 17.9).

• Figure 17.9 Snopes is an online reference for urban legends common in hoax e-mails.

The most important thing to do in this case is educate e-mail users: they should be familiar with a hoax or two before they go online, and they should know how to search the Internet for hoax information. Users need to apply the same common sense on the Internet that they would in real life: if it sounds too outlandish to be true, it probably is a fabrication. The goal of education about hoaxes should be to change user behavior to delete the hoax e-mail and not send it on.

Mail Gateway

E-mail is one of the reasons for connecting networks together, and mail gateways can act as solutions to handle mail-specific traffic issues. Mail gateways are used to process e-mail packets on a network, providing a wide range of e-mail-related services. From filtering spam, to managing data loss, to handling the encryption needs, mail gateways are combinations of hardware and software optimized to perform these tasks in the enterprise.

Spam Filter

The bane of users and system administrators everywhere, spam is essentially unsolicited or undesired bulk electronic messages. While typically applied to e-mail, spam can be transmitted via text message to phones and mobile devices, as postings to Internet forums, and by other means. If you’ve ever used an e-mail account, chances are you’ve received spam. Enter the issue of spam filtering, the identification and removal of spam traffic from an e-mail stream.

From a productivity and security standpoint, spam costs businesses and users billions of dollars each year, and it is such a widespread problem that the U.S. Congress passed the CAN-SPAM Act of 2003 to empower the Federal Trade Commission to enforce the act and the Department of Justice to enforce criminal sanctions against spammers. The act establishes requirements for those who send commercial e-mail, spells out penalties for spammers and companies whose products are advertised in spam if they violate the law, and gives consumers the right to ask e-mailers to stop spamming them. Despite all our best efforts, however, spam just keeps coming; as the technologies and techniques developed to stop the spam get more advanced and complex, so do the tools and techniques used to send out the unsolicited messages.

Here are a few of the more popular methods used to fight the spam epidemic; most of these techniques are used to filter e-mail but could be applied to other mediums as well:

   Blacklisting Blacklisting is essentially noting which domains and source addresses have a reputation for sending spam and then rejecting messages coming from those domains and source addresses. This is basically a permanent “ignore” or “call block” type of capability. Several organizations and a few commercial companies provide lists of known spammers.

   Content or keyword filtering Similar to Internet content filtering, this method filters e-mail messages for undesirable content or indications of spam. Much like content filtering of web content, filtering e-mail based on something like keywords can cause unexpected results, as certain terms can be used in both legitimate and spam e-mail. Most content-filtering techniques use regular expression matching for keyword filtering.

   Trusted servers The opposite of blacklisting, a trusted server list includes SMTP servers that are being “trusted” not to forward spam.

   Delay-based filtering Some Simple Mail Transfer Protocol (SMTP) servers are configured to insert a deliberate pause between the opening of a connection and the sending of the SMTP server’s welcome banner. Some spam-generating programs do not wait for that greeting banner, and any system that immediately starts sending data as soon as the connection is opened is treated as a spam generator and dropped by the SMTP server.

   PTR and reverse DNS checks Some e-mail filters check the origin domain of an e-mail sender. Checking the reverse lookup reference from the DNS (the PTR record entry) can assist in determining the validity of the e-mail. If the reverse checks show the mail is coming from a dial-up user, home-based broadband, or a dynamically assigned address, or has a generic or missing domain, then the filter rejects it because these are common sources of spam messages.

   Callback verification As many spam messages use forged “from” addresses, some filters attempt to validate the “from” address of incoming e-mail. The receiving server can contact the sending server in an attempt to validate the sending address, but this is not always effective, as spoofed addresses are sometimes valid e-mail addresses that can be verified.

   Statistical content filtering Statistical filtering is much like a document classification system. Users mark received messages as either spam or legitimate mail and the filtering system learns from the user’s input. The more messages that are seen and classified as spam, the better the filtering software should get at intercepting incoming spam. Spammers counteract many filtering technologies by inserting random words and characters into the messages, making it difficult for content filters to identify patterns common to spam.

   Rule-based filtering Rule-based filtering is a simple technique that merely looks for matches in certain fields or keywords. For example, a rule-based filtering system may look for any message with the words “get rich” in the subject line of the incoming message. Many popular e-mail clients have the ability to implement rule-based filtering.

   Egress filtering Some organizations perform spam filtering on e-mail leaving their organization as well, and this is called egress filtering. The same types of anti-spam techniques can be used to validate and filter outgoing e-mail in an effort to combat spam.

   Hybrid filtering Most commercial anti-spam methods use hybrid filtering, or a combination of several different techniques to fight spam. For example, a filtering solution may take each incoming message and match it against known spammers, then against a rule-based filter, then against a content filter, and finally against a statistical-based filter. If the message passes all filtering stages, it will be treated as a legitimate message; otherwise, it is rejected as spam.

Much spam filtering is done at the network or SMTP server level. It’s more efficient to scan all incoming and outgoing messages with a centralized solution than it is to deploy individual solutions on user desktops throughout the organization. E-mail is essentially a proxied service by default: messages generally come into and go out of an organization’s mail server. (Users don’t typically connect to remote SMTP servers to send and receive messages, but they can.) Anti-spam solutions are available in the form of software that is loaded on the SMTP server itself or on a secondary server that processes messages either before they reach the SMTP server or after the messages are processed by the SMTP server. Anti-spam solutions are also available in appliance form, where the software and hardware are a single integrated solution. Many centralized anti-spam methods allow individual users to customize spam filtering for their specific in-box, specifying their own filter rules and criteria for evaluating inbound e-mail.

The central issue with spam is that, despite all the effort placed into building effective spam-filtering programs, spammers continue to create new methods for flooding in-boxes. Spam-filtering solutions are good but are far from perfect and continue to fight the constant challenge of allowing in legitimate messages while keeping the spam out. The lack of central control over Internet traffic also makes anti-spam efforts more difficult. Different countries have different laws and regulations governing e-mail, which range from draconian to nonexistent. For the foreseeable future, spam will continue to be a burden to administrators and users alike.

Tech Tip

Mail Relaying

One of the steps that the majority of system administrators running Internet e-mail servers have taken to reduce spam, and which is also a good e-mail security principle, is to shut down mail relaying. Port scanning occurs across all hosts all the time, typically with a single host scanning large subnets for a single port, and some of these people could be attempting to send spam e-mail. When they scan for TCP port 25, they are looking for SMTP servers, and once they find a host that is an open relay (a mail server that will accept mail from anyone), they can use that host to send as many commercial e-mails as possible. The reason that they look for an open relay is that spammers typically do not want the e-mails traced back to them. Mail relaying is similar to dropping a letter off at a post office instead of letting the postal carrier pick it up at your mailbox. On the Internet, that consists of sending e-mail from a separate IP address, making it more difficult for the mail to be traced back to you. SMTP server software is typically configured to accept mail only from specific hosts or domains. All SMTP software can and should be configured to accept only mail from known hosts, or to known mailboxes; this closes down mail relaying and helps to reduce spam.

Tech Tip

Since it may not be possible to close all mail relays, and because some spammers will mail from their own mail servers, software must be used to combat spam at the recipient’s end. Spam can be filtered at two places: at the host itself and at the server. Filtering spam at the host level is done by the e-mail client software and usually employs basic pattern matching, focusing on the sender, subject, or text of the e-mail. This fairly effective system uses an inordinate amount of bandwidth and processing power on the host computer, however. These problems can be solved by filtering spam at the mail server level. Many companies offer a dedicated appliance designed as a specialty e-mail server with the primary task of filtering spam. This server typically uses a combination of techniques listed here. It also implements an internal database to allow more granular filtering based on spam the appliance has already seen.

Try This!

Greylisting

Another technique for combatting spam is known as greylisting. When an e-mail is received, it is bounced as a temporary rejection. SMTP servers that are compliant with RFC 5321 will wait a configurable amount of time and attempt retransmission of the message. Obviously, spammers will not retry sending of any messages, so spam is reduced.

All the techniques we have discussed for dealing with spam have advantages and disadvantages, and most people will run some combination of techniques to attempt to filter as much spam as possible while not rejecting legitimate messages.

A side benefit of filtering spam at the receiving server is reduced e-mail. In enterprises, performing backups of information is a significant task. Backups are size dependent, both in cost and time, and reducing e-mail by eliminating spam can have significant impacts on e-mail backups. Spam reduction will also have a significant impact on the e-discovery process, as it reduces the quantity of material that needs to be searched. E-discovery is short for electronic discovery, the electronic component of a legal discovery process. The discovery process is court mandated and, when applied to a corporate environment, can cause the shutdown of corporate operations until the process is complete. For this reason, anything that makes the process easier or faster will benefit the corporation.

Tech Tip

Spam URI Real-time Block Lists

Spam URI Real-time Block Lists (SURBLs) detect unwanted e-mail based on invalid or malicious links within a message. Using an SURBL filter is a valuable tool to protect users from malware and phishing attacks. Not all mail servers support SURBL, but this technology shows promise in the fight against malware and phishing.

There are multiple methods of blocking lookup resources, through a method referred to as blacklists or block lists. A Real-time Blackhole List (RBL) is a list of e-mail servers that are known for allowing spam, or have open relays, and enable bad e-mail behaviors.

Sender Policy Framework (SPF)

Sender Policy Framework (SPF) validates the originating address of the e-mail. This is the originating mail server. SPF has been widely adopted by the major service providers, including Gmail, Hotmail, AOL, and Yahoo!, and works using DNS records of the sender and acts at the time of sending (see Figure 17.10).

• Figure 17.10 How SPF works

Tech Tip

Sender ID Framework

Microsoft offers another server-based solution to spam, called the Sender ID Framework (SIDF). SIDF attempts to authenticate messages by checking the sender’s domain name against a list of IP addresses authorized to send e-mail by the domain name listed. Sender ID works similarly to SPF, and works via a Sender ID TXT record in your DNS. Sender ID has not had a lot of uptake other than by Bell Canada, so in most cases it is of limited use.

DomainKeys Identified Mail

DomainKeys Identified Mail (DKIM) is an e-mail validation system employed to detect e-mail spoofing. DKIM operates by providing a mechanism to allow receiving MTAs to check that incoming mail is authorized and that the e-mail (including attachments) has not been modified during transport. It does this through a digital signature included with the message that can be validated by the recipient using the signer’s public key published in the DNS. DKIM is the result of the merging of two previous methods: DomainKeys and Identified Internet Mail. DKIM is the basis for a series of IETF standards-track specifications and is used by AOL, Gmail, and Yahoo! Mail. Any mail from these organizations should carry a DKIM signature.

The following is an example of the DKIM information that appears in an e-mail header:

The two signatures, b and bh, relate as follows:

   b The actual digital signature of the contents (headers and body) of the mail message

   bh The body hash

DLP

Data loss prevention (DLP) is also an issue for outgoing mail. Two options are available: either use an integrated DLP solution that scans both outgoing traffic and mail or use a separate standalone system. A separate standalone system has the disadvantage that one must maintain two separate DLP keyword lists. Most enterprise-level DLP solutions have built-in gateway methods for integration with mail servers to facilitate outgoing mail scanning. This allows for the checking of outgoing mail traffic against the same list of keywords that other outgoing traffic is scanned against.

Mail Encryption

The e-mail concerns discussed so far in this chapter are all global issues involving security, but e-mail suffers from a more important security problem—the lack of confidentiality, or, as it is sometimes referred to, privacy. As with many Internet applications, e-mail has always been a plaintext protocol. When many people first got onto the Internet, they heard a standard lecture about not sending anything through e-mail that they wouldn’t want posted on a public bulletin board. Part of the reason for this was that e-mail is sent with the cleartext of the message exposed to anyone who is sniffing the network. Any attacker at a choke point in the network could read all e-mail passing through that network segment.

Some tools can be used to solve this problem by using encryption on the e-mail’s content. The first method is S/MIME and the second is PGP.

S/MIME

Secure/Multipurpose Internet Mail Extensions (S/MIME) is a secure implementation of the MIME protocol specification. MIME was created to allow Internet e-mail to support new and more creative features. The original e-mail RFC specified only text e-mail, so any nontext data had to be handled by a new specification—MIME. MIME handles audio files, images, applications, and multipart e-mails. MIME allows e-mail to handle multiple types of content in a message, including file transfers. Every time you send a file as an e-mail attachment, you are using MIME. S/MIME takes this content and specifies a framework for encrypting the message as a MIME attachment.

Cross Check

S/MIME was developed by RSA Data Security and uses the X.509 format for certificates. The original specification supported both 40-bit RC2 and 3DES for symmetric encryption, and it has been extended to use AES, as 3DES has been effectively retired. The protocol can affect the message in one of two ways: the host mail program can encode the message with S/MIME, or the server can act as the processing agent, encrypting all messages between servers.

The host-based operation starts when the user clicks Send; the mail agent then encodes the message using the generated symmetric key. Next, the symmetric key is encoded with the remote user’s public key for confidentiality or is signed with the local user’s private key for authentication/nonrepudiation. This enables the remote user to decode the symmetric key and then decrypt the actual content of the message. Of course, all of this is handled by the user’s mail program, requiring the user simply to tell the program to decode the message. If the message is signed by the sender, it will be signed with the sender’s public key, guaranteeing the source of the message. The reason that both symmetric and asymmetric encryption are used in the mail is to increase the speed of encryption and decryption. Because encryption is based on difficult mathematical problems, it takes time to encrypt and decrypt. To speed this up, the more difficult process, asymmetric encryption, is used only to encrypt a relatively small amount of data, the symmetric key. The symmetric key is then used to encrypt the rest of the message.

The S/MIME process of encrypting e-mails provides integrity, privacy, and, if the message is signed, authentication. Several popular e-mail programs support S/MIME, including the popular Microsoft products Outlook and Windows Mail. They both manage S/MIME keys and functions through the E-mail Security screen, shown in Figure 17.11. This figure shows the different settings that can be used to encrypt messages and use X.509 digital certificates. This allows interoperability with web certificates, and trusted authorities are available to issue the certificates. Trusted authorities are needed to ensure the senders are who they claim to be—an important part of authentication. In Windows Mail, the window is simpler (see Figure 17.12), but the same functions of key management and secure e-mail operation are available.

• Figure 17.11 S/MIME options in Outlook

• Figure 17.12 S/MIME options in Windows Mail

While S/MIME is a good and versatile protocol for securing e-mail, its implementation can be problematic. S/MIME allows the user to select low-strength (40-bit) encryption, which means a user can send a message that is thought to be secure but that can be more easily decoded than messages sent with 3DES encryption. Also, as with any protocol, bugs can exist in the software itself. Just because an application is designed for security does not mean that it, itself, is secure. Despite its potential flaws, however, S/MIME is a tremendous leap in security over regular e-mail.

PGP

Pretty Good Privacy (PGP) implements e-mail security in a similar fashion to S/MIME, but PGP uses completely different protocols. The basic framework is the same: The user sends the e-mail, and the mail agent applies encryption as specified in the mail program’s programming. The content is encrypted with the generated symmetric key, and that key is encrypted with the public key of the recipient of the e-mail for confidentiality. The sender can also choose to sign the mail with a private key, allowing the recipient to authenticate the sender. Currently, PGP supports the public key infrastructure (PKI) provided by multiple vendors, including X.509 certificates and Lightweight Directory Access Protocol (LDAP) key sources such as Microsoft’s Active Directory.

In Figure 17.13, you can see how PGP manages keys locally in its own software. This is where you store not only your local keys, but also any keys that were received from other users. A free key server is available for storing PGP public keys. PGP can generate its own keys using either Diffie-Hellman or RSA, and it can then transmit the public keys to the PGP LDAP server so other PGP users can search for and locate your public key to communicate with you. This key server is convenient, as each person using PGP for communications does not have to implement a server to handle key management. For the actual encryption of the e-mail content itself, PGP supports International Data Encryption Algorithm (IDEA), 3DES, and Carlisle Adams and Stafford Tavares (CAST) for symmetric encryption. PGP provides pretty good security against brute force attacks by using a 3DES key length of 168 bits, an IDEA key length of 128 bits, and a CAST key length of 128 bits. All of these algorithms are difficult to brute-force with existing hardware, requiring well over a million years to break the code. Although this is not a promise of future security against brute force attacks, the security is reasonable for today.

• Figure 17.13 PGP key management

PGP has plug-ins for many popular e-mail programs, including Outlook and Mozilla’s Thunderbird. These plug-ins handle the encryption and decryption behind the scenes, and all the user must do is enter the encryption key’s passphrase to ensure that they are the owner of the key. In Figure 17.14, you can see the string of encrypted text that makes up the MIME attachment. This text includes the encrypted content of the message and the encrypted symmetric key. You can also see that the program does not decrypt the message upon receipt; it waits until instructed to decrypt it. PGP also stores encrypted messages in the encrypted format, as does S/MIME. This is important because it provides end-to-end security for the message.

• Figure 17.14 Decoding a PGP-encoded message

Like S/MIME, PGP is not problem free. You must be diligent about keeping the software up to date and fully patched, because vulnerabilities are occasionally found. For example, a buffer overflow was found in the way PGP was handled in Outlook, causing the overwriting of heap memory and leading to possible malicious code execution. There is also a lot of discussion about the way PGP handles key recovery, or key escrow. PGP uses what’s called an Additional Decryption Key (ADK), which is basically an additional public key stacked upon the original public key. An ADK, in theory, would give the proper organization a private key that would be used to retrieve the secret messages. In practice, the ADK is not always controlled by a properly authorized organization, and the danger exists for someone to add an ADK and then distribute it to the world. This creates a situation in which other users will be sending messages that they believe can be read only by the first party, but that can actually be read by the third party who modified the key. These are just examples of the current vulnerabilities in the product, showing that PGP is just a tool, not the ultimate answer to security.

Instant Messaging

Instant messaging (IM) is another technology that has seen a change in recent years. Gone are the old services of AOL Instant Messenger, and in are messaging apps that are connected to a social media app (for example, Facebook Messenger), connected to a smart device (for example, a messaging app on a phone), or provide security (for example, Wire).

IM programs are designed to attach to a server, or a network of servers, and allow you to talk with other people on the same network of servers in near real time. The nature of this type of communication opens several holes in a system’s security. One of the common issues is that the IM application will tell other users when a user is online.

Popular IM clients were not implemented with security in mind. All support sending files as attachments, few currently support encryption, and currently none have a virus scanner built into the file-sharing utility. This has created a market for a secure IM system, and several have sprung up to serve IM on the mobile device marketplace. One is called Wire, and its opening screen can be seen here.

Modern Instant Messaging Systems

Instant messaging is an application that can increase productivity by saving communication time, but it’s not without risks. The protocol sends messages in plaintext and thus fails to preserve their confidentiality. It also enables the sharing of files between clients, thus allowing a backdoor access method for files. There are some methods to minimize security risks, but more development efforts are required before IM is ready to be implemented in a secure fashion. The best ways in which to protect yourself on an IM network are similar to those for almost all Internet applications: avoid communication with unknown persons, avoid running any program you are unsure of, and do not write anything you wouldn’t want posted with your name on it.

Instant messaging also plays a role in today’s social media–driven world. Many very popular “messaging systems” are in use today, such as Snapchat, Instagram, Jabber, Tumblr, WhatsApp, and more. These are instant sharing systems that allow user bases to share files, pictures, and videos among users. Each of these systems has large numbers of users and literally billions of transferred items every year. As the social aspect of the Web grows, so do the instant sharing systems connecting users in social webs. Apple has its own messaging service, as does Android, and apps exist for a wide range of different “messaging” systems.

Any list of messaging apps will become outdated rather rapidly, but at the time this book went to press, the list included the following:

   Discord

   Facebook Messenger

   Instagram

   Skype

   Slack

   Snapchat

   Tumblr

   WeChat

The main security threat on most of these apps is information disclosure. Because they can be used from mobile devices outside of an enterprise network, there is the possibility for information to be captured and released across these platforms. For this reason, one of the security policies of high-security facilities is to not allow personal devices.

As the workforce has grown younger, new technologies have entered the workspace. Slack, shown next, is one such example. Slack is a messaging app that works to provide work teams with communication and file-sharing capabilities in real time within the enterprise.

Chapter 17 Review

Chapter Summary

After reading this chapter and completing the exercises, you should understand the following about web components, e-mail, and IM security.

Describe the functioning of the TLS protocol suite

   TLS uses a combination of symmetric and asymmetric cryptographic methods to secure traffic.

   Before a TLS session can be secured, a handshake occurs to exchange cryptographic information and keys.

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

   Web browsers have mechanisms to enable plug-in programs to manage applications such as Flash objects and videos.

   Plug-ins that block pop-up windows and phishing sites can improve end-user security by permitting greater control over browser functionality.

Describe secure file transfer options

   FTP operations occur in plaintext, allowing anyone who sees the traffic to read it.

   SFTP combines the file transfer application with the Secure Shell (SSH) application to provide for a means of confidential FTP operations.

Explain directory usage for data retrieval

   LDAP is a protocol describing interaction with directory services.

   Directory services are data structures optimized for retrieval and are commonly used where data is read many times more than written, such as ACLs.

Explain scripting and other Internet functions that present security concerns

   Scripts are pieces of code that can execute within the browser environment.

   Some scripts or code elements can be called from the server side.

Use cookies to maintain parameters between web pages

   Cookies are small text files used to maintain state between web pages.

   Cookies can be set to persistent (last for a defined time period) or session (expire when the session is closed).

Examine web-based application security issues

   As more applications move to a browser environment to ease programmatic deployment, it makes it easier for users to work with a familiar user environment.

   Browsers have become powerful programming environments that perform many actions behind the scenes for a user, and malicious programmers can exploit this hidden functionality to perform actions on a user’s PC without the user’s obvious consent.

Describe security issues associated with e-mail

   Malicious code is code that performs something harmful to the computer it runs on. Malicious code is often sent through e-mail.

   Viruses are pieces of malicious code that require user action to spread.

   Worms are pieces of malicious code that use automated methods to spread.

   Spam, or unsolicited commercial e-mail, is e-mail that is sent to you without you requesting it, attempting to sell you something. It is the electronic equivalent of a telemarketing call.

   Hoax e-mails are e-mails that travel from user to user because of the compelling story contained in them.

Implement security practices for e-mail

   Protecting your e-mail system from virus code requires several measures:

   Don’t execute any attachment from an unknown source.

   Use antivirus programs that run on the server to filter all e-mails.

   Use client-side antivirus programs to catch any viruses that might come from web-based e-mail accounts.

   Keeping all software up to date helps to prevent worm propagation.

   Server-side filtering software and the application of Spam Blackhole Lists help limit the amount of unsolicited e-mail.

   E-mail encryption is a great way to protect the privacy of communication since e-mail is a cleartext medium.

   PGP, or Pretty Good Privacy, is a good specific application for e-mail encryption.

   S/MIME, or Secure/Multipurpose Internet Mail Extension, is the e-mail protocol that allows encryption applications to work.

   Antivirus software is important to protect against malware.

Detail the security issues of instant messaging protocols

   The most popular IM programs all send messages in the clear, without native encryption built into the default clients.

   All the IM clients need to attach to a server to communicate. Therefore, when attached to the server, they announce the source IP of a particular user.

   Instant messaging can also be used to transfer files. This activity typically bypasses any security built into the network, especially mail server virus protections.

Key Terms

Active Server Pages (ASP) (663)

ASP.NET (663)

Authenticode (666)

botnet (675)

browser extension (665)

browser helper objects (BHOs) (666)

code signing (667)

cookie (663)

DomainKeys Identified Mail (DKIM) (684)

e-mail (670)

e-mail hoax (674)

File Transfer Protocol (FTP) (658)

Hypertext Markup Language (HTML) (650)

inlining (667)

instant messaging (IM) (689)

Internet Engineering Task Force (IETF) (652)

Java (661)

JavaScript (661)

Lightweight Directory Access Protocol (LDAP) (657)

mail delivery agent (MDA) (672)

mail relaying (682)

mail transfer agent (MTA) (672)

mail user agent (MUA) (672)

Multipurpose Internet Mail Extensions (MIME) (673)

open relay (682)

PHP (663)

plug-in (665)

Pretty Good Privacy (PGP) (687)

Real-time Blackhole List (RBL) (683)

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

Secure Sockets Layer (SSL) (652)

Sender Policy Framework (SPF) (683)

server-side scripting (663)

Simple Mail Transfer Protocol (SMTP) (671)

spam (675)

SSL stripping attack (657)

Transport Layer Security (TLS) (652)

Uniform Resource Locator (URL) (650)

unsolicited commercial e-mail (675)

X.500 (657)

Key Terms Quiz

Use terms from the Key Terms list to complete the sentences that follow. Don’t use the same term more than once. Not all terms will be used.

1.   Spam is the popular term for _______________.

2.   _______________ is a method for detecting e-mail spoofing.

3.   A large source of spam is zombie computers that are part of a(n) _______________.

4.   _______________ is the protocol used to add attachments to an e-mail.

5.   A(n) _______________ is a compilation of servers that are blocked because they have been known to send spam.

6.   _______________ allows outside users to send e-mail via your mail servers—a risky practice to allow.

7.   _______________ is a protocol for verifying e-mail addresses using DNS records to reduce spam.

8.   A(n) _______________ is a small application program that increases a browser’s ability to handle new data types and add new functionality.

9.   _______________ can have the same virus risks as e-mail.

10.   The most prevalent protocol that e-mail is sent by is _______________.

Multiple-Choice Quiz

1.   What is one of the biggest reasons spam is prevalent today?

A.   Criminals use zombie botnets.

B.   Regular mail is too slow.

C.   Spam is popular among recipients.

D.   Spam is sent from the government.

2.   What does the keyword [secure] in a cookie do?

A.   It causes the system to encrypt its contents.

B.   It prevents the cookie from passing over HTTP connections.

C.   It tells the browser that the cookie is a security upgrade.

D.   None of the above.

3.   Why is an open e-mail relay bad?

A.   It allows anyone to remotely control the server.

B.   It makes the e-mail server reboot once a day.

C.   No e-mail will go through.

D.   It will allow anyone to send spam through the server.

4.   Security for JavaScript is established by whom?

A.   The developer at the time of code development.

B.   The user at the time of code usage.

C.   The user through browser preferences.

D.   Security for JavaScript is not necessary—the Java language is secure by design.

5.   What is code signing used to do?

A.   Allow authors to take artistic credit for their hard work

B.   Provide a method to demonstrate code integrity

C.   Guarantee code functionality

D.   Prevent copyright infringement by code copying

6.   Why are instant messaging protocols dangerous for file transfer?

A.   They bypass server-based virus protections.

B.   File sharing is never dangerous.

C.   They allow everyone you chat with to view all your files.

D.   You’ll end up receiving many spam files.

7.   Why do PGP and S/MIME need public key cryptography?

A.   Public keys are necessary to determine whether the e-mail is encrypted.

B.   The public key is necessary to encrypt the symmetric key.

C.   The public key unlocks the password to the e-mail.

D.   The public key is useless and gives a false sense of privacy.

8.   Why is HTML e-mail dangerous?

A.   It can’t be read by some e-mail clients.

B.   It sends the content of your e-mails to web pages.

C.   It can allow the launching of malicious code from the preview pane.

D.   It is the only way spam can be sent.

9.   If they are both text protocols, why is instant messaging traffic riskier than e-mail?

A.   More viruses are coded for IM.

B.   IM has no business purpose.

C.   IM traffic has to travel outside of the organization to a server.

D.   Emoticons.

10.   TLS provides which of the following functionalities?

A.   Data integrity services

B.   Authentication services

C.   Data confidentiality services

D.   All of the above

Essay Quiz

1.   How would you implement a successful spam-filtering policy?

2.   Draft a memo describing malware risks to the common user and what the user can do to avoid infection.

Lab Projects