Recovering from website disasters - Part 2

This article, originally published in 2004, offers tips on solving problems with your website

Introduction | Part One | Part Two | Part Three | Part Four

My website has been hacked

If a hacker has intruded on your site and left graffiti across your homepage, your first instinct might be to clean up. But, according to David Harris, a specialist IT and intellectual property lawyer from Ukitlaw.com, you should resist the urge. "Cracking and defacement of a website is a criminal offence under the Computer Misuse Act. Therefore the servers will be a source of evidence and that should be preserved. At the very least before repairing servers I would suggest backing up log files or other files that would contain evidence," he says.

Security consultant Nick Sumner warns: "If they've got to the website, you don't know what else they've got. You have to assume the whole box has been compromised. You have to rebuild it. It's the only way to be 100% sure."

There's no point in recreating it with the same flaws: you need to plug the security hole this time and that means finding it first. Sumner is hired by webmasters to assess their site's security. "If I examine a website for vulnerabilities, first I'll look at the operating system software. Then I'll look at the shopping cart/ecommerce software. It might be well known to have vulnerabilities."

"The single biggest vulnerability is user input. If you enter an apostrophe into any input field and get a database error, it's an indication that the entry form is not secure. It's not a guarantee that it's vulnerable, but it's a good indication." Sumner says that imaginative hackers can create a string designed to crash the server and feed it commands to take control.

Other vulnerabilities include data leakage, where users can manipulate the URL to access data they shouldn't see; order manipulation where customers can edit an order price or status; and weak login forms that can be defeated with a brute force attack. Sumner claims that three out of five sites he's tested since the summer were critically vulnerable. "People could make changes to the site or access customer orders," he says. "It was pretty serious."

To defend yourself against intrusion, keep an eye on your log files, FTP logs and order logs. Create passwords that will be hard to guess - ideally a random sequence of letters and numbers of more than eight characters. And before you install any scripts (including shopping carts) on your site, apply any security patches and search the web for known weaknesses.

My site has been hit by a denial of service attack

In November 2003 last year, payment processor Worldpay was struck by a denial of service attack. "The attack filled up the pipes with detritus but we were transacting throughout," says Worldpay's press manager Simon Fletcher. In a statement, Worldpay asserted that no customer data was compromised and conceded that attacks of this nature are difficult to prevent and avoid.

Daval markets its morning sickness treatment through its website at www.morningwell.co.uk and uses Worldpay to accept orders. Daval director David Gosley is upbeat about Worldpay's handling of the attack but warns against putting all your eggs in one basket: "We have ensured easy access to our products by appointing other online outlets, a variety of which use other clearance methods. Customers to our own ordering process finding they were unable to order simply chose another route to our product with another UK supplier. We list available sources on each of our product sites."

Legal options are limited. "Most current denial of service attacks seem to be distributed attacks from zombie machines infected by viruses," says Harris. "There is no practical legal remedy in this case since locating all infected machines and taking action against the owner is absurdly impractical. When an attack originates from one or two IP addresses, then the controlling ISP can be contacted and informed. If they fail to act to stop it then a range of legal remedies such as injunctions and damages might be feasible."

If your own site is targeted, the culprit is most likely to be some poorly error-trapped code. Sumner says: "A database set to return ten rows could be changed to ten thousand rows to show the full database." Simply editing a URL on a dynamic website could overwhelm the server.