CHAPTER 21

WEB-BASED VULNERABILITIES

Anup K. Ghosh, Kurt Baumgarten, Jennifer Hadley, and Steven Lovaas

21.1 INTRODUCTION

21.2 BREAKING E-COMMERCE SYSTEMS

21.3 CASE STUDY OF BREAKING AN E-BUSINESS

21.4 WEB APPLICATION SYSTEM SECURITY

21.5 PROTECTING WEB APPLICATIONS

21.6 COMPONENTS AND VULNERABILITIES IN E-COMMERCE SYSTEMS

21.6.1 Client-Side Risks

21.6.2 Network Protocol Risks

21.6.3 Business Application Logic

21.6.4 CGI Script Vulnerabilities

21.6.5 Application Subversion

21.6.6 Web Server Exploits

21.6.7 Database Security

21.6.8 Platform Security

21.7 SUMMARY

21.8 FURTHER READING

21.9 NOTES

21.1 INTRODUCTION.

This chapter systematically reviews the primary software components that make up Web applications, with a primary focus on e-commerce, and provides an overview of the risks to each of these components.¹ The goal of this chapter is to point out that every system will have risks to its security and privacy that need to be systematically analyzed and ultimately addressed.

21.2 BREAKING E-COMMERCE SYSTEMS.

To make a system more secure, it may be advisable to break it. Finding the vulnerabilities in a system is necessary in order to strengthen it, but breaking an e-commerce system requires a different mind-set from that of the programmers who developed it. Instead of thinking about developing within a specification, a criminal or hacker looks outside the specifications.

Hackers believe that rules exist only to be broken, and they always use a system in unexpected ways. In doing so, they usually follow the path of least resistance. Those areas perceived to provide the strongest security, or the most resistance to hacking, will likely be ignored. For example, if a system uses Secure Sockets Layer (SSL) to encrypt Web sessions between Web clients and the Web server, a hacker will not try to break the encryption stream but instead will look for an easier way to get at the data after they are decrypted and stored in the clear.

Hackers go where the money is—sometimes literally, sometimes not. They typically try to hack into a site only if there is some reward for their effort. Sometimes hackers are motivated by money, but as often the motivation is the lure of fame, notoriety, or acceptance by a peer group. The level of protection should be commensurate with the value of the resource being protected. For instance, a Web site that publishes the menus for local restaurants may not be seen as a target for a denial of service or any other type attack. Such a Web site simply is not as attractive a target as a bank's online Web site, where a hacker can certainly gain in notoriety and even profit financially. Similarly, most people do not bother encrypting e-mail messages due to lack of security awareness, and because most potential snoopers are not interested in ordinary personal e-mail. Sensitive e-mail from a high-profile organization should be encrypted, however, in order to protect valuable intellectual capital.

It is important to remember that the e-commerce system is a chain that is only as strong as its weakest link.² Hackers naturally attempt to attack that point of least resistance. This explains why a site may deliberately set up a honeypot (a sacrificial system) with appealingly vulnerable services in order to track and monitor potential hackers. In e-commerce, or any systems with a Web presence, cryptography often is perceived to provide the strongest level of protection; thus, hackers generally attack host-side services and client-side content.

Maintaining strong host security, both inside and outside of perimeters, is critically important. One unfortunate side effect of corporate perimeters is that system administrators tend to overlook host-based security, which may leave the host completely vulnerable. The result is that once hackers make it through or around perimeter devices and policies (e.g., firewalls, routers, or even receptionists), they can leverage the internal trust relationships to compromise many resources including workstations, servers, and phone systems. The prudent administrator will exercise equal concern both at the entry to systems and within those systems.

21.3 CASE STUDY OF BREAKING AN E-BUSINESS.

Consider an online investing e-business application and how a hacker might go about disassembling its security for malicious or financial gain. Online investing is very popular for several reasons. Rather than waiting for quarterly statements in the mail or dealing with a phone menu, customers can quickly view the status, balances, and current value of investment holdings by visiting the Web pages of their portfolio managers. If they wish to buy and sell equity shares on demand, they can establish online Web-enabled brokerage accounts. Exhibit 21.1 shows a simplified workflow diagram of an online investing application that enables users with established accounts to view portfolio holdings and cash balances, to update the stocks tracked, and to conduct online trades.

To see how this application can be broken, it is helpful to look at a sample network architecture that implements the online application. Exhibit 21.2 shows the network architecture of the system that implements the online investing application, along with example exploits. The system consists of the end users' client machines, the Internet, routers, firewall, front-end Web and e-mail servers, application servers, databases, and workstations.

There are many ways a hacker could break this online application. Exhibit 21.2 shows one possible scenario. In step 1 of the attack, the hacker uses the Internet and a Web browser to misuse one of the CGI (Common Gateway Interface) scripts that invoke the application on a server. The CGI script could be a development CGI script inadvertently left on the server before going into production, a default CGI script from an application server distribution, or a script that implements flawed logic in the online investment application. Exploiting CGI scripts via cross-site scripting or other common exploit methods allow hackers to gain shell access to Web servers. CGI script vulnerabilities are discussed later in this chapter.

EXHIBIT 21.1 Online Investing Application

EXHIBIT 21.2 Breaking an E-Business

The vulnerability need not be in a CGI script. Application servers can be implemented in Java, C, C++, Perl, or Python in various application server frameworks. The difficulty lies not in which language the business application logic is developed; more important are the vulnerabilities introduced by the complex logic at this middleware layer. One of the key problems in the development of application middleware is poor input sanity checking; that is, the developers fail to impose limits on acceptable input. The hacker can exploit the lack of input sanity checking to feed the application server unexpected input used in system commands. This technique can gain shell privileges on the machine.

Although application server misuse is a common way of breaking into systems, there are many other ways to gain the initial access in step 1 of the attack. For instance, the Web and mail servers may be running any of several network services, such as FTP and BIND/DNS, which may be misconfigured and thus “poisoned.” The Web and mail server software themselves may be vulnerable to attack. Many popular commercial Web and mail servers have been vulnerable to buffer overflow attacks that often permit full system root privileges on the host.³ Once attackers gain system privileges on an internal host, they can exploit the inherent internal trust often woven among machines through network policies in order to gain access to other systems on the network. This strategy is precisely what the attacker follows in step 2 of the attack illustrated in Exhibit 21.2.

