Anyone who is not already familiar with design patterns may, after a brief survey of the field, come away with the impression that design patterns are a lot of marketing hype, are just some simple coding techniques, or are the playthings of computer scientists who really should get out more. While each of these impressions carries a grain of truth, design patterns are an essential component of the professional C++ programmer’s toolkit.

A “design pattern” is a recurring architectural theme that provides a solution to a common design problem within a particular context and describes the consequences of this solution. A design pattern is more than a simple description of a technique; it’s a named capsule of design wisdom gleaned from successful existing practice, written in such a way that it can be easily communicated and reused. Patterns are about programmer to programmer communication.

From a practical perspective, design patterns have two important properties. First, they describe proven, successful design techniques that can be customized in a context-dependent way to new design situations. Second, and perhaps more important, mentioning the application of a particular pattern serves to document not only the technique that is applied but also the reasons for its application and the effect of having applied it.

This sort of thing is nothing new. Consider an analogy from the field of algorithms. (Algorithms are not design patterns, and they’re not “code patterns.” They’re algorithms, and this is an analogy.) Consider the following statement that I might make to a colleague: “I have an unsorted sequence that I have to search a number of times. Therefore, I’m going to quick sort it and use binary search to perform each lookup.” The ability to use the terms “quick sort” and “binary search” is of inestimable value not only in design but also in communicating that design to an educated colleague. When I say “quick sort,” my colleague knows that the sequence I’m sorting is in a random access structure, that it will probably be sorted within O(nlg2n) time, and that the elements in the sequence may be compared with a less-than-like operator. When I say “binary search,” my colleague knows (even if I hadn’t earlier mentioned “quick sort”) that the sequence is sorted, that I will locate the item of interest within O(lg2n) comparisons, and that an appropriate operation is available to compare sequence elements. Shared knowledge of, and a standard vocabulary for, standard algorithms permits not only efficient documentation but also efficient criticism. For example, if I planned to perform this search and sort procedure on a singly linked list structure, my colleague would immediately smirk and point out that I couldn’t use quick sort and probably wouldn’t want to use binary search.

Until the advent of design patterns, we missed these advantages in documentation, communication, and efficient smirking with our object-oriented designs. We were forced into low-level descriptions of our designs, with all the inefficiency and imprecision that entails. It’s not that techniques for sophisticated object-oriented design didn’t exist; it’s that the techniques were not readily available to the entire programming community under a shared, common terminology. Design patterns address that problem, and we can now describe object-oriented designs as efficiently and unambiguously as algorithmic designs.

For example, when we see that the Bridge pattern has been applied to a design, we know that at a simple mechanical level an abstract data type implementation has been separated into an interface class and an implementation class. Additionally, we know that the reason this was done was to separate strongly the interface from the implementation so that changes to the implementation would not affect users of the interface. We also know a runtime cost exists for this separation, how the source code for the abstract data type should be arranged, and many other details. A pattern name is an efficient, unambiguous handle to a wealth of information and experience about a technique, and careful, accurate use of patterns and pattern terminology in design and documentation clarifies code and designs.

Patterns wonks sometimes describe design patterns as a form of literature (they really do) that follows a certain formal structure. Several common variants are in use, but all forms contain four essential parts.

1. First, a design pattern must have an unambiguous name. For example, the term “wrapper” is useless for a design pattern, because it is already in common use and has dozens of meanings. Using a term like “Wrapper” as a pattern name would lead only to confusion and misunderstanding. Instead, the different design techniques that formerly went under the name “wrapper” are now designated by the pattern names “Bridge,” “Strategy,” “Façade,” “Object Adapter,” and probably several others. Use of a precise pattern name has a clear advantage over using a less precise term, in the same way that “binary search” is a more precise and useful term than “lookup.”
2. Second, the pattern description must define the problem addressed by the pattern. This description may be relatively broad or narrow.
3. Third, the pattern description describes the problem’s solution. Depending on the statement of the problem, the solution may be rather high level or relatively low level, but it should still be general enough to customize according to the various contexts in which the problem may occur.
4. Fourth, the pattern description describes the consequences of applying the pattern to the context. How has the context changed for better or worse after application of the pattern?

Will knowledge of patterns make a bad designer a good designer? Time for another analogy: Consider one of those painful mathematics courses you may have been forced to undergo, in which the final examination is to prove a number of theorems in a certain area of mathematics. How do you get out of such a course alive? One obvious way is to be a genius. Starting from first principles, you develop the underpinnings of an entire branch of mathematics and eventually prove the theorems. A more practical approach would be to memorize and internalize a large number of theorems in that area of mathematics and use whatever native mathematical ability, inspiration, or good luck you have at your disposal to select the appropriate subsidiary theorems and combine them with some logical glue to prove the new theorems. This approach is advantageous even for our fictitious genius, because a proof built upon established theorems is more efficient to construct and easier to communicate to mere mortals. Familiarity with subsidiary theorems does not, of course, guarantee that a poor mathematician will be able to pass the test, but such knowledge will at least enable that person to understand the proof once it has been produced.

In a similar vein, developing a complex object-oriented design from first principles is probably going to be tedious, and communication of the eventual design difficult. Composition of design patterns to produce an object-oriented design is similar to use of subsidiary theorems in mathematics to prove a new theorem. Design patterns are often described as “micro-architectures” that can be composed with other patterns to produce a new architecture. Of course, selecting appropriate patterns and composing them effectively requires design expertise and native ability. However, even your manager will be able to understand the completed design if he or she has the requisite knowledge of patterns.

Data Abstraction

A “type” is a set of operations, and an “abstract data type” is a set of operations with an implementation. When we identify objects in a problem domain, the first question we should ask about them is, “What can I do with this object?” not “How is this object implemented?” Therefore, if a natural description of a problem involves employees, contracts, and payroll records, then the programming language used to solve the problem should contain Employee, Contract, and PayrollRecord types. This allows an efficient, two-way translation between the problem domain and the solution domain, and software written this way has less “translation noise” and is simpler and more correct.

In a general-purpose programming language like C++, we don’t have application-specific types like Employee. Instead, we have something better: the language facilities to create sophisticated abstract data types. The purpose of an abstract data type is, essentially, to extend the programming language into a particular problem domain.

No universally accepted procedure exists for designing abstract data types in C++. This aspect of programming still has its share of inspiration and artistry, but most successful approaches follow a set of similar steps.

1. Choose a descriptive name for the type. If you have trouble choosing a name for the type, you don’t know enough about what you want to implement. Go think some more. An abstract data type should represent a single, well-defined concept, and the name for that concept should be obvious.
2. List the operations that the type can perform. An abstract data type is defined by what you can do with it. Remember initialization (constructors), cleanup (destructor), copying (copy operations), and conversions (nonexplicit single-argument constructors and conversion operators). Never, ever, simply provide a bunch of get/set operations on the data members of the implementation. That’s not data abstraction; that’s laziness and lack of imagination.
3. Design an interface for the type. The type should be, as Scott Meyers tells us, “easy to use correctly and hard to use incorrectly.” An abstract data type extends the language; do proper language design. Put yourself in the place of the user of your type, and write some code with your interface. Proper interface design is as much a question of psychology and empathy as technical prowess.
4. Implement the type. Don’t let the implementation affect the interface of the type. Implement the contract promised by the type’s interface. Remember that the implementations of most abstract data types will change much more frequently than their interfaces.

Polymorphism

The topic of polymorphism is given mystical status in some programming texts and is ignored in others, but it’s a simple, useful concept that the C++ language supports. According to the standard, a “polymorphic type” is a class type that has a virtual function. From the design perspective, a “polymorphic object” is an object with more than one type, and a “polymorphic base class” is a base class that is designed for use by polymorphic objects.

Consider a type of financial option, AmOption, as shown in Figure 1.

Figure 1. Polymorphic leveraging in a financial option hierarchy. An American option has four types.

An AmOption object has four types: It is simultaneously an AmOption, an Option, a Deal, and a Priceable. Because a type is a set of operations, an AmOption object can be manipulated through any one of its four interfaces. This means that an AmOption object can be manipulated by code that is written to the Deal, Priceable, and Option interfaces, thereby allowing the implementation of AmOption to leverage and reuse all that code. For a polymorphic type such as AmOption, the most important things inherited from its base classes are their interfaces, not their implementations. In fact, it’s not uncommon, and is often desirable, for a base class to consist of nothing but interface.

Of course, there’s a catch. For this leveraging to work, a properly designed polymorphic class must be substitutable for each of its base classes. In other words, if generic code written to the Option interface gets an AmOption object, that object had better behave like an Option!

