The use of particular top-level country domain names (e.g. .co.uk or .com) does add an element of trust to a visitor's impression of the site. On Thursday, the Metropolitan Police's Central e-Crime Unit (PCeU) closed 1,219 web sites selling fake designer goods.

If the fake sites had not been on .co.uk domain, they may have been less able to con consumers into parting with their money and not receiving anything or buying counterfeit products, and the PCeU would have had a harder time taking action. Providing sufficient evidence has been gained, it appears these measures were appropriate in the circumstances.

It seems a missing full stop brought down every web site hosted on a domain ending with .se (the top-level domain for Sweden) on Monday evening.

The .SE registry had apparently performed an incorrect software update but actually a script (program written by a human) had failed to add a terminating full stop (.) to the DNS records in the .se zone. Tested? I guess not.

It reminded me of Google's mishap in May when it flagged every site as potentially harmful by simply adding an extra forward slash (/) character to a file.

And, simple punctuation mistakes can invalidate the HTML of your web page, or stop your application's scripts from running. In July Microsoft created a security flaw in Windows by the addition of an extra ampersand (&) character.

Tim Berners-Lee is still wishing he hadn't put two forward slashes in every URL.

The mighty power of a punctuation mark.

It's common for access to some web sites to be restricted to users from particular Internet Protocol (IP) addresses. This is usually in addition to some other identification and authentication method. But other IP addresses are often added to this "allow list" and these should not necessarily be trusted in the same way.

In a typical scenario, a web site hosted on the internet that is used to administer another web application might be restricted to the company's own IP addresses. Then the developers say they need to check something on the live site, or another server needs to index the content, or someone wants to work from home for a while, or the site needs to be demonstrated at a client's location. All these additional IP addresses are added to the "allow list". These restrictions may be being applied at a network firewall, traffic management system, at the web server, in the application itself, in intrusion detection systems or in log analytical software, or in many of these. These are difficult to manage and in time there will be many IP addresses that no-one knows why they are allowed unless they are carefully documented, and subject to a fixed time limit when they are confirmed again by an appropriate person or removed. These extra addresses are quite often hard for someone else to guess.

However, there is another area where IP addresses are added to "allow lists", and this is for remote monitoring and testing services. These might be checking uptime, response times, content changes, HTML validation or security testing. The service providers publish the IP addresses of the source systems so that companies can specifically allow access to their web sites. Since the number of these services is relatively small, it's not too difficult to find which one might give access to areas of a web site or web application that the public (and malicious people) should not be able to get to. The particular danger here is that the IP addresses might be excluded from monitoring and logging, and therefore even a diligent web site manager might not realise for example the uptime monitoring service is making unusual, or excessive, requests.

Although it is not likely a malicious person is using this "trusted" address unless routing has been compromised as well, problems can go undetected, from what might seem to be a legitimate source. The IP address may have been typed incorrectly, or worse, the restrictions/exceptions may not have been implemented correctly allowing more addresses to have the privileged access than intended. Not logging a user's session is privileged access.

Allow traffic through, but be very specific what is allowed and monitor what's going on. Review all the exceptions periodically. Be especially careful about anything that bypasses authentication (such as allowing a search engine to crawl restricted-access content) on an otherwise public site.

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.