Threats
Exposure of confidential data: Not all information is meant to be shared. Some business data may be for internal use only (wholesale prices paid, for example). Customer information (account numbers, passwords, credit card numbers) is obviously personal and confidential. A web server isn't a good place to store confidential information! Once source of exposure is transmission of information via TCP-IP, the standard internet data transmission protocol used for http; use of SSL (secure socket layer) technology to encrypt and decode transmitted data is a standard safeguard (albeit at a performance cost).
Data loss: If you loose data, you loose customers and control, opening yourself up to possibilities for fraud (I paid you and you didn't send my package). You could loose data for physical reasons (hard drive crashed), because you were hacked, or because you were careless (oops!). Mirroring data in a RAID system (multiple disks), server security (firewalls, access protections), and competent and honest staff are your first defenses. But when you do loose data, you had better have it backed up somewhere, preferably in a separate building!
Modification of data: Unauthorized, malicious changes in data may be more difficult to detect than simple loss. There are many reasons (mischief, criminal intent) for hackers to attempt to modify data. Overall systems and file access security is the best defense.
Denial of service: A denial of service attack is intended to render a site slow or useless, inhibiting or preventing normal commerce. They can be executed through a program (trojan or virus) that ties up substantial system resources. Reverse spamming makes it look as though the victim is sending out annoying emails, resulting in a flood of resource-draining responses and complaints (as well as damage to reputation). The attack can be external, as when a large set of infected machines bombard a target with network traffic. Closing all but essential server ports (e.g., all but ftp port 21 and web port 80) can help prevent these attacks, and use of firewalls or intruder detection systems can help prevent successful denial of service attacks. Our class server hides behind both the URI and its own firewall; an intruder detection system automatically sends me an email when it detects a port scan or denial of service attack, which happens occasionally even behind the external firewall (or am I being scanned from within the URI domain???).
Software errors: The more you do, the more complicated the programming to do it, and the more likely that there are errors in program logic. The initial design specs can help prevent overlooked problems in design, such as sending an order that hasn't been paid for (example on p. 343). Developers may have not allowed for a wide-enough range of deviations in input data (did you think of what the single quote in O'Malley might do in the WHERE clause of a SQL string if you don't escape it? hint: how do you end a quoted string?).
Poor testing: You need to test under as many possible conditions as you can. Does your page work on major browsers and degrade acceptably on out-of-date ones? Did you migrate from one server technology to another without adjusting for changes in that technology? Testing is boring and hard work, but it is highly preferable to the cheap thrill of seeing a major bug in your software take down your client's company! One approach is to have someone other than the developer attempt to break the code. That someone will not likely become the best friend of the developer, but the developer will be better off every time a break is uncovered and repaired.
Repudiation: This means a denial of having taken part in a transaction (I didn't order that); afterward, what proof do you have that an internet transaction was authentic (could it have been a fraud perpetuated on the customer?). One counter is to use digital certificates together with encryupted or signed communications, especially between vendors with ongoing commercial relations (p. 344).
Counter Threats
Usability, Performance, Cost, and Security: You cannot maximize more than one related variable simultaneously. This means that you have to make tradeoffs between being secure and being usuable. Performance comes at a cost. Security may impede performance and reduce usability. You don't always need to maximize security.
Security policy: A policy is a document that describes a preferred operating procedure. It lays out goals, setting guidelines for reaching those goals, but not specific details on how those guidelines will be implemented. The document whould state general philosophy toward security, items to be protected (hardware and software), people responsible, and standards (quantifiable) for measuring security.
Principles of authentication: Authentication seeks to establish who a user is, a prerequisite to deciding what they are permitted to do. Web authentication relies mainly on passwords and digital signatures. Passwords, known only to the system and the user, are not on their own a strong authorization (using a computer, you can guess combinations of letters, numbers, and systems, and eventually defeat any password if allowed repeated guesses). Passwords that are simple and easy to remember are also easy to guess. The easiest are dictionary words and user names. It is more difficult if you enforce a policy (as can be done through the computer's administrative software) that requires a minimum length (8-40 characters), upper and lower case, letters, numbers, and symbols. Of course, leaving them written down somewhere or giving them out to someone creates an obvious security risk.
Chapter 16 provides examples of PHP and MySQL authentication
Encryption: This involves scrambling plain text through use of a secret key, which is then provided to the recipient of the scrambled text, allowing the recipient to unscramble it. Private key encryption and public key encryption are explained briefly on p. 349-350.
Digital Signatures: A private key is used to create an encrypted signature which is added to a message. A public key is sent to the recipient allowing decryption. Because only the sender can create the signature, the reciever is reasonably assured of who the sender is. Mechanisms are outlined on p. 351.
Digital Certificates: Through encryption, anyone can create a unique identity which can be verified by a second party. But who was the anyone and how do you know you can trust them? Third parties (Verisign, Thawte) issue a digital certificate to companies after independently verifying who they are. Someone who uses a third-party certified site still has to decide whether to trust that company's business practices, but there is a greater degree of confidence that the company is known (so, would you buy a used tank from Haliburton knowing it was indeed Haliburton?). With an issued certificate, web browsers can make a secure SSL connection to your site without tripping warnings on client machines; SSL-enabled servers are called secure web servers. The process and an example are outlined on pages 352-3.
Auditing and Logging: Servers record events such as file accesses. These logs can be used to search for alteration of critical files, such as system configurations (could be used to obtain adminstrative file access permissions, for example).
Firewalls: Firewalls filter incoming and outgoing packets (TCP/IP), detecting or rejecting packets according to a set of administrator-defined rules. For example, you can reject packets coming from specific IP addresses or IP ranges, or only admit access from specific addresses. You can restrict packets sent to specific ports. At URI, for example, packets sent to or from port 1433 are automatically rejected; this is a proprietary Microsoft SQL server port so that if you want to run a SQL Server management console to administer a SQL Server database on a remote server, you must "punch a hole" by getting an IP-specific exception to allow use of that port on your dedicated IP. Our class server restricts attempts to contact all but port 21 (ftp) and port 80 (http) as a first line of defense, for example.
Backups: If you haven't backup up data and web pages, your hard drive will seize, your server will burn, and the roof of your building will fall in during the next snow storm. No kidding!
Physical Security: Your server is your baby. Keep it warm, but not too warm, dry, and loved. Keep it locked up because physical access is the hacker's best friend. Preferably, keep it in someone else's care, someone who owns a business of providing low-cost, 24/7, always backed up, web hosting, so that you don't have to tend to your server at midnight on a January weekend after a blizzard-induced power outage.