Once attackers have access to the various file systems on the application server, they can view source code of CGI scripts or other application middleware to discover customer account numbers, passwords, and even database administrator passwords for accessing the back-end databases. From there, they can download important and confidential client information stored in the database. In step 3 of the attack, the attacker leverages the internal privileges gained to plant backdoors into the system unnoticed. A suite of software, commonly known as a rootkit and available to hackers, allows them not only to get into a system unnoticed but also to erase their tracks in audit logs. In the example shown, the hacker installs a rogue remote administration program known as Back Orifice, which provides the ability to remotely administer the host and network with the same privileges and power as an authentic system administrator.

At this point in the attack, the hacker has assumed total control of the systems and any Web-facing or commerce-related processes, with many options including:

• Stealing customer or company information for the purpose of financial gain
• Defacing the Web pages for notoriety or to publicize an agenda
• Working in a stealthy manner to uncover proprietary business information and other confidential intellectual capital (espionage)
• Blackmailing the business with threats of discrediting it
• Subverting the application for any other personal gain

Step 4 of the attack illustrates the last case, where the attacker credits a personal cash account. The hacker must move quickly enough to withdraw these funds before traditional back-end auditing discovers the discrepancy. There have been many defaced Web pages of government agencies, and other important sites, and many reported instances of the other cases. Of course, some companies are understandably reluctant to publicize events that might lessen customer confidence, yet in many cases, legislation now requires the disclosure of a breach.

Unfortunately, it takes only a single flawed, unpatched computer, or overlooked vulnerability, for a hacker to compromise a system as a whole. Although defense-in-depth (using multiple forms of security, such as firewalls on the perimeter and intrusion detection inside the network) is a popular strategy, often multiple layers of defense fall like a house of cards when a single hole is exploited. For example, an attacker who gains root capability can disable all other security measures. The problem is known as an asymmetric attack because it is much more difficult and costly to defend against such an attack than to launch one. Although a committed hacker may be capable of spending as much time as is needed to break into a system, a company cannot spend as much money as needed to defend itself against all possibilities.

The number of flaws that can be exploited is staggering, considering all the different platforms and devices that make up current information technology (IT) infrastructures. Compounding the problem is the fact that a hacker can work in relative anonymity using a $500 computer and modem to launch attacks. Even worse, hackers can work from any number of Internet kiosks available in airports, malls, cafés, and even laundries. As hackers get more sophisticated, and as more easily utilized scripts become available, attacks will be launched from mobile devices that can roam in and out of different geographic zones and then be discarded—making tracking of the attacker next to impossible.

21.4 WEB APPLICATION SYSTEM SECURITY.

In spite of the fairly bleak picture painted here, organizations can effectively manage their risk from hackers. As in many other security domains, the security posture or stance assumed by the organization is critical for deterring and thwarting hackers. To use a physical-world analogy, consider burglars who intend to break into homes in a nice neighborhood. As the burglars scope out potential targets, they will notice some houses with burglar alarms—complete with conspicuous signs of the alarm systems—and some without. In all likelihood, the burglars will bypass the houses with the burglar alarms and move on to the other, less well-protected targets. Thus, the security stance assumed by the owner plays an important role.

Every organization must first determine its desired security stance as documented in its security policy. System administrators use the security policy to configure the systems, routers, firewalls, and remote access solutions. Without an explicit security policy, there is no way to determine what the security stance of the organization is, how to configure its systems, or even if a nonobvious security breach has occurred. Once the security policy is developed, the actual security implementation must be assessed. That is, the system must be tested and evaluated to determine how well it meets its security policy. Usually there is a difference between the desired stance and the actual stance. This difference is the security gap between where the organization would like to be (secure against particular threats) and where it actually is in practice.

The process of developing a security policy and evaluating the organization's systems against that policy will identify not only the gaps between the actual security stance and the desired posture but also weaknesses in the security policy itself. It is important to have an independent party, preferably an outside party, evaluate the security stance of the organization. A third party can fairly assess whether the organization's system upholds the security policy. If the group that develops the security policy or the system configuration is also responsible for evaluating it, the evaluation may be biased, and potential vulnerabilities may be overlooked. This may occur not through ill will or dishonesty but rather because of the difficulty of being objective about one's own work.

EXHIBIT 21.3 Layered View of an E-Business Application

21.5 PROTECTING WEB APPLICATIONS.

Web application security can be understood from different views. First, consider the view of e-businesses in Exhibit 21.3. The diagram shows two e-businesses communicating over the Internet, perhaps performing business-to-business types of transactions.

In this view, the lowest layer of the e-business is the networking layer. At the networking layer, there are concerns about the reliability, integrity, and confidentiality of the data that runs over the communications channel. This layer is of particular concern because the Internet is a public switched network, meaning that any number of third parties may have access to the data that traverses the nodes of the Internet on the way from the data source to its destination. Also, the Internet Protocol (IP) is a connectionless protocol, which means there is no dedicated circuit between source and destination. As a result, packets sent during a given session may take different routes to their destination, depending on traffic congestion and routing algorithms. Because IP is an unreliable datagram protocol (i.e., IP uses independent packets forwarded from node to node, but there is no guarantee of successful transmission), the networking layer includes a connection-oriented reliable transmission layer such as TCP (Transmission Control Protocol) that ensures that dropped or lost packets are retransmitted and that bit flips that may have occurred during transmission (e.g., over wireless networks) are corrected.

Although TCP/IP provides for more reliable delivery of Internet packets, IP version 4 does not provide secure connection services. Typically, this means that there is no guarantee of confidentiality, identification, or even delivery of packets sent from one Internet host to another. Because packets often traverse several Internet nodes from source to destination, packet contents can be intercepted by third parties, copied, substituted, or even destroyed. This is the risk that most people citing risks of e-commerce have decried; they have overlooked the more substantive risks of e-commerce dealing with server- and client-side security and privacy. IPv6 holds promise to bring many security improvements to the network layer, but it has not been deployed widely in the United States. Fortunately, even in IPv4, we have good solutions to the data confidentiality problem. Cryptographic techniques can provide strong guarantees for data confidentiality, authentication of parties, and integrity of data sent during the transmission. Furthermore, digital signatures can be used to sign received mail in a “return receipt” application that provides guarantees of delivery of e-mail. Thus, as shown in Exhibit 21.3, we can use encryption services to protect data transmitted over the network.

The operating system (OS), or platform, that hosts the Web applications lives on the networking layer. In a layered model, the services of one layer use the services of the lower layer and provide services to upper layers. The network layer often is thought of as a core portion of the operating system; however, from a layered services point of view, the OS software runs on top of the network layer.

