 |  |
| |
Besides Apache, there are two big chunks of supporting software you will need: a scripting language and a database manager. We cover languages fairly extensively in Chapter 13, Chapter 15, Chapter 16, and Chapter 17. There are also some smaller items.
The computing world divides into two camps — the sort-of-free camp and the definitely expensive camp. If you are reading this, you probably already use or intend to use Apache and you will therefore be in the sort-of-free camp. This camp offers free software under a variety of licences (see later) plus, in varying degrees, commercial support. Nowadays, all DBMs (database managers) use the SQL model, so a good book on this topic is essential.[49] Most of the scripting languages now have more or less standardized interfaces to the leading DBMs. When working with a database manager, the programmer often has a choice between using functions in the DBM or the language. For instance, MySQL has powerful date-formatting routines that will return a date and time from the database served up to your taste. This could equally be done in Perl, though at a cost in labor. It is worth exploring the programming language hidden inside a DBM.
[49]Such as SQL in a Nutshell, by Kevin Kline (O'Reilly, 2000).
These are the significant freeware database managers:
A "real" database manager will offer features like transactions that can be rolled-back in case of failure and Foreign key. Both MySQL and PostgreSQL now have these.
If you are buying a commercial database manager, you will probably consider Oracle, Sybase, Informix: products that do not need our marketing assistance and whose support for free operating systems is limited.
Most web sites need a mailserver to keep in touch with clients and to tell people in the organization what the clients are up to.
The Unix utility Sendmail (http://www.sendmail.org) is old and comprehensive (huge, even). It had a reputation for insecurity, but it seems to have been fixed, and in recent years there have been few exploits against it. It must mean something if the O'Reilly book about it is one of the thickest they publish.[50] It has three younger competitors:
[50]Bryan Costales with Eric Allman, sendmail (O'Reilly, 2002)
[51]Indeed, it was exactly this kind of situation that led to the formation of the Apache Group in the first place.
In style it is similar to Smail 3, but its facilities are more extensive, and in particular it has some defences against mail bombs and unsolicited junk mail in the form of options for refusing messages from particular hosts, networks, or senders. It can be installed in place of sendmail, although the configuration of exim is quite different to that of sendmail.
It is available for Unix machines under the GNU licence and has a good reputation among people whose opinions we respect.
Business email should be encrypted because it may contain confidential details about your business, which you want to keep secret, or about your clients, which you are obliged to keep secret.
Pretty Good Privacy (PGP) (http://www.pgpi.org) is the obvious resource, but it uses the IDEA algorithm, is protected by patents, and is not completely free. GnuPG does not use IDEA and is free: http://www.gnupg.org/. PGP is excellent software, but it has one problem if used interactively. It tries to install itself into your web browsers as a plug-in and then purports to encrypt your email on the fly. We have found that this does not always work, with the result that your darkest secrets get sent en clair. It is much safer to write an email, cut it onto the clipboard, use PGP's encryption tool to encrypt the clipboard, and copy the message — now visibly secure — back into your email.
Your live web site will very likely be on a machine far away that is not under your control. You can connect to the remote end using telnet and run a terminal emulator on your machine, but when you type in the essential root password to get control of the far server, the password goes across the web unencrypted. This is not a good idea.
You therefore need to access it through a secure shell over the Web so that all your traffic is encrypted. Not only your passwords are protected, but also, say, a new version of your client database with all their credit card numbers and account details that you are uploading. The Bad Guys might like to intercept it, but they will not be able to.
You need two software elements to do all this:
Secure shell: free from OpenSSH at www.openssh.org or expensive at http://www.ssh.com.
A terminal emulator that will tunnel through ssh to the target machine and make it seem to you that you have the target's operating system prompt on your desktop. If you are running Win32, we have found that Mindterm (http://www.mindbright.se) works well enough, though it is written in Java and you need to install the JDK. When our version starts up, it throws alarming-looking Java fatal errors, but these don't seem to matter. A good alternative is Putty: http://www.chiark.greenend.org.uk/~sgtatham/putty/. If you are running Unix, then it "just works" — since you have access to a terminal already.
The object of business is to part customers from their money (in the nicest possible way), and the essential point of attack is the credit card. It is the tap through which wealth flows, but it may also serve to fill you a poisoned chalice as well. As soon as you deal in credit card numbers, you are apt to have trouble. Credit card fraud is vast, and the merchant ends up paying for most of it. See the sad advice at, for instance, http://antifraud.com/tips.htm. Conversely, there is little to stop any of your employees who have access to credit card numbers from noting a number and then doing some cheap shopping. Someone more organized than that can get you into trouble in an even bigger way.
Unless you are big and confident and have a big and competent security department, you probably will want to use an intermediary company to handle the credit card transaction and send you most of the money. An interesting overview of the whole complicated process is at http://www.virtualschool.edu/mon/ElectronicProperty/klamond/credit_card.htm.
There are a number of North American intermediaries:
First Union - Merchant Sales and Services http://www.firstunion.com/2/business/merchant/
Nova Information Systems http://www.novainfo.com/
Vantage Services http://vanserv.com/
Since we have not dealt with any of them, we cannot comment. The interfaces to your site will vary from company to company, as will the costs and the percentage they will skim off each transaction. It is also very important to look at the small print on customer fraud: who picks up the tab?
We have used WorldPay — a U.K. company operating internationally, owned by HSBC, one of our biggest banks. They offer a number of products, including complete shopping systems and the ability to accept payments in any of the world's currencies and convert the payment to yours at the going rate. We used their entry-level product, Select Junior, which has rather an ingenious interface. We describe it to show how things can be done — no doubt other intermediaries have other methods.
You persuade your customer along to the point of buying and then present her with an HTML form that says something like this:
We are now ready to take your payment by credit card for $50.75.
The form has a number of hidden fields, which contain your merchant ID at WorldPay, the transaction ID you have assigned to this purchase, the amount, the currency, and a description field that you have made up. The customer hits the Submit button, and the form calls WorldPay's secure purchase site. They then handle the collection of credit card details using their own page, which is dropped into a page you have designed and preloaded onto their site to carry through the feel of your web pages. The result combines your image with theirs.
When the customer's credit card dialog has finished, WorldPay will then display one of two more pages you have preloaded: the first, for a successful transaction, thanking the client and giving him a link back to your site; the other for a failed transaction, which offers suitable regrets, hopes for the future, and a link to your main rival. WorldPay then sends you an email and/or calls a link to your site with the transaction details. This link will be to a script that does whatever is necessary to set the purchase in motion. Writing the script that accepts this link is slightly tricky because it does nothing visible in your browser. You have to dump debugging messages to a file.
It is worth checking that the amount of money the intermediary says it has debited from the client really is the amount you want to be paid, because things may have been fiddled by an attacker or just gone wrong during the payment process.
A password is only useful when there is a human in the loop to remember and enter it. Passwords are not useful between processes on the server. For instance, scripts that call the database manager will often have to quote a password. But since this has to be written into the script that anyone can read who has access to the server and is of no use to them if they have not, it does nothing to improve security.
However, services should have minimal access, and separate accounts should be used. SSH access with the associated encrypted keys should be necessary when humans do upgrades or perform maintenance activities.
You should run no more Unix services than are essential. The Unix utility ps tells you what programs are running. You may have the utility sockstat, which looks at what services are using sockets and therefore vulnerable to attacks from outside via TCP/IP. It produces output like this:
USER COMMAND PID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS root mysqld 157 4 tcp4 127.0.0.1.3306 *.* root sshd1 135 3 tcp4 *.22 *.* root inetd 100 4 tcp4 *.21 *.*
indicating that MySQL, SSH, and inet are running.
The utility lsof is more cryptic but more widely supported — it shows open files and sockets and which processes opened them. lsof can be found at ftp://vic.cc.purdue.edu/pub/tools/unix/lsof/.
It is a good idea to restrict services so that they listen only on the appropriate interface. For example, if you have a database manager running, you may want it to listen on localhost so only the CGI stuff can talk to it. If you have two networks (one Internet, one backend), then some stuff may only want to listen on one of the two.
Internal services — those not exposed to the Internet, like a database manager — should have their own network. You should partition machines/networks as much as possible so that attackers have to crawl over or under internal walls.
If there are untrusted internal users on your system (for instance, students on a University system who are allowed to create their own virtual web sites), use suexec to make sure they do not abuse the file permissions they get via Apache.
When your clients need to talk confidentially to you — and vice versa — you need to use Apache SSL (see Chapter 3). Since there is a performance cost, you want to be sparing about using this facility. A link from an insecure page invokes SSL simply by calling https://<securepage>. Use a known Certificate Authority or customers will get warnings that might shake their confidence in your integrity. You need to start SSL one page early, so that the customer sees the padlock on her browser before you ask her to type her card number.
You might also use SSL for maintenance pages (see earlier).
See Chapter 11 on SSL.
|  | |
| 12.3. Managing a Big Site |  | 12.5. Scalability |
Copyright © 2003 O'Reilly & Associates. All rights reserved.