Web Security

For such an important issue on the internet, security often seems shrouded in mystery. First you need to ask yourself, “What do I need to be secure from?” The answer will determine where and what level of security you should create on your web site.

Domain Security

When purchasing a domain name, you are often asked whether you want a secure registration, which usually comes at an extra charge. All this does is to keep your personal contact information hidden from domain “WHOIS” lookups in the central registry. If you want people to find your contact information, (for instance, if you are in business), you may not need this feature. But it can possibly reduce the number of spam emails you receive.

Remember that your domain name is only held for you for as long as you have contracted to pay for it. To assure that your domain can not be transferred to another owner, you should always keep the domain name locked. This is usually the default, and there is typically no charge for this service. The minute your ownership expires, though, it can get bought by someone else, and you could find yourself being offered your own domain name again at an exorbitant price. The best practice against this is to set your domain name contract to auto-renew.

Website Security

When you host your website, you are given the option of creating a username and password for your FTP (File Transfer Protocol) account — your access to upload web pages to the site. Be certain that you choose a password that can not easily be guessed. Use a combination of numbers and letters, upper- and lower-case, and not based on names or words that exist in the dictionary. Hackers with programs designed to guess passwords through trial-and-error could get into your FTP listings, and wreak havoc on your site, if your password can be guessed.

Email Security

With email, some things are too good to be true, and others are too bad to be true. If you receive an email that appears to come from your bank, or your web host provider, contact them directly via phone or their web site. See if your email program allows you to look at the message’s source code; you may find clues in the email header that it was sent by someone other than they claim to be.

Remember, it is quite rare that a legitimate company would ever send you an urgent email requiring you to click something to access your account with them. And false winning-lottery-ticket and foreign-dignitary-with-money-for-you schemes have been around far longer than email itself. You will have to rely on your own good judgement to keep yourself safe from malicious emails.

Many email providers give you the option of sending and receiving email over SSL, which encrypts email to and from your address. In some cases it could slow down your email service, but it will help to keep your email from being read by anyone other than the intended recipient. Check your provider’s service and your email settings to see how to set this up.

Security on Form Pages

Nearly any page that has form fields for a user to fill out can be attacked by “spam-bots.” More of a nuisance than a threat, spam-bots attempt to load blog pages with links to their own websites, to generate traffic and enhance search engine placement for themselves. As a result, your blog or comment list may be riddled with junk you don’t want. This is why you will often see a collection of randomly-generated letters or words you must enter on forms, to ensure that you are indeed a human being entering information.

Other techniques can be used to thwart the spam-bots in a more invisible manner, but either way, your programmer needs to protect any publicly-accessible form pages on your site against this annoyance.

Database Security

Dynamic web sites (those with changeable content) often use a database such as MySQL, MSSQL, Oracle or Postsgre (to name a few) to deliver their modifiable content. Often the parameters to change the content are delivered via form fields, or in the browser’s address bar. Clever hackers can sometimes get into the site’s database by entering database code into these fields — a technique known as an “injection attack.” Once they gain access, they could effectively alter all the site’s content, or even wipe out the database entirely. This could prove disastrous to a site with ample content, or one that collects customer information.

To guard against injection attacks, a website programmer must be familiar with these hacker techniques, and run all information to be entered into a database through secure filters designed to remove malicious programming attempts.

Online Payments Security

Commercial transactions over the web require the highest level of security awareness. Under no circumstances should a customer’s bank account or credit card information be stored or sent in an even remotely insecure manner. Some third-party payment processors, such as PayPal, will allow transactions to be made through their site, transferring the user to their window to complete a transaction, and then returning the user to the original site, in order to provide their own site security.

However, if you wish for a customer to remain on your site throughout the transaction process, your programmer must provide you with the highest possible security measures on your site:

  • Secure certificate (‘https’) — A domain with a secure certificate can encrypt any information going to-and-from the website — across phone lines, cable, satellite, or whatever the medium. The certificate ensures that only the indended recipient would see the unencrypted message. Anyone “listening in” would receive only gobbledygook.
  • Onsite encryption — Any sensitive information pertaining to payments must be encrypted through one of the most secure encryption methods possible. A number of excellent encryption techniques are available to programmers, but this is high-level stuff; be sure your programmer knows what he or she is doing. Any sensitive information to be passed from one page to another within the website, regardless of the method used to pass it, must be securely encrypted.
  • Database security — It is recommended not to store bank account or credit card information within your site’s database at all. But if it is required, no sensitive information should ever be stored within a database unencrypted. Relying on the database’s password protection alone — even with the database security measures mentioned above — is not newrly safe enough.

The above reommendations are only the beginning; the PCI Security Standards Council is currently in the process of outlining comprehensive security measures for website payments.

As you can see, there are levels of security in websites, just as there are in your house or property. While a padlock is enough for some situations, others require a vault.

Comments are closed for this post.