This is not to say that an AmOption should behave identically to an Option. (For one thing, it may be the case that many of the Option base class’s operations are pure virtual functions with no implementation.) Rather, it’s profitable to think of a polymorphic base class like Option as a contract. The base class makes certain promises to users of its interface; these include firm syntactic promises that certain member functions can be called with certain types of arguments and less easily verifiable semantic promises concerning what will actually occur when a particular member function is called. Concrete derived classes like AmOption and EurOption are subcontractors that implement the contract Option has established with its clients, as shown in Figure 2.

Figure 2. A polymorphic contractor and its subcontractors. The Option base class specifies a contract.

For example, if Option has a pure virtual price member function that gives the present value of the Option, both AmOption and EurOption must implement this function. It obviously won’t implement identical behavior for these two types of Option, but it should calculate and return a price, not make a telephone call or print a file.

On the other hand, if I were to call the price function of two different interfaces to the same object, I’d better get the same result. Essentially, either call should bind to the same function:

AmOption *d = new AmOption;

Option *b = d;

d->price(); // if this calls AmOption::price...

b->price(); // ...so should this!

This makes sense. (It’s surprising how much of advanced object-oriented programming is basic common sense surrounded by impenetrable syntax.) If I were to ask you, “What’s the present value of that American option?” I’d expect to receive the same answer if I’d phrased my question as, “What’s the present value of that option?”

The same reasoning applies, of course, to an object’s nonvirtual functions:

b->update(); // if this calls Option::update...

d->update(); // ...so should this!

The contract provided by the base class is what allows the “polymorphic” code written to the base class interface to work with specific options while promoting healthful ignorance of their existence. In other words, the polymorphic code may be manipulating AmOption and EurOption objects, but as far as it’s concerned they’re all just Options. Various concrete Option types can be added and removed without affecting the generic code that is aware only of the Option base class. If an AsianOption shows up at some point, the polymorphic code that knows only about Options will be able to manipulate it in blissful ignorance of its specific type, and if it should later disappear, it won’t be missed.

By the same token, concrete option types such as AmOption and EurOption need to be aware only of the base classes whose contracts they implement and are independent of changes to the generic code. In principle, the base class can be ignorant of everything but itself. From a practical perspective, the design of its interface will take into account the requirements of its anticipated users, and it should be designed in such a way that derived classes can easily deduce and implement its contract. However, a base class should have no specific knowledge of any of the classes derived from it, because such knowledge inevitably makes it difficult to add or remove derived classes in the hierarchy.

In object-oriented design, as in life, ignorance is bliss.

As mentioned, in the majority of cases an attacker does not have to do anything to get what he or she wants. The safe door is open and the goods are there to be taken. The Defcon 2002 wardriving contest showed that only 29.8 percent of 580 access points located by the contesters had WEP enabled. As much as 19.3 percent had default ESSID values, and (not surprisingly) 18.6 percent of discovered access points did not use WEP and had default ESSIDs. If you think that something has changed since then, you are mistaken. If there were any changes, these were the changes for the worse, because the Defcon 2003 wardrive demonstrated that only approximately 27 percent of networks in Las Vegas are protected by WEP. Because one of the teams employed a lateral approach and went to wardrive in Los Angeles instead, this number also includes some statistics for that city.

The Defcon wardrive observations were independently confirmed by one of the authors wardriving and walking around Las Vegas on his own.

Are things any better on the other side of the Atlantic? Not really. We speculated that only around 30 percent of access points in the United Kingdom would have WEP enabled. To validate this for research purpose, one of the authors embarked for a London Sightseeing Tour in the famous open-top red double-decker bus armed with a “debianized” laptop running Kismet, Cisco Aironet LMC350 card, and 12 dBi omnidirectional antenna. During the two-hour tour (exactly the time that laptop’s batteries lasted), 364 wireless networks were discovered, of which 118 had WEP enabled; 76 had default or company name and address ESSIDs. Even worse, some of the networks discovered had visible public IP addresses of wireless hosts that were pingable from the Internet side. If you are a wireless network administrator in central London and are reading this now, please take note. Of course, in the process of collecting this information, no traffic was logged to avoid any legal complications. The experiment was “pure” wardriving (or rather “warbusing”) at its best. Not surprisingly, warwalking in central London with a Sharp Zaurus SL-5500 PDA, D-Link DCF-650W CF 802.11b card (wonderful large antenna, never mind the blocked stylus slot), and Kismet demonstrated the same statistics. A similar level of 802.11 WLAN insecurity was revealed in Bristol, Birmingham, Plymouth, Canterbury, Swansea, and Cardiff.

Crossing the English Channel does not help either. One of the authors has driven from Warsaw to London with another Zaurus/D-Link CF card/Kismet kit and found a similar ratio of WEP/noWEP 802.11 networks, including very powerful unencrypted point-to-point links crossing the countryside motorways in the middle of nowhere. Another author has evaluated 802.11 security in Riga, Latvia. Curiously, the wireless networks in Riga were so abundant that it was practically impossible to use the middle ISM band (2.4–2.45 GHz) and many networks moved to the UNII (5.15–5.35 and 5.725–5.825 GHz) or even licensed ~24 GHz bands. Many legacy Breeznet and 802.11 FHSS networks were present. The wireless boom in Riga can be explained by old, noisy, Soviet-period phone lines incapable of carrying xDSL traffic without a significant packet loss/retransmission rate. Yet, despite the popularity of 802.11 networks, hardly anyone used WEP.

If you think that the majority of these unprotected wireless networks were home user access points, wireless community networks, or public access hot spots, you are wrong. Many of the wide open networks we have observed “in the wild” belong to government organizations (foreign governments included) and large corporations (multinationals included). In fact, some of these corporations are major information technology (IT) enterprises or IT-related consultancies, which is particularly shameful! We don’t even dare to think how many of the 802.11 networks located had implemented proper security measures beyond the standard (”crackable”) WEP and MAC address filtering. Single-digit percentage values surely come to mind. Considering that both WEP and MAC filtering are not difficult to circumvent with a bit of patience, it is not surprising that security remains the major concern restricting the spread and use of wireless technology around the world. At the same time, there are efficient wireless security solutions available, including powerful and affordable free and Open Source-based wireless safeguards that we describe in the second part of this book. Unfortunately, very few wireless network engineers and administrators are aware of the existence of these solutions. As always, human factor proves to be the weakest link.

The widespread area of 802.11 network coverage zones is one of the major reasons for rising security concerns and interest: An attacker can be positioned where no one expects him or her to be and stay well away from the network’s physical premises. Another reason is the widespread use of 802.11 networks themselves: By 2006 the number of shipped 802.11-enabled hardware devices is estimated to exceed 40 million units (Figure 1-2), even as the prices on these units keep falling. After 802.11g products hit the market, the price for many 802.11b client cards dropped to the cost level of 100BaseT Ethernet client cards. Of course there is a great speed disadvantage (5–7 Mbps on 802.11b vs. 100 Mbps on switched fast Ethernet), but not every network has high-speed requirements, and in many cases wireless deployment will be preferable. These cases include old houses in Europe protected as a part of the National Heritage. In such houses, drilling through obstacles to lay the cabling is prohibited by law. Another case is offices positioned on opposite sides of a busy street, highway, or office park. Finally, the last loop provider services via wireless are basically a replacement for the cable or xDSL link and 802.11b “pipe” is not likely to be a bottleneck in such cases, taking into account common xDSL or cable network bandwidth.

Figure 1.2. The growth of the 802.11 wireless market.

802.11 networks are everywhere, easy to find, and, as you will see in this book, often do not require any effort to associate with. Even if they are protected by WEP (which still remains the most common security countermeasure on 802.11 LANs), the vulnerabilities of WEP are very well publicized and known to practically anyone with a minimal interest in wireless networking. On the contrary, other wireless packet-switched networks are far from being that common and widespread, do not have well-known and “advertised” vulnerabilities, and often require obscure and expensive proprietary hardware to explore. At the same time, 802.11 crackers commonly run their own wireless LANs (WLANs) and use their equipment for both cracking and home and community networking.

Attacks on GSM and GPRS phones are mainly related to unit “cloning,” which lies outside the realm of network hacking to which this book is devoted. On the personal area network (PAN) side, the hacking situation is far more interesting to dive into from a network security consultant’s viewpoint.

