Project Management

Ensure basic Web site security with this checklist

While I normally advocate a principles-based approach to maintaining system security, and deplore the typical "best practices" checklist approach, that does not 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.

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.
  • Make sure you implement strong security measures that apply to all systems -- not just those specific to Web security: For more detail, check out 10 security tips for all general-purpose OSes. It might be worth a read.

A note about TLS and SSLv3:

TLS and SSLv3 are, in fact, almost identical protocols. Earlier versions of SSL, however, contain serious flaws that may be used to compromise the security of communications over these protocols. TLS is the recommended choice between TLS and SSLv3 because of the fact that it's a new implementation intended to replace SSL and will likely receive better support in years to come, including improvements in the security characteristics of the protocol.

About

Chad Perrin is an IT consultant, developer, and freelance professional writer. He holds both Microsoft and CompTIA certifications and is a graduate of two IT industry trade schools.

20 comments
Gena111
Gena111

Excellent checklist. I'd like to add another point : Periodically audit your website for flaws and vulnerabilities. This is extremely important, because we constantly make changes in our code, configurations, new installations, plug-ins and so on. Every little change can make our website vulnerable to hackers, that's why it is important to constantly validate its security state. for malware scanning : http://websitedefender.com for security audit : http://itsecurityadvice.net thanks,

bloodrose903
bloodrose903

Hey all, I just got a series of emails through a contact us form on the website (I use form2email for data handling) which all originated from the same IP address. The form poster used the string -1' in all the fields available. I've never seen this before - is that an attempt to exploit a loophole? Any suggestions to prevent this from occuring in the future? Thanks, s.

JCitizen
JCitizen

and then it probably won't pick up obfuscated malware objects in just one scan either.

royhayward
royhayward

Thanks, Many times when I read articles like this you find that the author is just restating the basics or the obvious. Saying things like, "Don't do admin work from Starbucks." and "Don't write your password on your whitboard." You didn't ignore these, but you went deeper. I am looking at moving to TSL now. It looks like a great option for my product. Thanks again.

bblackmoor
bblackmoor

This was a surprisingly decent article. It hits the main points, supports them, doesn't wander into the weeds or veer into OS-specific nonsense. Good job.

seanferd
seanferd

Or their managers' foreheads, whichever is appropriate. Fine list you got there. I sincerely hope that proper security built in first before the rest of site design starts catching on. Hopefully, lists like yours will help good designers make sure they've covered all bases, and inspire others to start condidering security as a "good idea". Well written as always.

appdev
appdev

Please Remind your audience that this article's scope is limited to Windows Server networks.Unix/Linux users should ignore most of it as MS specific.

Jaqui
Jaqui

Is the links in the site. While the commonly used scripts make themselves portable to different locations by using relative links, those same relative links are an opening for security exploits via cross site scripting, and cross site sql injection. A properly written script will have a site specific variable that is added to every relative link to reduce the possibility of that happening. When writing a script fom scratch, or picking a pre-existing script, look for how the script will avoid the issues of cross site exploits.

apotheon
apotheon

One thing you won't catch me doing is making up a checklist entirely of superficial fluff like "Don't write your password on the whiteboard in the conference room!" (barring rare exceptions, like a joke).

catseverywhere
catseverywhere

Of course it's not OS specific. An apache exploit, or a weak password, or an unencrypted login knows no OS. I second the request for more on cross site scripting. That's still mostly fog in my mind.

gemidune
gemidune

I agree, great article. If only every IT architect & developer understood this and practiced in this fashion. Plus, good addition about cross site scripting. More, please.

apotheon
apotheon

Please explain how it's limited to MS Windows. I wrote it as an OS agnostic article, and there is nothing about it that I recall that made it specific to MS Windows.

Jaqui
Jaqui

IT's os agnostic.

apotheon
apotheon

Here you go. I've written an article about cross-site scripting for you.

MarkGyver
MarkGyver

Here's a quote of the only part of the article that I could find that even *mentions* MS or Windows. This does not look like an endorsement to me. "[C]ross-platform-compatible strong encryption such as SSH is usually preferable to platform-specific, weaker encryption tools such as Windows Remote Desktop."

Timbo Zimbabwe
Timbo Zimbabwe

He either has his head shoved up a penguin's butt or is merely an MS basher. Either way, he's blind to the facts.

robo_dev
robo_dev

While I agree with you that there is nothing to suggest that the tips apply to Windows-based web servers..... As an 'IT Professional', making comments about the mental condition of others is totally unnecessary and unhelpful. It would be more constructive to challenge the poster to defend his viewpoint or opinion.

apotheon
apotheon

That seems like a bit of a stretch, but it's the best theory I've heard so far.