Operating systems are notoriously rife with software flaws that affect system security. Operating systems are vulnerable because commercial OSs today are immensely complex; for instance, the Windows Vista operating system is purported to have more than 50 million lines of source code. It is impossible to catch all software design and programming errors that may have security consequences in a platform this complex. Even though UNIX operating systems have been in use for the better part of 30 years, new flaws in OS utilities are found on a weekly basis across all the different UNIX platform variants.⁴

Security holes in the platform are critical by nature. That is, if the OS itself is vulnerable to exploitation, security provided by the application can be compromised by holes in the platform. The OS is always the foundation on which applications are built, so cracks in the foundation make for weak security at the application layer. As Exhibit 21.3 suggests, firewalls provide protection against some operating system flaws. One of the key roles of firewalls is their ability to shut down services offered to logical domain addresses.

Using Internet domain addresses, the firewall administrator can partition Internet addresses into trusted and untrusted domain ranges. For instance, any Internet address outside the company's domain can be considered untrusted. As a result, all OS services, such as remote logins, can be shut down to everyone outside of the company's domain. Even within a company, the domains can be partitioned so that certain subdomains are trusted for access to certain machines, but others are not. The key benefit then of firewalls is their ability to restrict access to the platform through offered services (i.e., specific functions that pass data through the firewall). As a result, firewalls can make it easy to hide OS flaws from untrusted entities.

Even so, firewalls are vulnerable to data- or code-driven attacks through offered services. These are sometimes called “allowed path” vulnerabilities. For instance, an attack through SMTP (mail) or HTTP (Web) will not be stopped by a firewall if the firewall is configured to let e-mail and Web services through, as is necessary for e-commerce. Firewalls also will not stop OS exploits from insiders or from the trusted entities that are granted access to the platform. However, it is important to realize that firewalls, if properly configured, can close down exposure to a significant number of platform vulnerabilities simply by denying untrusted outsiders access to platform utilities and services. Exhibit 21.3 illustrates reasonable protection from network- and platform-based attacks but not from application and database attacks. The database layer is shown separately in the diagram because of the importance of its role in e-commerce; however, database attacks usually can be considered as a type of application attack.

Application-based attacks represent a critical issue that is gaining more attention in recent years. There is no simple solution, but there is a growing sense that the security provided by a firewall, an SSL-enabled Web site, and encryption, together with digital certificates and signatures, is not enough. These measures are necessary but not sufficient. Applications, above all, are the online business. The Payment Card Industry Data Security Standards (PCIDSS) puts any organization processing credit card transactions on notice that Web application vulnerability protection was required as of June 2008. The PCIDSS specifies either “having all custom application code reviewed for common vulnerabilities by an organization that specializes in application security” or “installing an application layer firewall in front of Web-facing applications.”⁵

Online applications are increasingly sophisticated, and the software that implements the application logic has become highly complex, requiring component-based and object-oriented paradigms such as Enterprise Java Beans, CORBA, and DCOM/COM services. Collectively, these are known as application servers. The key point, however, is that because the application logic is custom and complex, it is often rife with errors in implementation or logic that can be and often are exploited by hackers.

Application security must not be confused with marketing claims. A secure online application is one that is resistant to attacks. It is not simply one that authenticates end users, encrypts transaction data, provides nonrepudiation of transactions, and guarantees service. These are all matters of importance that address characteristics of the transaction, not properties of the software. The remainder of this chapter addresses the software problem in some detail. The next section provides a different view of e-commerce systems from the layered view discussed previously. It identifies vulnerabilities in the different software components and strategies for managing the risks.

21.6 COMPONENTS AND VULNERABILITIES IN E-COMMERCE SYSTEMS.

Exhibit 21.4 shows a generic multitier architecture of an e-business, together with a summary of the types of vulnerabilities and risks to each of the major components. Using the Internet, Web clients (running on PCs or handheld devices) interface with a front-end Web server, a middleware layer of business application logic, back-end databases, an ERP system, supply-chain management software, and even some legacy systems that are now brought to the Internet.

21.6.1 Client-Side Risks.

Most e-commerce is performed using standard Web browsers and mail clients. Increasingly, e-commerce is being performed on handheld mobile devices such as personal digital assistants (PDAs) and mobile phones. The security risks particular to wireless devices are covered in Chapter 33 of this Handbook. Client-side security risks are mainly from malicious mobile code such as Web scripts, ActiveX controls, and hostile Java applets.⁶ Another major risk in client-side software is loss of privacy.⁷ Each computer, with its related software, receives and transmits a great deal of personal identifying information (PII). For instance, browsers may convey information about the computers (name, IP address, browser type, version, company name) and sometimes about the users themselves, particularly if automatic form-filling features have been enabled. Browsers also are used to track movements through the Web. For instance, every Web site the browser visits typically gets a record of the previous site from which the user entered. Banner ads in Web pages also track which sites have been visited in order to create a profile of Web usage, and cookies can be placed on end-user systems for the purpose of tracking and at times re-creating user input.

EXHIBIT 21.4 Multitier Architecture of an E-Business

A class of more insidious programs, known as spyware, can send information about computer usage out to specific sites, often without the user's knowledge or approval. One of the key risks with client-side software is that users simply do not know what the programs are revealing about themselves, or to whom. A simple principle is that a program should not be sending out any data that the user does not know about. An audit of the programs on any given machine probably would reveal that quite a few are in violation of that principle. Although most spyware programs are written to provide marketing data for software vendors or to redirect a user to predetermined sites, many manipulate and target users more effectively by spying on usage activity and even installing additional malicious code. For example, SpectorSoft markets a spyware tool known as eBlaster to people who suspect their spouses are engaging in illicit online affairs. This type of spyware program spies on user activity, from keystrokes to screen shots, and sends a log of the activity out over the network to a predetermined logging site. Spyware can be identified using diagnostic programs such as Ad-Aware from Lavasoft (www.lavasoft.com), but because of the dynamic nature of spyware technology, it may be difficult to identify all possibilities of infection.

