|
|
Here's a good way to look at total site security: It's a myth. We always arrange our clients' sites with this point in mind: Anything you put on the Internet is not truly secure. Yes, there are things you can do to
protect your information, or to let only certain viewers on to your site, but no matter what you do, there are ways to break in.
In fact, we have often unintentionally ended up at "secure" sites by following hypertext links or even just by hitting the wrong buttons—and we in no way consider ourselves hackers. Actually, the reason most security protocols are
enacted are simply because many problems stem from inexperienced users inadvertently messing with systems. Which brings us to another good point: everyone's not out to get you—really. There are probably very few hackers who will ever be interested in
anything on your site.
This is not to say that you should ignore security, or write off any security efforts as futile. Skilled car thieves can easily disarm an alarm system, but likely they will move on to a car without an alarm. Providing some sort of site security will
accomplish this same effect (though few car thieves break into a car just for the sense of accomplishment).
In general, a public site can be accessed by any individual who knows the address. A private site, on the other hand, usually requires a Password Authentication Protocol (PAP). Most servers and browsers have the capability to handle
password authentication, and it is generally a case of either setting this up on the server yourself (if you are using your own server), or having your administrator set this up for you (if you are using a virtual host).
In most cases, the server will keep a database of the users and their passwords, and will check the input against the recorded file. Upon requesting information from a secure address (which can be the entire server, or just a directory), the viewer is
confronted with a login/password interface. This can either be an input box generated as a function of the browser, or an HTML page that links out to a CGI file (see Figures 17.1 and 17.2).
Figure 17.1. An HTML PAP interface.
Figure 17.2. A browser-generated PAP interface.
Some uses for a private Web site are
Figure 17.3. HotWired's "free" site uses PAP and a rather lengthy registration form to collect demographic information.
How you set up your PAP will depend on your individual server. This book does not go into the actual mechanics of setting up private sites, as most server documentation will give you detailed instructions. If you are deciding whether or not to make a
site private, there are three major questions you need to ask yourself:
Previously, we listed some reasons for site security. Whatever reasons you have, consider the risks and benefits of putting any private information online. Putting private medical information online, for instance, can put you in a position of high
liability. Putting your secret R&D files online may compromise your business future. Your question should be "Why?" If you can avoid compromising your security by keeping files offline, do so!
If you are storing information that could be profitable to your competition, you have something to protect. If, however, you are designing a secure site just to track leads, or to restrict access to dirty pictures, or for some other noncrucial security
issue, you can afford to be a bit more blasé about your security.
A good exercise (to feed your paranoia) is to sit down and think about the worst things that could happen if someone broke into your server. This will be your best tool in assessing your risks and benefits, and in deciding how to approach your security
issues.
Obviously, this goes hand-in-hand with the other issues, but it's important to look at the raw information. To go back to the example of medical records, you could ask yourself if there might be a way to encrypt the records themselves, or to remove the
most damaging information. In many cases, you can at least minimize your worst case scenario by simply reducing the quantity or quality of information available.
There are at least four ways someone can break into your system. The first is to simply set up a program that will bang away at the front door, trying random usernames and/or passwords until a match is made. People who always use the same username and
password are a great help to hackers, because once a username/password combination is found on one site, it will usually go to the top of the list to be tried at another site.
The second way to break in to a site is to access the server through a route other than HTTP (Telnet, Gopher, Finger, FTP, and so on). This is an operating system problem and must be dealt with as it pertains to each OS. This can usually be fixed by
setting appropriate file permissions on the server system (as well as by just eliminating these other services, if unused).
The third way to gain access to a server is by getting shell access. This should not be possible on a Web server, but certain bugs can allow this to happen. Luckily, most companies who offer Web server software make protection from this a priority, and
it's extremely rare for someone to break in this way.
The most likely (and dangerous) way for someone to break into a system is through CGI. Remember, the "G" stands for gateway. Sloppy CGI protocols can allow someone to walk right into your system. This is because of the power that CGI allows
(it's a trade-off). There has also been concern expressed over scripting languages like Java. Always be aware that when you are running a script, you are providing a way for someone to get into your system. While the risk is very small, it does exist.
What do you do if a viewer copies something from your Web page to use as his or her own? Is there a legal remedy against this thief? Well, unfortunately that point is quite unclear. If the person did not use your work under a "fair use"
provision, if the work copied was protected under copyright law, and if you find out about the thievery, then you may take action. Whether you can be successful in the litigation is where things become unclear. There have actually been cases where entire
copyrighted books have been posted on the newsgroups, yet no action could be taken since the files were posted anonymously.
This subject is being heatedly debated, and there are many issues involved. Hopefully, we soon will have foolproof protection measures against this (but don't hold your breath). In the meantime, there are steps you can take to protect yourself. Some we
have used are
In this chapter, we have briefly discussed site security and Password authentication protocol. A few key things to remember are
The next chapter deals with Bells and Whistles—all those nifty, gee-whiz things that may or may not work for you.
