E-consultancy.com has many excellent online marketing and e-commerce resources, and I read the blogs and forums regularly. The following posting appeared on the forum a couple of days ago:

This cry for help worried me. Although the forum replies were helpful, it did make me wonder how many other web site owners have no idea where their web site is hosted.

If this is really the case here, it probably means the owner doesn't have all the resources to rebuild the site elsewhere and possibly is without back-ups of the data. And what about the intellectual property ownership? It's something which all developers should be discussing with their customers. My first suggestion would have been to contact the development company. A cursory examination of the source code reveals:

This company even showcases the site:

Now, we have no idea of the background and cannot guess if there is anything amiss. But the site is a card payment enabled e-commerce site, and surely the owner has had to comply with the Payment Card Industry (PCI) Security Standards Council's Data Security Standard (DSS)? Knowing where your web site is hosted would be one of the earlier things to discover.

Let's hope it's sorted soon.

Setting up a web server incorrectly can be difficult to change later. Isolating the operating system from web site files and other data using separate partitions or physical devices needs to be done during server commissioning.

It would be usual to have at least three partitions on a typical web server:

• The operating system
• The web site files (scripts and static files such as images and style sheets)
• Server logs

This allows you to restrict permissions - so that if the web site is compromised, it is harder to access the operating system files, and to ensure that logs don't grow excessively and use up all the available space.

Your own data - the database and perhaps other files - should be stored seperately. If possible this should be on other servers, but if not, on a separate partition.

If you allow any user uploaded content, you should also consider storing this on another separate partition, and in any case, never in sub-directories of the web site root. This is to prevent direct access to possibly malicious file content by directly requesting the address in a browser and to ensure the files are stored in an area with limited permissions.

In my post earlier this week on Server Login Protection, I mentioned how file transfer protocol (FTP) is commonly used, and should not be. A data breach this week hints that FTP was the method of access that lead to the data theft.

The Breach blog reported a breach involving Gloria Jean's Coffees' e-commerce site. Their privacy and security statement aludes to higher standards:

The notification letter to the New Hampshire Department of Justice in the United States (US) says the company:

But the strange thing is that it is an e-commerce site and that some of the data stolen was credit card information - card number, name, address and card verification value (CVV), also known as the card security code (CSC) - obtained by modification of the application scripts on the web server. In other words, inbetween the encrypted transfer (using SSL) to the web server and before sending this by an encrypted method to the payment gateway.

Enforcement of the Payment Card Industry (PCI) Data Security Standard (DSS) is much further advanced in the US. So either the site wasn't compliant in which case large fines are winging their way towards Gloria Jean's Coffees Corp, or the auditors may have missed something important here.

See also the related Keeping Up-to-Date with Security Breaches.

The login usernames and passwords for access to the server(s) hosting your web site or application must be protected. If someone has access to your web site's files or the server's operating system, they can potentially alter, delete, copy or add anything they want.

This means every person who requires access having a unique login, and the process of identifying the person and authentication should occur over an encrypted channel (e.g. virtual private network (VPN)). Conventional file transfer protocol (FTP) should never be used, and the service should be disabled or uninstalled in the same way as any other un-necessary service. The FTP log in process is not secure and can lead to the details been stolen and sold to criminals.

Put restrictions on as many of these as possible:

• Who can log in
• What they need to know/have/be to log in
• From where can they log in
• What they can access once logged in

Passwords should be forced to expire, be complex (e.g. length, mixture of case, alphanumerics) and do not allow password re-use (changing a password back to one used recently). Ensure you:

• Change all usernames and passwords when your web site goes live
• Log all failed and successful login attempts
• Log what is done by users
• Review the logs frequently
• Review all user accounts periodically and their permissions
• Revoke accounts promptly which are no longer needed

Watch out especially for accounts used by external or temporary staff, as these can sometimes be forgotten about. Avoid giving access if you can - upload approved modifications yourself for example - at least you will have a record of what has been altered.

I'll include one of my favourite illustrations: the ICRA (formerly the Internet Content Rating Association) web content label generator tool, allows you (or your developers, designers, etc) to give ICRA your own FTP details:

"What happens next?" indeed.

If a web site is unavailable, this will affect everyone who tries to use it. Availability is a usability issue.

A web site being "down" can have the same effect as if someone cannot do what they want, it takes them too long, it leaves them frustrated or it is prone to the introduction of errors.

There are sometimes good reasons for downtime. The servers may be having software updates applied (patching). Depending on the requirements, some organisations may close a web application down during backing up, during a data update or during a change to the application.

Unavailability may also be due to excessive server loading, network connectivity problems, equipment failure or due to an attack by malicious users. If you have to take a site down for repair, your users are being denied use of the service.

Where possible try to minimise planned (scheduled) downtime and monitor the uptime semi-continuously (checking for text on some web pages or important transactions every 5 minutes, from more than one external location). For planned outages, I recommend you inform users well in advance and provide a meaningful message screen - not just a default error page.

A common way malicious hackers try to obtain information about how your website works is to generate errors and see what is displayed. It is particularly important to stop these giving away information that might help someone break into your web site, but equally you should make sure these pages are not advertising someone else's products and services.

When a web site is developed and then set up on the web server(s), it is possible to define customised error pages for all sorts of unusual events like application errors, internal server errors and, the one most people will recognise, not found. The latter is sent back when a page or other file's address is requested but does not exist. The web server sends a response status code of 404 which means "not found" and the text from whichever document has been set for this. By default many sites will return text which gives away the operating system and web server software:

But some hosting companies rather naughtily hope to gain revenue from people typing the wrong address, following an old link or clicking a dead link on another page. Instead of showing a page from your own web site, or the default web server message, they display an advert for themselves and/or adverts for other web sites. These may neither be what you expect, nor want to be associated with. Here is one from a UK limited company's web site:

Check you own web site by typing an address like:

http://[your host name]/123456doesnotexist

or something similar. Hopefully, you will see a page in the style of your own web site with an apologetic message, and not anything else. If not, speak to your developers (or hosting company) and ask them to "add custom error pages for all possible web server errors" and make sure they are your own design. Also ask them to "ensure errors return the correct HTTP response status codes" - this is especially important for correct indexing by search engines.

Here's an example showing how to do it correctly from the British Library:

If you have more than one domain, host name, or also have an HTTPS address, check them all separately. This advertising could also exist on domains you have purchased, but are not currently using for a site.