A final client-side risk that businesses need to be especially concerned about is the risk of malicious executables that run on their user workstations. The desktop machine is like a petri dish for software: It is constantly changing and growing with new software executables—some of an unsavory nature. Malicious software, or malware as it is now known, finds many ways of infecting machines. For instance, one common way of disseminating malicious software is via e-mail attachments. Another is by masquerading as legitimate software on a Web page available for download. Users often upload and download software to and from internal network file shares. In addition, USB “thumb drives” and even old-fashioned floppy disks are still a viable way of transmitting malicious software. The Back Orifice “remote administration kit” is a well-known example of malicious software that, when installed, will allow anyone—including a hacker—to administer and control a machine remotely. Some malware products, running on an internal machine, may compromise the entire network because a remote hacker can control a trusted resource, possibly with enterprise administration rights. Data leakage and theft offered by the initial spyware infection can result in incidents that might undermine the integrity, authenticity, availability, or auditability of an entire data infrastructure. It is essential, therefore, that corporations carefully filter and closely monitor the application software that is downloaded and run (with or without the user's knowledge) on all systems from the e-commerce perimeter to the individual internal hosts.

21.6.2 Network Protocol Risks.

Network risks primarily arise from sending confidential data over the Internet—a public, packet-switching network. Many good protocols address the risks of sending confidential data over the Internet.⁸ In fact, a few years ago, the list included:

• SET
• SSL
• S/HTTP
• S/MIME
• CyberCash

Although some of these protocols are still around in one form or another, the industry has generally accepted SSL as the protocol of choice for secure Web browser transactions. The objective of most secure network protocols is to layer security properties on top of the TCP/IP network layers. Although TCP/IP provides reliable and robust delivery of datagrams over the Internet, it does not provide confidentiality, authentication, or strong message-integrity services. These are the properties that secure protocols provide. Some go even further. For instance, SET-compliant protocols leave the credit card number encrypted even at the merchant site. Since the merchant does not need to know the consumer's credit card number, by hiding the number from the merchant, a significant portion of credit card fraud can be eliminated. Rather than decrypting the credit card number at the merchant site, it is passed in encrypted form from the merchant to the credit-issuing bank. There it is decrypted, and the merchant's account is credited the amount of the purchase. The protocol details of SET, SSL, and other e-commerce protocols are described in Chapter 30 of this Handbook, in E-Commerce Security: Weak Links, Best Defenses, and in other books as well.⁹

Depending on the needs of an online business application, there is a requirement for more or less of the security properties afforded by secure protocols. For most Web browsing, a secure protocol is unnecessary; the standard Web protocol, HTTP, suffices. However, when customers send confidential or personal information to a site, a secure protocol that encrypts the data is preferable. The de facto secure protocol standard is SSL, now implemented in every standard Web browser. SSL will not only negotiate a secret session key between the Web site and a client to encrypt the data, but it also will authenticate the Web site. The Web site must have a valid certificate endorsed by a Certificate Authority, which the users implicitly trust. Using a list of trusted Certificate Authorities maintained within the client browser, access can be prevented to other, untrusted sites. Once the connection is established, the user can verify that the Web site is, in fact, the one intended by examining the site certificate. Users rarely do this in practice, but the certificate is available and should be more widely utilized.

These secure properties—that is, encrypted sessions and host site authentication—serve the purpose for most online commerce applications. Some applications, though, may demand even stronger security services. For instance, banking and investment applications often transmit highly confidential information, with the possibility of huge financial losses through inadvertent error or intentional fraud. These types of transactions require not only confidentiality of the data, but also authentication of the client. A financial institution must never give access to account information or permit transactions without authenticating the user.

Common identification schemes on the Internet include simple user name and password authentication. A much more secure solution is to require strong client authentication using client certificates. SSL supports client certificates, although sites rarely use this capability because it involves requiring customers to obtain a certificate from a Certification Authority.

In the future, e-commerce protocols will need to be increasingly sophisticated if they are to meet the stringent security and privacy requirements of new Internet applications. For example, as criminal, medical, patent, and other important databases migrate to the Internet, the protocols developed for accessing them need to consider the security and privacy needs of the database owners and maintainers, as well as those of the client or requester. Today, the progress in genomics is producing much information about the likelihood of developing deadly disease based on a genetic DNA sequence. This knowledge raises moral and ethical questions as to how much information about potential diseases should be revealed to doctors and patients, and also raises the specter of such information getting into the wrong hands once it is accessible on the Internet.

Consider the case of a doctor querying an online genetic disease database with a patient's DNA sequence. The online application attempts to match the DNA sequence with diseases that might develop in the future. If the database were maintained by a commercial entity such as an insurance provider, the patient almost certainly would not want the company to know of any disease that might be returned as the result of a query, because that information could be used to deny both insurance and employment.

Likewise, the database maintainer probably would not want to know of the query or of its result, as such knowledge might put it at risk for lawsuits, should the information be leaked. Furthermore, the database maintainer would want the rest of the database to remain inaccessible except for specific results returned to an approved inquiry. Preventing access to any other information in the database would help to protect the commercial interests of the company, because then the database could not be duplicated easily. Nor could queries be made without a cost-tracking mechanism. To support this dual model of secure and private information access, e-commerce protocols need to be developed and commercialized that not only encrypt data in transmission but also consider the total security and privacy needs of both parties to the transaction.

Another e-commerce application area that will require better security and privacy protocols involves applications that accept e-cash or digital coin payments. Currently, most online payment schemes use either credit or debit cards, with payments made from the buyer's checking account at a bank. Payments are made either with online verification of funds or with off-line batch payments at the end of the day. A number of applications, particularly those involving payments of a few dollars or even pennies, are being created that cannot support the costs of a bank-based transaction.

Many commercial services and products, such as vending machines and parking meters, are coin-activated and do not require customers to have an account or a line of credit. Although efforts are being made to convert such services to computerized devices, with micropayment capabilities, it will be many years before this is actually accomplished. In any case, there will always be customers who want to pay with cash or its electronic equivalent, so that the transaction cannot be tracked by a third party, such as a bank or a creditor.

Newer online applications for micropayments may include collecting fees for downloading music, data, weather reports, stock quotations, articles from magazines, and pages from books. Many of these applications are provided today without charge and supported by banner advertising, but a concern for profits is motivating most Web sites to seek additional sources of income. Whatever the application, there is a need for cash-based alternatives to the current account-based system for making payments. The key security and privacy concerns are with ensuring that e-cash is properly spent and accounted for and that anonymity is preserved throughout. Several protocols have been developed with these goals in mind, but none has reached commercial success or adoption by the vendor community. As mobile e-commerce begins to drive more traditionally cash-based transactions (e.g., parking meters, vending machines, and ticket booths), wireless vendors may adopt these new digital cash-based protocols.

Regardless of the network protocol used in an e-commerce application, the key concern is for those attackers who will attempt to breach the easiest obstacle in their quest to obtain system privileges and unauthorized access to data. If the security provided by the network protocol is perceived to be strong, attackers will look for alternatives that bypass the network security. For instance, these types of standard attacks from the hacker's toolkit will bypass the security provided by most e-commerce protocols:

• Man-in-the-middle attacks. Capturing transmissions in transit for eavesdropping or forgery
• DNS attacks. Altering records in the worldwide Domain Name System to misdirect connections to the wrong addresses
• War dialing. Automated testing of every phone number in a block of numbers
• Exploiting software vulnerabilities in network services. Such as FTP, Bind, SMTP, and HTTP servers
• Internal access. Improper use of authorized access by an insider (employee, contractor)
• Leveraging trusted hosts. Attacking from another system that has a privileged relationship with the target system
• Brute-force crypto attacks. Automated testing of all possible decryption keys to decipher a ciphertext

In summary, it is important not only to select the appropriate network protocol for each online application but also to avoid a false sense of security that might arise from use of a “secure” network protocol. Good security engineering will consider vulnerabilities in other components of the system that are more attractive targets to determined hackers.

21.6.3 Business Application Logic.

The business application logic pictured in Exhibit 21.4 represents one of the key areas of vulnerability in e-commerce systems. The program logic encodes what the online business is offering in terms of products, services, and customer convenience. It also defines the look and feel of the Web site and provides all of the interactive features, such as dynamic Web pages, personalized Web pages, and online transaction capabilities. Because each application is unique, the software that implements the logic must be, in many cases, custom-developed for each particular site.

In contrast, most of the other software components of a Web site are commercial off-the-shelf (COTS) software. For instance, the Web server, back-end databases, and supply-chain logistics software are often purchased off the shelf from software vendors. With COTS software, the end user has no control over the code and therefore is not responsible for coding bug fixes. When software bugs in COTS software are discovered, the software vendor usually issues a patch or incorporates a bug fix in the next release version. Software vendors can fix discovered bugs, but they depend on customer sites to actually apply the patches or upgrades to the software. In practice, this occurs less often than desired and is a significant reason why many Internet-based systems are vulnerable.¹⁰ The most important task in securing COTS software systems is to make sure that: (1) they are properly configured for a secure installation according to the site's security policy, (2) the software is properly updated to the current version and patch level, and (3) administrators are aware of the risks associated with bugs in the software.

Because many business applications are custom-developed, either by an in-house staff or by outsourcing to an e-business developer, the programs represent a key risk for several reasons. The dynamic, interactive nature of e-businesses, coupled with increasingly sophisticated online services, requires a significant amount of development to code the logic. As a result, the application programs tend to be very complex pieces of software, likely to contain flaws, and susceptible to the kinds of attacks launched against Web sites. In practice, errors in design and implementation of business application logic often compromise the security of an e-business.

Traditionally, the middle tier of software is implemented on Web servers using the Common Gateway Interface (CGI) and more recently PHP (Hypertext Processing). CGI and PHP scripts are programs that run on the Web server machine as separate processes from the Web server software. The Web server invokes these general-purpose programs in response to user requests. The CGI/PHP script's main function is to process user input and to perform some service, such as retrieving data or dynamically creating a Web page for the end user. Because CGI and PHP scripts process untrusted user input, the security risks associated with them and other forms of middle-tier software are extremely high. Many attacks against Web-based systems are implemented by exploited CGI/PHP scripts. And while CGI and PHP scripts can be written in any general-purpose programming language, they are written most often in Perl, C, Tcl, and Python.

More recently, component-based software (CBS) is making inroads in e-commerce applications as well as in standard Web applications. The purpose of CBS is to develop, purchase, and reuse proven software in order to implement application logic quickly, easily, and with high quality. Two of the more popular component frameworks for e-commerce applications are Enterprise JavaBeans (EJB) using XML and Java 2 Enterprise Edition (J2EE), which supports component-based Java. Other component models include the Object Management Group's (OMG) Common Object Request Broker Architecture (CORBA) and Microsoft's Common Object Model (COM) and Distributed COM (DCOM). These component frameworks are the glue that enables software components to use standard infrastructure services while hiding the details of the implementation by using well-defined interfaces.

Business application logic, when coded in CBS systems, usually runs on application servers with particular component models, such as EJB, CORBA, COM, and DCOM. CBS also provides an interface to back-end services such as database management, enterprise resource planning (ERP), and legacy software systems.

In addition to supporting traditional CGI functions, component-based software is expected to enable distributed, business-to-business applications over the Internet. The component-based software paradigm also supports good software engineering, as described later. The Unified Modeling Language (UML) facilitates object-oriented analysis and design for component-based frameworks. In addition, as the market for component-based software expands, many standard business application components will be available for purchase off the shelf.

Although the benefits of component-based software are numerous, they pose security hazards similar to those of CGI scripts. Component-based software enables development in general-purpose programming languages such as Java, C, and C++, which can execute with all the rights and privileges of server processes. Like CGI, they process untrusted user input, and because component-based software can be used to build sophisticated, large-scale applications, the likelihood for errors may be even greater than for simple CGI scripts. Regardless of the implementation—CGI or application servers—the security risks of server-side software are great, and therefore server-side software must be designed and implemented carefully.

The key risks in the middleware layer of e-commerce sites are:

• Misconfiguration of the CGI
• Default and development CGI scripts being left on the production server
• CGI misuse
• Application subversion
• Flawed logic
• Programming errors

21.6.4 CGI Script Vulnerabilities.

CGI scripts are frequent targets of attackers because they are often misconfigured and vulnerable to misuse.¹¹ When designing CGI scripts, it is prudent to expect the unexpected, particularly the malicious attack. Although the Web designer has control over the content of CGI scripts, there is no control over what end users are going to send to them. Also, often overlooked are vulnerabilities of CGI scripts that exist on the server as part of the distribution but that are not actually used in the application. Some CGI scripts, included as part of the Web server distribution, have well-known flaws that can be exploited to obtain unauthorized access to the server. Even if the default CGI scripts are not used as part of the Web server pages, anyone can access them by simply knowing the script names.

One of the most common—yet easily preventable—security hazards is misconfiguration of software, especially CGI scripts. One feature supported by many Web servers is the ability of individuals throughout an organization to write CGI scripts and have them execute from their own directories. Although useful for prettying up personal Web pages, this feature also can introduce system security hazards. In Web-based applications, the Web server should be configured to prevent CGI scripts from executing anywhere but in a single CGI directory under control of the system administrator.

The script-aliased CGI mode for Web servers ensures that CGI scripts will execute only from an explicitly named directory in the server configuration file. In addition, the CGI script path is not named in the URL to the CGI. Rather, the server “aliases” the explicit path to the CGI script to a chosen name, such as cgi-bin. Thus, running the server in script-aliased CGI mode prevents rogue CGI scripts from executing while it also hides the explicit path to the CGI scripts.

The CGI script directories also should be properly configured using OS access controls. For instance, if CGI scripts are written in a compiled language such as C, the script sources should be excluded from the document root of the Web server, so that they cannot be accessed via the Web. They should be accessible to the system administrator or Web content development group only, and inaccessible to everyone else in the organization. If the script sources fall into the hands of malicious perpetrators, the source code can be inspected for flaws, making the perpetrator's job even easier. Access to the CGI executables directory, frequently called the cgi-bin, should be properly controlled as well. Only the Web server and administrator need access to this directory. Liberal access permissions to the CGI executables directory give those with malicious intent the opportunity to place their own scripts within the site.

Most CGI scripts are written in scripting languages such as Perl, JavaScript, and Python. Scripting languages are useful for rapidly prototyping systems, but they also let the developer write dangerous code very easily. For instance, it is easy to construct system commands with user input, a potentially dangerous situation. Writing the same system functionality requires several lines of programming code and knowledge of system libraries. The easy accessibility of scripting languages makes them appealing, but also threatening to security-critical applications. It is also important to prohibit access to interpreters from the Web server. For instance, system administrators may be tempted to include the Perl interpreter in CGI script directories; however, doing so provides direct Web access to interactively execute Perl commands—an extremely dangerous configuration.

Finally, administrators should account for every CGI program on the server in terms of its purpose, origin, and modifications. Remove CGI scripts that do not serve a business function, and view with suspicion CGI scripts that are distributed with operating systems and Web servers, downloaded from the Internet, or purchased commercially. These steps will eliminate most of the potentially dangerous CGI scripts. Once a stable set of CGI programs is established, make a digital hash of the program executables (e.g., using MD5 or SHA-1) to enable future integrity checks.

21.6.5 Application Subversion.

Application subversion attacks are not discussed often in relation to e-businesses, but they represent a significant threat to most online applications. Application subversion is a form of program misuse. Unlike buffer overflow attacks, application subversion attacks exploit the program logic without violating program integrity, in order to elevate user privileges and gain unauthorized access to data. It is the very complexity of the target program that gives the attacker the means to gain unauthorized access. Application subversion attacks use programs in ways that the program's designers and developers did not anticipate. Typically, these attacks are not scripted, but rather developed from online interactive use and subsequent abuse.

Referring to Exhibit 21.1, an application subversion attack will attempt to discover ways of short-circuiting paths in the workflow. For instance, there may be a hidden path that lets the user gain access to account information without being authenticated to that account. Many such attacks work on the premise that access to confidential information is not properly authenticated.

Another common attack sends malformed input to a program. Many Web pages use forms extensively to drive the application, while the data input on the form is checked using client-side scripting. An attacker can take advantage of the fact that many online application developers assume that the client is going to use the form properly and that the scripts will check all input sent to the site. The attacker can examine the data stream sent by the form and then, rather than using the form, send a modified data stream via URL within the browser or incorporating it into a custom command of the attacker's choosing. An attacker may be able to obtain access to the application by placing system commands in the input stream. If the input stream is subsequently used in a system( ) call by the online application, the end user may force the execution of system commands on the attacker's behalf.

Some application developers rely heavily on hidden fields in the HTML document. Hidden fields allow the Web developer to include information on the page that is not displayed, although the end user can see the hidden field data simply by viewing the HTML source. The mistake application developers make is, first, in believing that the end user cannot see the hidden fields, and, second, in relying on the integrity of the hidden field data for making online decisions. Some online merchants have made the mistake of including pricing information for items in the hidden fields and using those prices to determine the cost of the online transaction. The end user can simply change the pricing in the hidden fields and send lower prices back to the merchants, for a discounted purchase.

Another misuse of hidden fields is to redirect application output. For instance, some Web sites include file system path information in hidden fields on their Web pages. This information is used by a server-side script to determine where to read or write transaction information. Attackers, simply by changing the hidden field, can overwrite files or read files to which they should not have access. In some cases, it may be possible to store a program entered in a form field to be used later as a means of running a privileged shell on the remote system.

In summary, rigorous software quality assurance is necessary throughout the design and development of all Web-enabled and e-business applications, including front-end Web pages, application middleware, and operating systems. Once the software is believed to be immune to application misuse and subversion attacks, the system administrator must perform other activities to ensure the security of the e-business middleware:

• All unnecessary scripts or application server programs must be eliminated from the production server.
• Source code of application middleware must be carefully guarded against download or unauthorized access.
• Proper configuration of the CGI and application middleware is necessary to ensure executable access only to the correct application middleware, with the lowest practical privilege level. Sanity checking of inputs to application middleware must be done to ensure that only well-formed input is accepted.
• Testing of application code with the use of programs such as WebInspect by SPI Dynamics (www.spidynamics.com) that are specifically designed to discover flaws within Web-based applications.

21.6.6 Web Server Exploits.

Web server security has been written about and covered in detail, including in E-Commerce Security: Weak Links, Best Defenses¹² and The Web Security Source Book,¹³ among other titles. Here we highlight some of the common exploits of Web servers used against many e-businesses.

21.6.6.1 Configuration.

The key to Web server security is its configuration. Like other complex pieces of software, Web servers are highly configurable to meet the needs of any given site. By default, most software vendors configure the software application for maximum functionality but minimum security. Thus, by default, when the server is first started, it is likely to be more permissive than any given company's security policy would like. The principal premise for configurability is in the variations that exist among sites.

A correctly configured Web server is the result of a policy that defines what access is allowed, to which individuals, for each resource. This policy, in turn, is used to configure routers, firewalls, and all public servers, such as the Web server. Configuring the Web server, while necessary, is by no means sufficient to secure the system. The discussion of application server exploits in Section 21.6.5 demonstrates this principle.

21.6.6.2 HTML Coding and Server-Side Includes.

Once the Web server is configured as securely as possible, it is important to ensure that the Web pages themselves do not open holes in the security. Many Web page developers fall into some common pitfalls that may compromise the site's security. The preceding section mentioned the problem of relying on hidden fields in HTML for security or business critical data. Users can abuse the hidden field data to subvert an application.

HTML offers other potential vulnerabilities. One that is most often criticized is Server Side Includes (SSI). The SSI configuration option, if enabled, allows directives to be embedded in HTML that the server will execute. For instance, if the next statement were embedded in an HTML document, it would direct the server to display the contents of the system password file:

<--#exec /bin/cat /etc/passwd -->

Certainly Web pages should not be written with SSIs without a compelling reason. Although access to the HTML code is normally under control of the site, there are many ways an attacker might get an SSI into an HTML page. First, the attacker may have found another way into the system (e.g., by a CGI script exploit) but may want to provide either an easier backdoor or a redundant backdoor in case the CGI script vulnerability is found and closed. Once the CGI script is exploited, the attacker may implant an SSI directive within one of the site's HTML pages. Another way for an attacker to gain access is to have the server generate a Web page with the SSI of choice embedded in the HTML. How can an attacker do this? One approach exploits a server that generates dynamic HTML depending on the end user's data, preferences, or history. If the Web server ends up using some of the attacker's data to generate the HTML page, the attacker may be able to insert an SSI directive in the HTML. In summary, a better solution than continuously monitoring the HTML pages is simply to disable the SSI. In that event, even if SSIs were embedded, the server would not execute them. This is a configuration option, and like all system configuration files, the Web server configuration file should be protected by both file permission protection and file integrity checks, to ensure that it cannot be tampered with.

Although SSIs are often highlighted, a more common risk results from keeping documents or files in a publicly accessible portion of the Web server. The accessible portion of the Web server is called the document root. This root specifies the portion of the file system that the Web server can read and display to a Web client if requested. The document root can be a superset of the Web pages that are actually displayed when the user clicks through a Web site. There may be other documents in the document root that are not linked to or from Web pages. This does not mean they are not accessible, however. Simply giving the correct address for any document will result in either displaying or downloading the document to any Web client. Therein lies the problem.

It is worth noting that HTML content is no longer found only in files served by the Web. On the local hard disk, Microsoft Windows applications often install Help documents comprised of CHM (“chum”) files and binaries. An attacker could exploit this vulnerability, leading to elevated privileges to the Windows XP “My computer” zone; unfortunately, local files are often overlooked and considered “trusted” during penetration tests.¹⁴ Recognizing these risks, Microsoft Corp. began use of Microsoft Assistance Markup Language with the Windows Vista OS.

21.6.6.3 Private Documents in Public Directories.

Private documents inadvertently placed in a public directory can result in a compromise of confidential information and loss of privacy. For example, if a database file of credit card numbers (say, cardnumbers.mdb) were stored in the document root of the Web server for a fictitious company, mycompany.com, this URL address typed in a Web browser could download the file: www.mycompany.com/cardnumbers.mdb

This risk is even greater if directory browsing, another configurable feature, is enabled. Directory browsing allows an end user to view the contents of the file system at a given directory level if a Web page does not exist with the same name. Directory browsing is really a way to explore the file system of another site using a Web browser. Users may view this feature if they go back one level from a given Web page by deleting the right-hand section of a page's URL and viewing its higher-level directory (e.g., in http://a.b.com/d/e.htm, one would remove the “e.htm” thus attempting to browse http://a.b.com/d/). Attackers can learn a lot of valuable information from viewing the contents of a directory including private files. Furthermore, the browser itself provides for clicking on a file name in the directory structure, which causes the file to be downloaded. Again, directory browsing, if enabled, is an open vulnerability and an unfortunately easy way to download private or confidential information.

21.6.6.4 Cookies and Other Client-Side Risks.

Another potential vulnerability for an e-business is the use of cookies. Because HTTP is a stateless protocol, each new Web page that is visited has no memory of the last Web page that was visited by that user. Cookies are used to “keep state” between different Web pages visited in a given session. Cookies can make an e-business transaction appear to be seamless, sequential, and coordinated.

Most people, when discussing the risks of cookies, focus on the client-side privacy risks. Although these certainly exist, cookies also pose risks to the businesses that employ them. If the information contained in cookies is trusted, much the same way that the content in hidden fields is trusted, then the e-business may be vulnerable to cookie exploits called cookie poisoning. Some Web sites use cookies to carry authentication information for a given user who traverses its pages. Once users have authenticated themselves, their token of authentication may be carried with them via cookies from one Web page to all subsequent pages at that site. Using cookies is a fairly weak form of authentication. The cookie can be stolen easily by someone snooping a user's local area network or the Internet and then, with the information gained, to access the user's personal pages on the Web site. Secure protocols such as SSL should be employed to mitigate this risk.

Cookies also are used for other purposes that can introduce new vulnerabilities into critical transactions. Because cookies are under the control of end users, they can be changed in whatever manner a user chooses. If cookies are designed to instruct a Web server where to write a customer-specific file, by changing the cookie data, an end user might overwrite other customer files or even replace critical system files. Similarly, if cookies are used for carrying order information, as is common in electronic shopping carts, then changing the contents of the cookies would corrupt the transaction. This could result in an unauthorized, deep discount to the customer. This example and other cross-site scripting vulnerabilities are quite prevalent on today's Web. Browser exploits, HTTP header injection, cross-site request forgeries (CSRF), and numerous flavors of phishing are all examples of Web client/user attack.

Regardless of the technology used, it is important to examine the features and functions of Web servers from a security-critical viewpoint. Dependence on a specific technology for critical transactions demands that the technology be trustworthy, so that it does not provide vulnerable points of attack.

21.6.7 Database Security.

Databases traditionally have represented an important intellectual property of information-based companies. As a result, they have almost always been company proprietary and unavailable to public access. In the new model of business, however, many of these proprietary databases are made available on the Internet, often without careful consideration of the risks involved. The Web browser becomes the database query interface, often to unknown and untrusted entities.

Although there has been much research in database security over the last two decades, the commercial sector has adopted only two key tenets: authenticating and authorizing principals to certain objects. Access to databases thus is controlled by properly authenticating the credentials of the requesting principal and then verifying which objects the authenticated principal is authorized to access. Any online database application must perform these two functions rigorously to protect the most valuable assets of e-business as well as customer privacy.

Although many vendors claim secure channel access from the Web server to the database, there are many pitfalls. To start with, the fundamental reason why databases are vulnerable is that Web interfaces are commonly appended to what once may have been a closed and proprietary interface, without concern for overall security. Second, unsecured middleware programs such as CGI scripts or application servers usually mediate access from the Web server to the database. Web servers can provide client authentication from simple user name and password entry to strong certificated authentication. The needs of the business and the size of the accessing community will dictate which solution is feasible.

Despite obvious security advantages, most users do not store encrypted information in their databases, primarily for performance reasons. Encrypting and decrypting information on the fly during search, retrieve, and store operations can be too slow for real-time transactions. Also, even encrypting the data in a storage unit would not provide complete protection, as the online application must be able to read from and write to the database in clear text. Application-based attacks would still be able to get at the data while it was in plain, unencrypted text format.

Another key vulnerability of online databases also arises from application-based attacks. As described earlier, attacks that exploit vulnerabilities in the business-application logic often can provide unrestricted access to a database.

Attacks that exploit a buffer-overflow vulnerability in an application server program usually will be able to get command shell access on the remote server. From there, the attacker usually is able to find source code for the application server programs, such as Perl scripts or even C code, that are used to access the database. Because these programs need access to the database, they also must know the passwords used to access the various data partitions. If the programmers have foolishly hard-coded the passwords, then simply reviewing the source code may be enough to discover these passwords. With passwords in hand, the attacker can use the application server program via the Web interface to gain unauthorized access to the database. More directly, with a password it is possible to query a database from the command shell, using SQL commands or commands from the database language of choice.

Finally, like the other complex programs that run e-businesses, databases must be securely configured. Basic steps that the database administrator (DBA) needs to take include:

• Enforcing Web client authentication to the database
• Enforcing Web client authorization for access to database records
• Eliminating default database and database platform accounts
• Ensuring that passwords are read from encrypted files, not stored in program code
• Changing easily guessed passwords
• Configuring and maintaining internal access controls
• Auditing log files for suspicious activity

Account maintenance can be a key vulnerability in database management. Often the database software vendor will create a DBA account with an easily guessed password. Worse, DBAs may use the default account and password distributed with the database installation. This permits an attacker who has knowledge of the default passwords to gain access to all portions of the database by assuming the identity of the database administrator.

21.6.8 Platform Security.

One area alluded to earlier in this chapter concerns the platforms that host components of an e-business. The platform, or operating system, represents the foundation of the e-business, but it is a potentially weak link in security. If there are cracks in the foundation, there is very little that even strong application software can do to keep the business secure. Therefore, it is imperative that system administrators properly patch platform vulnerabilities and maintain the security of the platform itself. As mentioned earlier, firewalls can go a long way toward blocking access to platform vulnerabilities by unauthorized outsiders. However, authorized but unprivileged users within the firewall can exploit known platform vulnerabilities to yield root privileges on a business-critical machine. Outsiders able to gain user privileges on the platform through any means also may be able to penetrate platform holes into severe security breaches.

Some key steps necessary to maintain platform security include:

• Eliminating default accounts generally installed with the operating system
• Prohibiting easily guessed passwords
• Enforcing password expiration
• Deactivating any unnecessary services that may be running by default
• Regularly applying security patches to the operating system
• Updating the operating system to its most recent release
• Ensuring that file access permissions are properly enforced, so as to prevent unnecessary access to critical files
• Enabling audit logging with intrusion monitoring
• Running system file integrity checks regularly

Some administrators believe that deploying a firewall is an acceptable substitute for configuring their platforms securely. Furthermore, with the plethora of different platforms running their enterprises, many system administrators give up on installing the latest OS patches and on securely configuring their platforms. They mistakenly assume that firewalls will protect them from all threats, even without maintenance. Unfortunately, relaxing host security can make the job of hackers easy. By hopping from machine to machine, they usually can find the valuable information they are looking for, or if that is their goal, they can wreak maximum damage.

21.7 SUMMARY.

This chapter has provided an overview of the weakest links in Web applications, including Web clients, network protocols, front-end Web servers, back-end databases, application servers, and the platforms on which they run. Secure network protocols are necessary but certainly not sufficient for securing e-commerce. The vulnerabilities described here are largely based on software flaws that exist in the application layer of e-commerce transactions.

Perhaps the most common vulnerability in e-commerce systems is misconfiguration of software. Because the responsibility for software configuration lies with the user, a security policy must be implemented and enforced. Once a system is configured, it is important to subject it to third-party validation and testing. A third-party audit can ensure that the configured system, including routers, firewalls, servers, and databases, meets the specifications of the security policy. The system also should be tested periodically against well-known, common attacks as well as against newer threats as they arise.

Like any software system, commercial off-the-shelf software has flaws, many of which are security-critical. It is imperative that system administrators stay current with vendor Web sites, with hacker sites, with newsgroups, and with wherever threats and patches to their software are released. Both the security and hacker communities are constantly at work finding flaws in COTS that software vendors and security firms generally correct quickly. Software consumers—those who buy and use the software—must do their part by applying all relevant patches to their vulnerable software.

For custom-developed software, which includes front-end Web pages, application servers, CGI scripts, and mobile content such as ActiveX or Java, developers must do everything possible to ensure that their software is not vulnerable to attack and that it does not infringe on users' privacy.

21.8 FURTHER READING

Anderson, R. Security Engineering: A Guide to Building Dependable Distributed Systems. Hoboken, NJ: John Wiley & Sons, 2001.

Cobb, Stephen. Privacy for Business: Web Sites and Email. Saint Augustine, FL: Dreva Hill, 2002.

McGraw, G., and E. Felten. Securing Java. Hoboken, NJ: John Wiley & Sons, 2000. Rubin, A. White Hat Security Arsenal: Tackling the Threats. Reading, MA: Addison-Wesley, 2001.

Rubin, A., D. Geer, and M. Ranum. The Web Security Sourcebook. Hoboken, NJ: John Wiley & Sons, 1997.

Scambray, J., Shema, M., and C. Sima. Hacking Exposed Web Applications, 2nd ed. San Francisco, CA: McGraw-Hill Osborne Media, 2006.

Viega, J., and G. McGraw. Building Secure Software: How to Avoid Security Problems the Right Way. Reading, MA: Addison-Wesley, 2001.

21.9 NOTES