While I normally advocate a principles-based approach to maintaining system security – and deplore the typical “best practices” checklist approach – that doesn’t mean that security checklists are without value. Employing a security procedures checklist is only the first step toward securing a resource, a means of aiding your memory before you apply your critical thinking skills and imagination to the problem of improving on the checklist in each individual case. Sometimes, a checklist can be useful in affecting workplace security policies as well.
A number of far-too-common security failures on Web sites and Web servers are addressed here. Because of the frequency of these poor security practices, it strikes me as important to gather good practices that address these problems in one place and to make them publicly available to Web server administrators, Web developers, and Webmasters. For those of you who haven’t considered all these factors in managing your Web resources, I recommend dealing with what you have left unconsidered as quickly as possible.
For those whose management has proved resistant to suggestions for improving security in these areas, or who simply need help in composing a message to management that will make your point clearly so that it isn’t misunderstood, I hope you find the following checklist of Web security practices helpful.
Login pages should be encrypted: The number of times I have seen Web sites that only use SSL (with https: URL schemes) after user authentication is accomplished is really dismaying. Encrypting the session after login may be useful — like locking the barn door so the horses don’t get out — but failing to encrypt logins is a bit like leaving the key in the lock when you’re done locking the barn door. Even if your login form POSTs to an encrypted resource, in many cases this can be circumvented by a malicious security cracker who crafts his own login form to access the same resource and give him access to sensitive data.
Data validation should be done server-side: Many Web forms include some JavaScript data validation. If this validation includes anything meant to provide improved security, that validation means almost nothing. A malicious security cracker can craft a form of his own that accesses the resource at the other end of the Web page’s form action that doesn’t include any validation at all. Worse yet, many cases of JavaScript form validation can be circumvented simply by deactivating JavaScript in the browser or using a Web browser that doesn’t support JavaScript at all. In some cases, I’ve even seen login pages where the password validation is done client-side — which either exposes the passwords to the end user via the ability to view page source or, at best, allows the end user to alter the form so that it always reports successful validation. Don’t let your Web site security be a victim of client-side data validation. Server-side validation does not fall prey to the shortcomings of client-side validation because a malicious security cracker must already have gained access to the server to be able to compromise it.
Manage your Web site via encrypted connections: Using unencrypted connections (or even connections using only weak encryption), such as unencrypted FTP or HTTP for Web site or Web server management, opens you up to man-in-the-middle attacks and login/password sniffing. Always use encrypted protocols such as SSH to access secure resources, using verifiably secure tools such as OpenSSH. Once someone has intercepted your login and password information, that person can do anything you could have done.
Use strong, cross-platform compatible encryption: Believe it or not, SSL is not the top-of-the-line technology for Web site encryption any longer. Look into TLS, which stands for Transport Layer Security — the successor to Secure Socket Layer encryption. Make sure any encryption solution you choose doesn’t unnecessarily limit your user base, the way proprietary platform-specific technologies might, as this can lead to resistance to use of secure encryption for Web site access. The same principles also apply to back-end management, where cross-platform-compatible strong encryption such as SSH is usually preferable to platform-specific, weaker encryption tools such as Windows Remote Desktop.
Connect from a secured network: Avoid connecting from networks with unknown or uncertain security characteristics or from those with known poor security such as open wireless access points in coffee shops. This is especially important whenever you must log in to the server or Web site for administrative purposes or otherwise access secure resources. If you must access the Web site or Web server when connected to an unsecured network, use a secure proxy so that your connection to the secure resource comes from a proxy on a secured network. In previous articles, I have addressed how to set up a quick and easy secure proxy using either an OpenSSH secure proxy or a PuTTY secure proxy.
Don’t share login credentials: Shared login credentials can cause a number of problems for security. This applies not only to you, the Webmaster or Web server administrator, but to people with login credentials for the Web site as well — clients should not share login credentials either. The more login credentials are shared, the more they tend to get shared openly, even with people who shouldn’t have access to the system. The more they are shared, the more difficult it is to establish an audit trail to help track down the source of a problem. The more they are shared, the greater the number of people affected when logins need to be changed due to a security breach or threat.
Prefer key-based authentication over password authentication: Password authentication is more easily cracked than cryptographic key-based authentication. The purpose of a password is to make it easier to remember the login credentials needed to access a secure resource — but if you use key-based authentication and only copy the key to predefined, authorized systems (or better yet, to separate media kept apart from the authorized system until it’s needed), you will use a stronger authentication credential that’s more difficult to crack.
Maintain a secure workstation: If you connect to a secure resource from a client system that you can’t guarantee with complete confidence is secure, you cannot guarantee someone isn’t “listening in” on everything you’re doing. Keyloggers, compromised network encryption clients, and other tricks of the malicious security cracker’s trade can all allow someone unauthorized access to sensitive data regardless of all the secured networks, encrypted communications, and other networking protections you employ. Integrity auditing may be the only way to be sure, with any certainty, that your workstation has not been compromised.
Use redundancy to protect the Web site: Backups and server failover can help maintain maximum uptime. While failover systems can reduce outages due to server crashes (perhaps because of DDoS attacks) and server shutdowns (perhaps because the server was hijacked by a malicious security cracker) to mere hiccups in service, that isn’t the only value to redundancy. The duplicate servers used in failover plans also maintain an up-to-date duplication of server configuration so you don’t have to rebuild your server from scratch in case of disaster. Backups ensure that client data isn’t lost — and that you won’t hesitate to wipe out sensitive data on a compromised system if you fear that data may fall into the wrong hands. Of course, failover and backup solutions must be secured as well, and they should be tested regularly to ensure that if and when they are needed, they won’t let you down.