Attacks on infrared PANs are a form of opportunistic cracking based on being in the right place at the right time—a cracker would have to be close to the attacked device and be in a 30-degree zone from its infrared port. Because the infrared irradiation power is limited to 2 mW only, the signal is not expected to spread further than two meters. An exemption to the 30 degrees/2 mW limitations is the case when an infrared access point (e.g., Compex iRE201) is deployed in an office or conference hall. In such a situation, all that a cracker needs to sniff traffic and associate with the infrared PAN is to be in the same room with the access point. There is no layer 2 security in Infrared Data Association (IrDA) PANs and unless higher layers’ encryption or authentication means are deployed, the infrared network is open for anyone to exploit. Windows 2000 and Windows XP clients automatically associate with other IrDA hosts and Linux IrDA project stack (http://irda.sourceforge.net/) provides a remote IrDA host discovery option (do irattach -s) as well as irdadump, which is a utility similar to tcpdump. Irdaping has been used to freeze dead unpatched Windows 2000 machines before the Service Pack 3 release (see the Bugtraq post at http://www.securityfocus.com/archive/1/209385/2003-03-11/2003-03-17/2). If you want to dump layer 2 IrDA frames under Windows 2000, an infrared debugger interface in rCOMM2k (a port of Linux IrDA stack, http://www.stud.uni-hannover.de/~kiszka/IrCOMM2k/English/) will do a decent job. However, no matter how insecure the infrared networks are, their limited use and physically limited spread means that scanning for data over light will never be as popular as scanning for data over radio frequency (RF) waves.

As such, warnibbling or looking for Bluetooth networks will gain much higher popularity than looking for infrared connections and might one day compete with wardriving in popularity. The tools for Bluetooth network discovery such as Redfang from @Stake and a graphical user interface (GUI) for it (Bluesniff, Shmoo Group) are already available to grab and use and more tools will no doubt follow suit.

Three factors limit the spread of Bluetooth hacking. One is the still limited use of this technology, but that is very likely to change in a few years. Another factor is the limited (if compared to 802.11 LANs) coverage zone. However, Class 1 Bluetooth devices (output transmission power up to 100 mW) such as Bluetooth-enabled laptops and access points can cover a 100-meter radius or greater if high-gain antennas are used. Such networks are de facto WLANs and can be suitable targets for remote cracking. The third factor is the security mechanisms protecting Bluetooth PANs against both snooping and unauthorized connections. So far there are no known attacks circumventing the E0 streaming cipher used to encrypt data on Bluetooth PANs. However, only time will determine if this proprietary cipher will stand Kerckhoffs’s assumption and whether the famous story of the unauthorized Cypherpunks mail list disclosure of the RC4 algorithm structure will not repeat itself again (see next article 11 if you find this example confusing). There are already theoretical observations of possible Bluetooth security mechanism weaknesses (see http://www.tcs.hut.fi/~helger/crypto/link/practice/bluetooth.html). Besides, even the best security countermeasure is useless unless it is implemented, and Bluetooth devices are usually set to the first (lowest) security mode out of the three Bluetooth security modes available and have the default of “0000″ as the session security PIN. It is also common to use the year of birth or any other meaningful (and guessable) four-digit number as a Bluetooth PIN. This happens for convenience reasons, but the unintended consequence is that it makes the cracker’s job much easier. In our observations, about 50 percent of Bluetooth-enabled devices have the default PIN unchanged. There are also devices that have default PINs prewired without any possibility of changing them: all the attacker would have to do is find the list with the default PINs online. Although this provides a great opportunity for the potential attacker, we have yet to meet a real flesh-and-bone “warnibbler” who goes beyond sending prank messages via Bluetooth on the street. At the same time, security breaches of 802.11 networks occur on a daily, if not hourly, basis bringing us back to the main topic: Why and, most important, how they take place.

Rather than concentrating on the basics of general information security or wireless networking, this introductory chapter focuses on something grossly overlooked by many “armchair experts”: The state of wireless security in the real world. Before getting down to it, though, there is a need to tell why we are so keen on the security of 802.11 standards-based wireless networks and not other packet-switched radio communications. Figure 1-1 presents an overview of wireless networks in the modern world, with 802.11 networks taking the medium circle.

Figure 1.1. An overview of modern wireless networks.

As shown, we tend to use the term 802.11 wireless network rather than 802.11 LAN. This particular technology dissolves the margin between local and wide area connectivity: 802.11b point-to-point links can reach beyond 50 miles in distance, efficiently becoming wireless wide area network (WAN) connections when used as a last mile data delivery solution by wireless Internet service providers (ISPs) or long-range links between offices. Thus, we consider specifying the use of 802.11 technology to be necessary: Local area networks (LANs) and WANs always had and will have different security requirements and approaches.

Figure 3-8 shows a diagram of a typical e-business payment processing system. The three functional elements of the electronic storefront’s payment processing system are order confirmation, payment gateway interface, and transaction database interface, as illustrated in Figure 3-9.

Figure 3-8. Use of the Discover one-time credit card to pay for purchases

Figure 3-9. Payment System—technology perspective

Innovative Ways to Combat Credit Card Fraud

One of the most popular topics of e-business discussion is credit card fraud. Incidents of credit card fraud are reported in the news media almost every day. Many more incidents are swept under the rug and never reported. Today’s marketing jargon has established a myth that credit card security hinges entirely on SSL. In fact, SSL has very little to do with most cases of credit card fraud. However, an SSL session does prevent an eavesdropper from snooping on network traffic and recovering sensitive financial information being sent from the customer to the electronic storefront. To date, we haven’t heard of a single case of an attacker perpetuating a credit card fraud by cracking a “weak” 40-bit SSL encrypted session and stealing customer credentials from it. Rather, the number one cause of e-business credit card fraud is when an attacker breaks into an electronic storefront and steals the transaction database.

A few years ago, the Secure Electronic Transaction (SET) protocol was designed so that the merchant didn’t receive the actual credit card information. The system involved three parties to the transaction participating simultaneously—namely, the customer, the merchant, and the financial institution. When a customer decides to pay for a purchase, the SET system on the customer’s computer sends a message to the merchant providing the transaction details and a copy of the customer’s digital certificate. No credit card details are sent. The merchant then sends a request to the merchant’s financial institution, which in turn asks for authorization from the customer’s financial institution based on the certificate provided by the customer. Once everything has been approved, payment is completed. Thus the merchant never gets the actual credit card details, and theft of information from the merchant’s system can’t result in fraud. However, the SET protocol didn’t catch on. It was based on an idealized model, requiring heavy software and PKI support by all three participants.

An innovative way to achieve a similar result is used by some credit card companies. It calls for a “one-time-use credit card.” A “virtual” credit card is issued by the credit card company whenever a customer wants to make an online payment. The customer accesses the credit card company’s Web site and signs in. The customer then enters parameters such as the amount to be paid and validity of payment. In return, the credit card company generates a “virtual” credit card number, which is valid for one transaction only. This credit card number is internally linked to the customer’s actual credit card, and it is also stored by the credit card company during the period for which it is valid.

The customer then uses the virtual credit card number, instead of the actual credit card number. To the merchant, the virtual credit card is processed exactly the same as a normal credit card. The merchant’s financial institution sends a verification and settlement message to the customer’s credit card company. The credit card company determines whether the virtual credit card is valid and whether the amount of payment falls within the limits of the amount requested by the customer—and approved when the virtual credit card was issued. The rest of the payment process goes through normally.

Once used, the virtual credit card is automatically destroyed by the credit card company. The credit card number will never work again. In the event of a fraud where credit card information gets stolen from the merchant’s Web site, and an attacker reuses the virtual credit card, the fraud will be detected and, in addition to denial of the transaction, a fraud investigation can be initiated.

Discover Financial Services, the issuers of the Discover credit card, uses such a scheme, which it calls Single-Use Credit Card number. Discover also provides customers with software called Discover DeskShop, which can be integrated with browsers to facilitate quick issuing of single-use credit cards from Discover.com. More details on Discover’s single-use credit card approach can be found at http://www2.discovercard.com/shopcenter/deskshop/main.shtml. Figure 3-8 summarizes the use of one-time credit cards.

Order Confirmation Page
After deciding to purchase the items that were placed in the shopping cart, the customer is guided to an order confirmation page, which captures information such as credit card number, customer name, shipment address, billing address, and mode of shipment.

Payment Gateway Interface
Every electronic storefront has an interface to a payment gateway operated by a financial institution. The interface is provided by the financial institution as a software component. For example, Verisign’s PayFlow Pro payment gateway provides a variety of PFPro components, including a Java object, a Microsoft COM DLL, and a Unix shared module.

The payment gateway interface component is invoked by the electronic storefront application. This component transmits the payment information to the payment gateway system over an encrypted channel such as SSL. This component also returns a response code to the electronic storefront application, indicating the status of the transaction. The response code indicates whether the transaction succeeded or failed and gives various other details about the transaction. Based on the response code, the electronic storefront application decides what to do with the order.

Transaction Database Interface
Once a transaction is passed to the payment gateway, the transaction details, along with the response code, are written into a back-end transaction database for future use. The transaction database interface must be carefully designed so it does not allow attackers to retrieve or tamper with the transaction data.

Interfacing with a Payment Gateway—An Example

A popular payment gateway service called PayFlow Pro is provided by VeriSign. PayFlow Pro’s client-side component resides in the electronic storefront application. The client component interfaces with PayFlow Pro’s servers owned by VeriSign. The PayFlow Pro client communicates with the PayFlow Pro servers, using HTTP requests sent via SSL. The HTTP request contains various parameters for processing the transaction.

Figure 3-10. Sample HTML page that interfaces with PayFlow Pro

This example features a PayFlow Pro interface implemented with Java Servlets. On the client side, the PayFlow Pro Java object is wrapped into a Java Servlet. Figure 3-10 shows what the page looks like in the Web browser.

The following HTML code is from a sample HTML page that interfaces with the PayFlow Pro payment processing system and invokes the payment processing component:

<H1>Payment Gateway Interface</H1>

<p>

<form name=pfpro_form method=GET

 action="https://payment.example.com/servlet/PFServlet/">

<table border=0>

<tr><td>Cart code</td><td><input type=text name=SHOPCART size=6></td></tr>

<tr><td>Credit Card number</td><td><input type=text name=CARDNUM size=16></td>

</tr>

<tr><td>Expiration date<br>(month/year)</td>

 <td><input type=text name=EXPMONTH size=2>

 <input type=text name=EXPYEAR size=2></td></tr>

</table>

<p><input type=submit value="Process payment">

</form>

The HTML page contains a form that invokes https://payment.example.com/servlet/PFServlet/. PFServlet invokes the PFPro Java object, which interfaces with the PayFlow Pro payment gateway. The HTML form accepts the following parameters:

Each customer’s shopping cart has a unique code associated with it. The PFServlet uses that code to process all the items in the shopping cart. Ideally, the shopping cart code is passed automatically to the payment processing system by the shopping cart session management system. The following is the code for the Java PFServlet.

import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;
import com.Signio.PFProAPI;

public class PFServlet extends HttpServlet {

public void doGet (HttpServletRequest req, HttpServletResponse res) throws

ServletException, IOException

{

 PrintWrite            rout;

 PFProAPI pfObject = new PFProAPI();

 String ver = pfObject.PNVersion();

 // get HTML form parameters

 String EXPMONTH = req.getParameter("EXPMONTH");

 String EXPYEAR = req.getParameter("EXPYEAR");

 String CARDNUM = req.getParameter("CARDNUM");

 String SHOPCART = req.getParameter("SHOPCART");

 String EXPDATE = EXPMONTH + EXPYEAR;

 // calculate total amount from the shopping cart contents

 String AMOUNT = CalculateTotalAmount(SHOPCART);

 // Receive PayFlow Pro username and password credentials from

 // a stored repository

 String username = PFCredentials.getUserName();

 String password = PFCredentials.getPassword();

 // Server hosting PayFlowPro payment gateway

 String HostAddress   = "test.signio.com";

 String HostPort      = "443";

 // Construct the parameter string to be passed to PayFlow Pro

 String ParmList      =

 "TRXTYPE=S&TENDER=C&USER=" + username + "&PWD=" + password +

 "&ACCT=" + CARDNUM + "&EXPDATE=" + EXPDATE + "&AMT=" + AMOUNT +

 "&COMMENT1[10]=TestPay&INVNUM=1234567890&STREET=120+WIGGINS+ST

 &ZIP=47907";

 String Timeout       = "30";

 // Send request to process payment and receive a response

 int rc = pfObject.ProcessTransaction( HostAddress, HostPort,

 "", "", "", "", ParmList, Timeout);

 // Write the result

 res.setContentType("text/html");

 out = res.getWriter();

 // Customer response and receipt generation code goes here.

 // At the very end, the transaction is written out to the database.

}

The com.signio.PFProAPI package provides the PayFlow Pro Java object API calls. This package is imported and placed within the PFServlet code. Next pfObject is instantiated from the PFProAPI class. The pfObject is used to communicate with the PayFlow Pro servers.

Then the form parameters, described previously, passed to the PFServlet are processed. Once the parameters are received, the function CalculateTotalAmount() is used to process the contents of the customer’s shopping cart and generate the total purchase amount to be passed for payment processing.

The next part of the code deals with setting up connection parameters for the payment gateway. First, the payment gateway credentials issued by PayFlow Pro to the merchant are retrieved from an internal repository. These credentials also can be hard-coded but doing so isn’t good programming practice. Next the server’s IP address and port numbers are set up. Finally, the string ParmList, containing a list of parameters to be passed as an HTTP request to the PayFlow Pro server, is created. These parameters indicate the transaction type (in this case a “Sale” indicated by an “S”) and the payment method (a “C” for “Credit Card”). In addition, they provide the PayFlow Pro user name and password, the credit card number and expiration date, the amount to be debited, some comments regarding the transaction, the customer’s invoice number, and the customer’s address. Full details of these parameters are found in the PayFlow Pro’s developer guide document available from VeriSign.

The request for payment processing is then issued by the pfObject.ProcessTransaction() method. The variable “rc” stores the response code received from the PayFlow Pro’s payment gateway server. Typically, all the processing—from the request to the response—occurs within a few seconds.

The rest of the servlet code generates the appropriate results based on the response code. If the payment is accepted, the servlet generates an order confirmation and a receipt and initiates the order fulfillment process. If the payment is denied, the servlet generates an appropriate response to the customer. In the end, the transaction is recorded in the transactions database.

Payment System Implementation Issues

Implementing a payment system and integrating it with a payment gateway raises certain issues that must be addressed.

Integration
Integrating the payment processing system of the electronic storefront with the payment gateway interface object requires that no sensitive parameters be derived from data passed from the client side. For example, the total price of the items selected should always be calculated by looking up the shopping cart contents and price lists from tables on the server side and never depending on any client-side data.

Temporary Information
If any temporary information needs to be stored on the server side, it should be stored outside the Web document root directory in a separate temporary file area. This way, attackers can’t retrieve intermediate or temporary files by requesting them over a Web browser. All temporary information stored should be destroyed as soon as it is no longer needed. Care should be also taken to ensure that temporary information stored from two concurrent sessions do not overwrite one another.

SSL
Although SSL doesn’t imply server-side security, it is essential that SSL be used between the customer and the electronic storefront Web site and between the storefront application and the payment gateway so that eavesdroppers can’t lay their hands on sensitive data traveling across the Internet.

Storing User Profiles
Many electronic retail storefronts allow users to create a profile and store it on the businesses’ system. In many cases, the stored profile also contains payment information, including credit card information. In such cases, extreme care should be taken to ensure that stored user profiles not be compromised in any way.

Vulnerabilities Caused by Poor Integration of Shopping Cart and Payment Gateway
A vulnerability was reported on January 4, 2002, concerning the Miva Merchant shopping cart (versions 3.x) and VeriSign’s PayFlow link payment system. The vulnerability causes the shopping cart to accept invalid credit card transactions as valid. In essence, the bug isn’t in the payment processing system but in the way the shopping cart application is integrated with the payment gateway.

There are two ways to exploit the Miva Merchant shopping cart. The first method is to edit the HTML code by saving the HTML contents of the final checkout page so that, instead of the payment form invoking the PayFlow URL, it directly invokes the final payment acceptance URL within the shopping cart, thus entirely skipping the validation stage. The second way of exploiting the system is to sign up for a free test merchant account with VeriSign’s PayFlow system. The test merchant account will validate certain credit card numbers that have been designated as test numbers for developers who want to test their applications. Again, the way to exploit the shopping cart is to edit the HTML code on the checkout page, and instead of the HTML form invoking the PayFlow URL, the form invokes the test account validation URL. Then a fake “testing” credit card number can be used to validate the purchases. Full details of the exploitations are available at http://securitytracker.com/alerts/2002/Jan/1003102.html.

PayPal—Enabling Individuals to Accept Electronic Payments

Payment processing systems such as PayPal (http://www.paypal.com) have enabled individuals to accept electronic payments over the Web. This capability has led to a dramatic increase in individuals, including small-scale entrepreneurs, and small businesses doing business over the Internet.

PayPal’s transactions are performed via credit card. Every user is allowed to sign up for a PayPal account at no cost. The account binds users’ identities with their credit cards. Users simply use their e-mail addresses to refer to their PayPal accounts. Assume that a user named Mallory wants to make a payment to a user named Jill who has a PayPal account. Jill’s PayPal account is simply referred to by her e-mail address, jill@example.com. If Mallory wants to make a payment to Jill, Mallory first has to sign up for a PayPal account. To do so he creates a PayPal account and assigns his credit card to the account. To make the payment, Mallory signs onto PayPal and initiates a payment to the jill@example.com account. PayPal uses Mallory’s credit card to credit Jill’s account with the specified amount. An e-mail is automatically sent to Jill stating that she has received money from Mallory.

PayPal offers three types of accounts: personal, premium, and business with different features and facilities customized for individual users, individual users with high volumes of payment receipts, and small businesses, respectively. Facilities such as receiving direct credit card payments, using an ATM or a debit card connected to the PayPal account, handling mass payments, and the like are provided by PayPal.

Some fifteen million individuals and small businesses currently use PayPal, enabling them to carry on business online. PayPal is the number one method of accepting payments on auction sites such as eBay. PayPal also encourages the “shareware” software market. Shareware is based on the concept of “try before buy.” Software developers distribute their software at no cost and give customers an option to purchase copies if they like it and want to continue using it. PayPal allows individual software developers to accept payments via credit cards from such customers who use their software. Interestingly, PayPal is also used extensively by the Internet pornography industry, which has now enabled individuals to accept payments for pornographic content.

Summary

Shopping carts and payment gateways are the heart of any e-commerce application that serves customers over the Internet. These parts of the application exchange confidential and essential information between customers and businesses over the Internet. Hence it needs serious attention with respect to security. Each component should be tightly coupled with other parts of the application. Any loophole in implementation can cause serious information leakage from the server. The several products available should be thoroughly tested with regard to security before purchase, not after installation.

As shown in Figure 3-7, proper implementation of the shopping cart application requires integration of several different electronic business components. First, it is integrated with a session management component, which keeps track of a customer’s shopping session. Second, it is integrated with the product catalog application, which generates a display of products sold by the storefront and allows the customer to browse the products; the customer can select a product from the catalog and place it in the shopping cart. Third, it is integrated with—acts as an input to—the payment gateway, which comes into play at the end of the shopping session. Fourth, it is integrated with back-end databases such as product inventory for automatically verifying and updating stock quantities, customer information for tracking customers’ buying preferences, and so on.

Figure 3-7. Shopping cart implementation - technology perspective

Since the early days of electronic retail shopping, many types of shopping carts have been introduced. Some shopping carts were made publicly available along with the source code, whereas some were sold as commercial third-party applications. Of the plethora of shopping carts, many failed because of improper implementation, which eventually led to security vulnerabilities.

Product Catalog

The product catalog typically consists of a product code, a product description, pricing, and other information. When a customer selects a product from the catalog, she places it in her shopping cart. Weak integration of the product catalog and the shopping cart leads to security vulnerabilities.

For example, if the customer can find a way to manipulate the price while selecting a product, a major error will occur. We look at such attacks in more detail in Chapter 10, where poorly implemented shopping carts allow customers to purchase products at reduced prices.

A well-implemented shopping cart application interfaces with the back-end product information database. Then parameters such as prices are derived from the database instead of relying on HTML form fields being passed back and forth. Quantity validation is an equally important issue. What happens if a customer enters a negative quantity into the shopping cart? What happens if the customer enters a fractional quantity?

Session Management

Another important aspect of shopping cart implementation is the session management mechanism. Each customer has to have a separate shopping cart while making purchases from the electronic store. Like regular storefronts, an electronic storefront probably caters to many customers at the same time. A poor session management mechanism may cause customers’ shopping carts to get mixed up, which may lead to disastrous results, especially if one customer ends up paying for another customer’s purchases. To manage customer shopping activities, a well-designed server-side session management system is essential. A poorly designed session management system can lead to session hijacking or information leakage.

Database Interfacing

The database interface between the shopping cart application and back-end databases is a focus for attacks. If it isn’t implemented properly, an attacker can inject malicious SQL queries to the database and cause a security breach. An attacker may also modify intermediate tables that store other users’ shopping sessions and selections.

Integration with the Payment Gateway

At the end of the shopping session, all selected items in the shopping cart and the corresponding bill are passed to the invoice generation and payment processing page of the electronic store application. Weak integration in this area can lead to the tampering of prices or entering of illegal quantities before the information is passed to the payment gateway.

Examples of Poorly Implemented Shopping Carts

We illustrate briefly what can go wrong if shopping carts are poorly implemented by presenting some examples in this section. More complete coverage of the vulnerabilities illustrated here are presented in later chapters and in Chapter 10, in particular.

Carello Shopping Cart
The Carello shopping cart (http://www.carelloweb.com) running on Windows NT has a flaw that allows remote command execution over HTTP. This shopping cart has a component called Carello.dll that interacts with the client. An attacker can inject commands by using malformed URLs that lead to remote command execution on the Web server.

For example, the following URL can execute the dir command on the server:

http://target/scripts/Carello/Carello.dll?CARELLOCODE=SITE2&VBEXE=C:\..\winnt\system32\cmd.exe%20/c%20dir

A full description is available at http://securitytracker.com/alerts/2001/May/1001526.html.

DCShop Shopping Cart
The DCShop shopping cart (http://www.dcscripts.com/dcforum/dcshop/44.html) stores temporary order information in clear text in a temporary file called orders.txt. This file is in DCShop’s Order subdirectory and can be retrieved directly via HTTP by any user. The orders.txt file contains all the data related to customers’ recent orders, including names, shipping addresses, billing addresses, e-mail addresses, and credit card data. The attack can be performed simply by issuing the following URL:

http://target/cgi-bin/DCShop/Orders/orders.txt

A full description is available at http://securitytracker.com/alerts/2001/Jun/1001777.html.

Hassan Consulting’s Shopping Cart
Hassan Consulting’s shopping cart (http://www.irata.com/products.html) allows arbitrary command execution on the server. The shopping cart runs on Unix and is written in Perl. The script, shop.pl, doesn’t filter out characters such as “;” and “|,” which allow remote users to inject commands on the server via the URL. URL exploitation occurs as follows:

http://target/cgi-local/shop.pl/SID=947626980.19094/page=;ls|

A full description is available at http://securitytracker.com/alerts/2001/Sep/1002379.html.

Cart32 and Several Other Shopping Carts
Some shopping carts have hidden form fields within the html source code that contain product information such as price, weight, quantity, and identification. An attacker can save the Web page of a particular item to his computer and edit the html source, allowing him to alter the parameters of the product, including the price of the product.

A full description is available at http://online.securityfocus.com/bid/1237.

Processing Payments

So far, we’ve looked at how a customer goes about browsing the electronic storefront and selecting items for purchase. The product catalog application and the shopping cart application take care of this process. Let’s now focus on the checkout process and how customers pay for their purchases.

Finalizing the Order
Once a customer has finalized the selection of items she wishes to purchase, the payment processing system captures the order details from the customer’s shopping cart. The system also asks for extra information to complete the order, such as shipping address, mode of shipment, method of payment, and so on. At this point, the customer is given the option of revising the order if necessary.

Method of Payment
Customers have several options for making payment. Credit cards and debit cards are the most popular methods of payment in almost all retail shopping, be it physical or electronic. All electronic payment processing systems can handle payment by credit card and check.

Verification and Fraud Protection
Payment processing systems communicate with the payment gateway to verify the authenticity of the customer’s method of payment for the purchases. In the case of credit cards, the payment gateway validates credit card numbers and expiration dates, verifies ownership, and determines whether the credit balance covers the amount of the purchase, and the like.

At the electronic storefront site, the payment processing system keeps a detailed log of all transactions so that they can be reconciled when payments are settled with the financial institution. Maintaining transaction logs is mandatory in most cases, and they should also be closely guarded. An attacker’s gaining access to the transaction log database would pose a huge security risk involving customers’ identities and payment instruments, which could then be used in fraudulent schemes.

Order Fulfillment and Receipt Generation
Once the payment is processed successfully, the payment system application in the electronic storefront confirms the order acceptance and generates a receipt for the customer. Nowadays, such applications have the ability to e-mail receipts to customers and notify them of the initiation of shipment, with a tracking number for use with the delivery agency so that the customers can track their shipments themselves.

Introduction

Retail shopping has evolved dramatically over the years. In the earlier days of shopping, a shopkeeper would sit behind a counter and respond to requests from a customer, selecting a product from the shelf and handing it to the customer for her consideration. The customer would then indicate whether she was interested in buying it. If so, the product would be set aside, the shopkeeper would respond to the customer’s next request, and after the customer was satisfied with all the items set aside, the shopkeeper would prepare the final bill and accept payment. If the customer didn’t like a product, the shopkeeper would naturally reshelve it.

Today, most stores allow customers to do their own shopping. A customer may ask for assistance from one of the attendants, but on the whole, products are displayed in ways that make shopping easy. Thus stores can cater to many customers, each going about his shopping individually. The entire shopping experience has been made easy for the customer. Factors such as product layout, arrangement of displays, location and width of aisles, location of check out counters, and the availability of human assistance all play a key role in the overall shopping experience.

Another innovation in the shopping experience was the advent of “catalog shopping.” Here the entire storefront was replaced with a printed catalog of products and a precise method of placing orders via phone or mail. This new approach allowed businesses to operate in an entire region or an entire nation without maintaining retail stores. Catalog shopping offered competitive prices, as there was no overhead for maintaining retail stores, inventory, staff, and stocking logistics; few central warehouses and a well-established delivery system were used to fill orders. From the customer’s viewpoint, the entire shopping experience was now available from home.

Electronic shopping is an attempt to combine the shopping experience of both in-store shopping and catalog shopping. Web-based applications offer more interactivity than a printed catalog. They also have the ability to provide more media forms, such as audio, video clips, and animation, in addition to static text and pictures—all in an effort to enhance the shopping experience and, in the end, sell more merchandise. In fact, the success of the online shopping experience depends almost entirely on ease of shopping coupled with factors such as richer media.

Customers have their own shopping styles and sets of needs when they go shopping. A storefront and its contents look different and more or less appealing when viewed through the eyes of different customers. Thus the greatest challenge facing electronic storefronts is to cater to diverse customer needs and desires over a Web-based interface. The set of customer choices also varies. For example, one customer may like to pile up all potential purchases while shopping but delay the final decision of which item(s) to purchase until the very end. Another customer may like to make a single selection at a time. Customers have different payment habits too. Although the majority use credit cards to pay for retail purchases, customers still like to pay cash or by check in some cases. Even with credit cards, customers may prefer one credit card company to another. Shopping systems have to anticipate and take care of all these needs and preferences.

As Web shopping applications have matured, some technologies and components became standard for every electronic storefront implementation. In this chapter we focus on the two most important aspects of an electronic storefront—shopping carts and payment gateways. The purpose of this chapter is to familiarize you with a few key concepts and issues related to security.

Evolution of the Storefront

By taking a look at how retail businesses evolved over time, you can understand better the roles of various components of an electronic shopping framework. Let’s begin with the traditional model of retail shopping. Figure 3-1 shows various entities and interrelationships of traditional retail shopping.

Figure 3-1. Traditional retail business

In a traditional retail business, customers interact with the merchant via a storefront. The purpose of the storefront is to display and generally to stock enough merchandise for customers to purchase on a day-to-day basis. The storefront has ways to accept payments from customers for their purchases and if some orders can’t be filled directly on the store’s premises, the merchant is responsible for taking the order and payment information. The order is then passed along to the company owning the store for further processing.

The entire purchase and delivery process works something like this. First, the company validates the order in terms of accuracy of information and availability of requested merchandise. When it finds everything in order, the company processes the payment instructions with the help of its financial institution. Upon proper processing of the payment, the company interacts with its suppliers and its clearinghouse (distribution center or warehouse) to initiate shipment of the purchased goods against the order.

In addition to selling goods, a retail business has many other peripheral functions and activities. For example, it is also responsible for marketing the company’s merchandise, which is what draws customers to its storefront in the first place.

As the scale of operations, volumes, and need for efficiency increased, retail businesses began using software applications that captured the business logic of transactions and inventory control and carried out various business processes automatically. As they continued to prosper, businesses used more and more automation in their processes. Figure 3-2 shows how businesses increased their use of automation via computerization.

Figure 3-2. Automation via computerization

Computer systems capture and process transactions efficiently at the storefront. At the end of the day, all orders are transferred electronically to the company’s corporate computer systems. These systems are updated with data from suppliers and the clearinghouse, which help track inventory. The company’s systems, in turn, typically communicate with the bank’s computers to process payments in bulk. Once the payments are processed, the orders are sent to suppliers and the clearinghouse to be filled. However, the evolution doesn’t end here. As more users were connected to the Internet—and as Web application servers matured—electronic retail business (e-business or e-commerce) came into being. Instead of businesses making use of automation, businesses themselves became automated. Application servers were now capable of hosting entire business processes on the Internet and interfacing with business processes of other entities, such as financial institutions and suppliers. The Internet also provided the means for providing ancillary services such as marketing. The physical storefront began to be replaced by an electronic storefront. People began hosting storefronts on the Internet and selling directly to customers, who interacted with the electronic storefront through a Web browser.

It is now possible to capture orders, process payments, update inventories, and initiate order fulfillment in a matter of minutes. The entire system requires little human intervention. Figure 3-3 depicts the e-commerce model.

Figure 3-3. E-commerce model

Electronic Shopping

With the electronic retail business model in mind, let’s now follow the process of electronic shopping in an electronic storefront. Companies host their storefronts as Web applications on Web servers. The Web site becomes the store’s electronic identity. Customers “step into” stores by browsing the store’s Web site. The electronic storefront provides customers with a virtual shopping experience, as they browse the merchandise and decide what they want to buy. The electronic storefront also interfaces with a payment processing system or a payment gateway provided by the company’s financial institution for accepting payments on the merchant’s behalf. The electronic storefront also interfaces with the company’s corporate systems and the suppliers’ and clearinghouse’s systems for order processing and fulfillment.

When the customer visits the electronic storefront, or Web site, he browses the different products that the store sells. The customer then reads the description of the products, looks at product prices, and decides whether to buy one or more product. Once a customer has arrived at a decision to buy a particular product, he needs to set the product aside until the shopping “trip” completed. In a regular storefront, the customer uses a shopping cart to hold his selections until he is ready to check out. Today’s electronic shopping cart is analogous to the metal or plastic shopping cart familiar to every shopper. An electronic shopping cart holds the customer’s selections and when all the selections are made, the shopping cart helps the customer check out and pay for his purchases. Electronic storefronts handle customer payments via payment gateways provided by the storefront’s financial institution where it has its bank accounts. This application provides some sort of customization to serve customers’ varying needs. The payment gateway verifies the validity of the payment instrument used by the customer and takes the necessary actions to process the payment instrument and credit the merchant’s account with the appropriate funds. Figure 3-4 depicts a customer’s interaction with an electronic retail business.

Figure 3-4. Use of electronic shopping cart and payment gateway

Shopping Cart Systems

Shopping carts in storefronts are provided for the customer’s convenience. A customer picks up a shopping cart from the row of carts in the parking lot or at the storefront entrance. The customer pushes the cart around the store’s floor during the shopping session, filling it as she goes, until she is ready to check out. The customer then (sometimes) returns the cart to the store when she has finished transferring her purchases to her vehicle. Similarly, when a customer visits an electronic retail storefront, the shopping cart’s purpose is to make shopping easy for the customer. To understand the technologies that govern an electronic shopping cart, you need to understand how the technology works.

Scope and Lifetime of an Electronic Shopping Cart
When a customer first enters an electronic retail storefront, the shopping cart application provides him with a virtual shopping cart. It remains with the customer until he places an order and exits the storefront’s Web site. Once the order is placed, the virtual shopping cart’s contents are cleared and the resources used by the virtual shopping cart are freed. In essence, without further need, the virtual shopping cart is destroyed by the shopping cart application.

Collecting, Analyzing, and Comparing Selected Components
As with a conventional shopping cart, another important aspect of an electronic shopping cart is that the customer can select items after analyzing them thoroughly—including comparing different brands—and place them in the cart. The ability to hold items and carry them along electronically saves shopping time. Otherwise, the customer would have to pay for each item immediately upon selection and then continue with his shopping. Also, at any time during the shopping process, the customer can view the selected items and compare them with other items.

Keeping Track of the Total Cost
One advantage that an electronic shopping cart has over a conventional shopping cart is that is displays the running total of the items as they’re added to the shopping cart. In this way, the customer can keep track of the cost of his selections and compare it to his budget.

Change of Mind
A customer often changes her mind after deciding to buy an item. If the customer notices a better or cheaper item than the one being carried, she can replace the previous selection with the new one. If she overshoots her budget, she may decide not to buy some items or reduce the quantities of the items selected. Electronic shopping carts allow the customer to change the quantities and remove items previously selected.

Processing the Purchase
The electronic shopping cart also helps the merchant do the final billing at the checkout counter. By carrying the total cost of the selected items, the shopping cart saves the checkout system the trouble of adding up the costs. The system simply applies any taxes and surcharges and generates the final bill. Payment is accepted against this final bill.

Figure 3-5. Shopping cart integrated with product catalog

Hence the shopping cart application forms the heart of the electronic storefront. The shopping cart application binds the customer, the catalog, the inventory system, and the payment system closely. Certain electronic shopping cart systems provide the customer with product recommendations and price comparisons with equivalent products on the fly. Most shopping cart systems are implemented with server-side code. When maintaining shopping cart instances on the server side, some applications allow the user to resume shopping where she left off, if for some reason the shopping session is terminated abruptly. Incidentally, if shopping cart applications aren’t implemented with server-side code, they become candidates for electronic shoplifting!

Figure 3-6. Shopping cart contents

Figures 3-5 and 3-6 show how the shopping cart is integrated with the product catalog and how a customer can keep track of selections during the shopping session.

CSS was designed to work with HTML. To take advantage of CSS, you need to know some HTML. As stated in the Preface, we assume most readers have had some exposure to HTML. However, to ensure we all talk about the same thing, we now review the basics of HTML.

Elements

HTML is simple to write. It is essentially a series of elements that define the structure of your document. An element normally has three parts:

• Start tag
• Content
• End tag

Figure 1.2 illustrates the three parts of an element.

All tags in HTML start with a “<” and end with a “>.” Between these comes the name of the element. In Figure 1.2, the name of the element is SENTENCE. The content of the element is a string of characters (but we will soon see that the content of an element can be another element). After that comes the end tag. End tags look like the start tag, except they have a “/” (slash) before the element name.

Building a Simple HTML Document

HTML has approximately 30 commonly used elements. SENTENCE isn’t one of them, in fact, SENTENCE isn’t an HTML element at all. We used it as an example to show the basic structure of all elements. Let’s look at a real HTML element:

<HTML></HTML>

In this book, all element names are printed using small-cap letters (for example, BODY). HTML elements are case-insensitive. That is, any combination of uppercase and lowercase letters can be used. Hence, “TITLE,” “Title,” and “title” are all the same. XML, however, is case-sensitive.

One of the elements in HTML is called HTML. The HTML start tag (<HTML>) marks the beginning of an HTML document, and the HTML end tag (</HTML>) marks the end. Everything between these two tags is the content of the HTML element. In the example, nothing is between the start and the end tag. In the next example, we add some content:

<HTML><TITLE>Bach’s home page</TITLE></HTML>

What we added from the last example is marked in bold letters (this is a convention we will use throughout this chapter). Unlike the SENTENCE example, the content of the HTML element is not just a string of characters – it’s actually another element. The TITLE element contains the title of an HTML document. The title of the document we build in this chapter is “Bach’s home page.” Figure 1.3 maps out the two elements we have so far.

Figure 1.3. Diagram of an element.

When a browser displays an HTML document in a window onscreen, the content of the title element generally goes into the title bar of the window. The title bar is at the top of the window. Below that is often the browser’s control panel. Further below that is the most interesting part of the browser window: the canvas. The canvas is the part of the window where documents are actually displayed. See Figure 1.4.

Figure 1.4. The parts of a browser’s window. The top line is the title bar, the large grey area is the canvas. CSS only deals with the content of the canvas.

As you can see, we have yet to put anything in the document that will be displayed on the canvas. To have something actually show up on the canvas, you must place it in the BODY element. The BODY element is inside the HTML element:

<HTML>

<TITLE>Bach's home page</TITLE>

<BODY>

</BODY>

</HTML>

To make it easier to see where elements start and end, we show the HTML examples over several lines and indent elements that are inside others. We do this because it makes the code easier to read. The browser ignores the extra space and the line breaks that separate one line from another.

The content of the HTML element now consists of not one, but two other elements. By themselves, the BODY tags do not add anything to the canvas; we need to give the BODY element some content. Let’s start by adding a first-level heading to the sample document. The standard HTML tag for a first-level heading is H1. Here’s the HTML code:

<HTML>

<TITLE>Bach's home page</TITLE>

<BODY>

<H1>Bach's home page</H1>

</BODY>

</HTML>

The title of the document is the same as the first-level heading. This will often be the case in HTML documents, but it doesn’t have to be.

HTML also has other headings you can use: H2, H3, H4, H5, and H6. The higher the number, the less important the heading is. If H1 corresponds to a chapter, H2 is a section, H3 a subsection, etc. Typically, also, the higher the number, the smaller the font size. Here’s the document with a couple of extra headings added:

<HTML>

<TITLE>Bach's home page</TITLE>

<BODY>

<H1>Bach's home page</H1>

<H2>Bach's compositions</H2>

<H3>The keyboard music</H3>

</BODY>

</HTML>

Figure 1.5 shows the heading levels as they might appear onscreen.

However, we don’t need those two extra headings right now, so we delete them and add a paragraph of text instead. We do this using the paragraph element, P:

<HTML>

<TITLE>Bach's home page</TITLE>

<BODY>

<H1>Bach's home page</H1>

<P>Johann Sebastian Bach was a prolific

composer.

</BODY>

</HTML>

Figure 1.6 shows the new paragraph.

Note that we left out the ending paragraph tag, </P>. Normally, an element begins with a start tag and ends with an end tag. However, for some HTML elements, the end tag may be omitted. The end tag notifies the browser when the element ends, but in some cases, the browser can figure this out for itself, so the tag is not needed. For example, the P element cannot exist outside of the BODY element. So, when the browser encounters the BODY end tag (</BODY>), it knows that the P element has also ended. Still, including the P end tag is perfectly legal. HTML specifies that leaving out the </P> has no effect on the way the document is displayed.

You can also see that the browser ignored the spaces and line breaks in the source document. There is only one space between each pair of words and the line breaks are gone.

Next, suppose we want to emphasize a word relative to the surrounding text. Several HTML elements can express this; among them, we find STRONG and EM (EM stands for emphasis). These elements do not say anything about how they are to be displayed, but there are some conventions: STRONG elements are normally displayed in bold, and EM elements are displayed in italic.

The following code shows the use of the STRONG element:

<HTML>

<TITLE>Bach's home page</TITLE>

<BODY>

<H1>Bach's home page</H1>

<P>Johann Sebastian Bach was a

<STRONG>prolific</STRONG>

composer.

</BODY>

</HTML>

Figure 1.7 shows how this code is displayed.

Notice how the word “prolific” stands out relative to the surrounding text. Also note that although the H1 and P elements start on a new line, the STRONG element continues on the same line where the P element started. H1 and P are examples of block-level elements, while the STRONG element is an inline element. We discuss block-level and inline elements in the next section.

Block-Level and Inline Elements

In the previous section, the STRONG element was placed in the middle of an element, P, while the P and H1 elements both began and ended a line. You can’t insert a P element in the middle of another P or H1 element or vice versa. But, you can insert an element like STRONG in the middle of most other elements. This is because the P and H1 elements are block-level elements, while the STRONG element is an inline element.

• Elements can be divided into three groups:
• Block-level
• Inline
• Invisible

A block-level element is an element that begins and ends a line or, put another way, that has a line break before and after its content. Examples of block-level elements that you’ve seen so far in this chapter are H1 and P.

Element Overview

Confused about the different elements? Don’t worry. Table 1.1 gives you an overview of the most common HTML elements. We’ve introduced you to several of these already and will discuss others shortly. We talk about others when appropriate throughout the rest of this book and use them in many examples. Also, we suggest that you refer to the table as needed as you work your way through this book. The last column of the table (”Empty? Replaced?”) is explained later in this chapter.

Among the elements that are not included in Table 1.1 are the elements that create forms and tables. Also, the non-standard elements have been left out.

In the next several sections, we add to your repertoire of HTML tags by discussing elements that you can use to create lists, add a horizontal rule, force a line break, and link to text and images.

Comments

Most of your documents will consist of elements. However, you can also insert HTML comments into the document. A comment is anything you want to say about what is going on with your document that you don’t want to be displayed. The user won’t see the comment on the canvas because browsers ignore comments; that is, they do not display a comment’s contents. Comments can be a helpful way of communicating something about your document to other designers who will see your code.

To ensure that the comment really is not viewable by the user, you enclose it between special strings that the browser will recognize as enclosing a comment. You begin the comment with the string <!-- and end it with the string -->. (That’s two hyphens in both cases.) Here’s a sample comment:

<!-- CSS is the greatest thing

to hit the Web since hyperlinks -->

Lists

Lists are common in HTML documents. HTML has three elements that create lists:

OL, which creates an ordered list. In an ordered list, each list item has a label that indicates the order, e.g., a digit (1, 2, 3, 4, or I, II, III, IV) or letter (a, b, c, d). In desktop-publishing terminology, ordered lists are often called numbered lists.

UL, which creates an unordered list. In an unordered list, each list item has a mark that does not indicate order, e.g., a bullet symbol. In desktop-publishing terminology, unordered lists are often called bulleted lists.

DL, which creates a definition list. A definition list is a list of terms with their corresponding definitions. For example, a dictionary is a (long!) definition list.

Bach’s home page must surely include a list of some of his compositions. Let’s add an ordered list:

<HTML>

<TITLE>Bach's home page</TITLE>

<BODY>

<H1>Bach's home page</H1>

<P>Johann Sebastian Bach was a

<STRONG>prolific</STRONG>

composer. Here are his best works:

<OL>

<LI>the Goldberg Variations

<LI>the Brandenburg Concertos

<LI>the Christmas Oratorio

</OL>

</BODY>

</HTML>

Notice that an LI doesn’t need an end tag, but an OL does. Figure 1.8 shows the result.

Figure 1.8. An ordered list.

This ordered list is unfair to all the other great compositions by Bach. (What about the Mass in B-minor?) Let’s change the ordered list into an unordered list. To do this, we simply change the OL to UL:

<HTML>

<TITLE>Bach's home page</TITLE>

<BODY>

<H1>Bach's home page</H1>

<P>Johann Sebastian Bach was a

<STRONG>prolific</STRONG>composer.

Among his works are:

<UL>

<LI>the Goldberg Variations

<LI>the Brandenburg Concertos

<LI>the Christmas Oratorio

</UL>

</BODY>

</HTML>

Figure 1.9 shows the result.

Figure 1.9. An unordered list.

Notice that we do not have to change the LI elements to change the list from unordered to ordered: Both UL and OL use LI as the list item element. But, because the LI elements are now inside the UL element, they will look different.

A DL, or definition list, is used for lists that have terms and their corresponding definitions. Each term is contained in a DT element, and each definition in a DD element. An example of a DL is a dictionary or glossary. In the next example, we change our OL to a DL. Notice how the LIs, change to DTs and that like the LIs, they do not require end tags. Figure 1.10 shows the result.

Figure 1.10. A definition list.

<HTML>

<TITLE>Bach's home page</TITLE>

<BODY>

<H1>Bach's home page</H1>

<P>Johann Sebastian Bach was a

<STRONG>prolific</STRONG> composer.

Among his works are:

<DL>

<DT>the Goldberg Variations

<DD>composed in 1741, catalog number BWV988

<DT>the Brandenburg Concertos

<DD>composed in 1713, catalog numbers

BWV1046-1051

<DT>the Christmas Oratorio

<DD>composed in 1734, catalog number BWV248

</DL>

</BODY>

</HTML>

Empty Elements HR and BR

All the HTML elements that we have discussed so far have had content. HTML also has some elements that do not have content; they are called empty elements. One example is the HR element, which inserts a horizontal rule in the document. It doesn’t need any content. Also, the BR element’s sole purpose is to force a line break. Because empty elements do not have any content, they don’t need any end tags.

We can add a horizontal rule to a document by using the HR (horizontal rule) element. HR is an empty element, so you should omit its end tag. Here’s the code for adding an HR element:

<HTML>

<TITLE>Bach's home page</TITLE>

<BODY>

<H1>Bach's home page</H1>

<P>Johann Sebastian Bach was a

<STRONG>prolific</STRONG>

composer. Among his works are:

<UL>

<LI>the Goldberg Variations

<LI>the Brandenburg Concertos

<LI>the Christmas Oratorio

</UL>

<HR>

</BODY>

</HTML>

Figure 1.11 shows the result.

Figure 1.11. Adding a horizontal rule.

We can force a line break in the middle of an element by using the BR (break) element. The browser normally ignores line breaks in the HTML document and automatically breaks a line when needed when it displays the document. However, if you want to force a line break at a certain spot in the document, BR enables you to do this. Because BR is an empty element, you can omit its end tag.

Here is our example with a BR element added:

<HTML>

<TITLE>Bach's home page</TITLE>

<BODY>

<H1>Bach's <BR>home page</H1>

<P>Johann Sebastian Bach was a

<STRONG>prolific</STRONG>

composer. Among his works are:

<UL>

<LI>the Goldberg Variations

<LI>the Brandenburg Concertos

<LI>the Christmas Oratorio

</UL>

</BODY>

</HTML>

Figure 1.12 shows the result.

Figure 1.12. Adding a line break.

It is usually better to let the browser determine the line breaks, because as an author, you cannot know how wide the user’s window is or how large the fonts are. So, we’ll take out the BR element as we move on.

Maintaining Preformatted Text

In the previous example, we mentioned that a browser generally ignores line breaks, except for those that you enter using the BR element. The browser also ignores tabs and extra white space. Tabspaces are converted to single white-space characters, while extra white-space characters – any more than one – are collapsed into one white-space character. Generally, this is what we want. This feature enables us to space out our code so that it is more readable and reflects the structure of the document, secure in the knowledge that the browser ignores all the extra white spaces.

Sometimes, however, you may want to insert white space and have the browser display your text exactly as you formatted it. The PRE (preformatted) element allows you do this. Simply enclose within <PRE> tags the information whose formatting you want to preserve. The PRE element is often used for simple tables where columns need to align vertically:

<HTML>

<TITLE>Bach's home page</TITLE>

<BODY>

<H1>Bach's <BR>home page</H1>

<P>Johann Sebastian Bach was a

<STRONG>prolific</STRONG>

composer. Among his works are:

<PRE>

COMPOSITION           YEAR  CATALOG#

Goldberg Variation    1741  BWV988

Brandenburg Concertos 1713  BWV1046-1051

Christmas Oratorio    1734  BWV248

</PRE>

</BODY>

</HTML>

Notice that the content of the PRE element cannot be aligned with the other elements because the extra white space would appear on the canvas. Figure 1.13 shows the result.

Figure 1.13. Preserving preformatted text.

This is actually not a very good example because by using PRE, we hide the fact that the content is a table. This is a case where using a table is in fact the right thing to do because it enhances accessibility (see the section “Placing text in a table” earlier in this chapter).

Adding Hyperlinks

We can make our document more interesting by adding hyperlinks to it. When hyperlinks are in place, users can click on them to access related documents from somewhere else on the Web. Hyperlinks are integral to HTML and the Web. Without hyperlinks, there would be no Web.

To make a hyperlink, you use the A (anchor) element. When the user clicks on the A element, the browser fetches the document at the other end of the hyperlink. The browser needs to be told where it can find the other document, and this information goes into an attribute on the A element. An attribute is a characteristic quality of the element, other than the type or content of an element. The A element uses an attribute called HREF (hypertext reference) to add a hyperlink:

<HTML>

<TITLE>Bach's home page</TITLE>

<BODY>

<H1>Bach's home page</H1>

<P>Johann Sebastian Bach was a

<STRONG>prolific</STRONG>

composer. Among his works are:

<UL>

<LI>the <A HREF="goldberg.html">Goldberg</A>

Variations

<LI>the Brandenburg Concertos

<LI>the Christmas Oratorio

</UL>

<HR>

</BODY>

</HTML>

Let’s take a closer look at the newly added A element. Figure 1.14 shows the different parts of the A element.

Figure 1.14. The parts of an A element.

The A start tag is a bit more complicated than the other start tags we have seen so far; in addition to the element name, it includes an attribute. Different element types have different attributes; among the most common ones is the HREF attribute on the A element. Attributes can only go into the start tag of the element, after the element name. Most attributes need a value: The HREF attributes always takes a URL as a value. A URL (Universal Resource Locator) is a Web address that the browser uses to locate the hyperlinked document. When URLs are