Site Security in HTML Creating Commercial Websites
Site Security in Creating Commercial Websites, 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).
This chapter does not deal with encryption security. This is covered in the preceding chapter, “Taking Payment Online.”
Public Versus Private Sites
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).
Uses for Private Sites
Some uses for a private Web site are
- provide a place for sensitive material (financial, proprietary, or medical records).
- use in conjunction with a payment system on a “charge for access” site.
- provide a premium site (a site that perhaps is only available to clients, past customers, sales staff, and so on).
- build a sense of exclusivity.
- track sales and marketing. By asking viewers to fill out information before receiving a password into the site (such as the popular HotWired site,), you can track who is visiting and collect sales information at your virtual front-door. (Be really careful of this—if not given enough incentive, viewers may never enter at all.)
Setting Up a Private Site
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:
- What do you want to accomplish?
- Who do you want to keep out?
- What are you keeping secret?
What Is the Point?
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!
Who Wants to Know?
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.
What Ya Hiding?
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.
While not common, some PAP applications have a dummy login. This was usually set up so that either the programmer or the end user would have quick access. By all means, remove any username/password data that you have not entered yourself, prior to going online. A very common dummy login is to use “guest” as both the username and password.
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
- Include copyright notices on each Web document.
- Make all your graphics as site-specific as possible (for example, incorporate your logo or something specific to your company into all graphics). They may steal your graphic, but they’ll be advertising your company in the meantime. (Go ahead, make our day, punk.)
- Put sensitive information beneath a password-protected site, or don’t post it at all.
- For information people may steal and claim as their own, you may want to use something like MD5 (freeware including documentation available at ftp://ftp.cert.org/pub/tools/md5/). MD5 shows that you had a certain file at a certain date. By using an MD5 hash code, and then publishing that code (in a newspaper, for example), you will have a record of your ownership. These hash codes cannot be inverted—meaning you can’t start with a hash code and work backwards to create the text to produce that code. Furthermore, changing even one letter in a huge document will completely change the code.
In this chapter, we have briefly discussed site security and Password authentication protocol. A few key things to remember are
- No site is ever completely secure, unless it’s offline.
- When providing sensitive information, you must weigh the risks against the benefits.
- You can take steps to help protect your intellectual property.