Office Memo 9
Office Memo 9
10 October 2003
Is your site being hacked without your knowledge?
Hackers manage to break into systems more often than you might realise - just ask any member of a penetration testing team. These people hack for a living, with the explicit permission of the companies whose systems they are targeting. Their job is to highlight weaknesses. In roughly three-quarters of cases, they manage to break through even the seemingly most secure ecommerce sites and firewalls.
Criminals, too, are finding that hacking is getting easier as more companies move their business on to the Web. This is not always because the systems are using inadequate protection systems. More often, it is because the designers and programmers have made basic mistakes. And such mistakes can cost companies dear. If someone lowered the prices in your online product catalogue, how quickly would you notice? Or, if someone raised them, and orders stopped coming in, how soon would you make the connection?
Remember the Microsoft Hotmail hack from a couple of years ago? Someone discovered just how easy it could be to get into the mailbox of any Hotmail user. They just included details of that user's account on the end of "www.hotmail.com". The system would then disclose that person's details without asking for a name or password.
Bringing a commercial Web site to its knees is often no more difficult. You first download one of the widely available and free hacking tools. Install it, then type in the URL of the Web server. Watch as it crashes because it's using default settings and configurations.
Basic remedies
Keeping your Web-based business secure in today's hacker-ridden Internet means more than installing traditional network firewalls and intrusion detection. Neither will detect or prevent the type of attacks mentioned above. You also need to ensure the program code which drives your Web site is bug free.
Most importantly, you should design the site with security in mind from the start. Hackers know all the tricks, so you can't hope to keep your system safe unless you know them too. Alternatively, find a way to scan your application automatically for known programming faults.
The price of failure
Financial institutions often allow their customers to transfer money or apply other changes to their private bank accounts. They should make sure the Web application program would not allow a hacker to do the same from his browser. Insurance companies that allow customers to buy policies or adjust them to their needs should be extra cautious. Hackers might try to buy cover for accidents that have already occurred by starting a new policy with a retrospective start date.
Here is another example. Does your ecommerce site pass the cost of an item to your credit card processing system by a parameter in the URL? If so, it's easy for a hacker to alter the price by simply changing that URL. Hackers have used this technique to get products or services at a discount. Some have even changed the prices to negative values, crediting their account each time they placed an order!
Such attacks are easy to defeat if tangible goods are being sold and delivered. This is not the case for intangible items, such as downloadable software or expensive reports. Once a hacker has got hold of the file, there's nothing to stop him posting it on a public Web site. Once there, everyone can see it and all the search engines can find it.
Not all hacks need such a degree of technical competence. Every popular Web browser lets users view the source code of the current page, and any developers' comments. Hackers skilled in social engineering can even use something as innocuous as the name and 'phone number of the programmer. ("Social engineering" is hacker slang for tricking a person into revealing his or her password.)
When Web sites were mainly electronic brochures, a hacker's attention was little more than a nuisance. Sites have now become online versions of the traditional call centre - taking enquiries, processing orders and delivering quotes. A crash or hack that puts a site out of business for just a few minutes will cost you real money to fix and severely affect your revenue.
Vulnerabiliies
The hardest part is knowing that you've been attacked, and thus realising that you need to take action. Even checking your Web pages, transaction database and security logs regularly cannot ensure continuing immunity.
Consider the current darling of the Web development scene - content management systems. A CMS allows anyone in your organisation to update your Web site using some simple HTML forms and a password. They can do it from anywhere, using the Web. There is no need for access to FTP, as there are no files to upload.
Need to add a story to the front of your site? Just enter a password and type away. But what if a hacker were to do this? A malicious, untrue news release posted on your site for just an hour could easily find its way into the Internet rumour mill. Watch your company's share price dive! And the harder you work to publicise your denial of the story, the more people become aware that you've been hacked. The hacker wins twice.
OWASP
If you are a Web developer, keeping on top of hacker techniques is critical. The Web itself is the key to doing so. One excellent site is www.owasp.org, home of the Open Web Application Security Project. This freely accessible site contains masses of information to help developers stay on top of the most important techniques for ensuring hacker-proof ecommerce sites.
OWASP is a community project, staffed by developers from across the world. They have agreed to share their experience and expertise to help identify common threats and advise on how to prevent them. There are separate areas dealing with JavaScript, PHP, SQL, ASP and all the common development languages.
Although the OWASP lists are comprehensive, ensuring that your code never falls foul of any weakness on the lists is a difficult and time-consuming task. One option is to use automated tools such as Web application scanners to aid the process. You can use these during development or QA, or in production. This saves time and money, and allows you to scan continually rather than just every day or once a week.
It's also essential to revise your security policy according to what the scan discovers. Exchanging details of vulnerabilities and positive attributes between the scanner and an application firewall can make sure your Web application is secure.
Top tips
However you manage your security, there is a handful of points to remember to make sure that your Web application program isn't leaking money:
Use a Web application scanner to discover vulnerabilities. Develop a security policy for each application based on its unique positive attributes.
When planning the security of a server, use a positive security model rather than a negative one. By default, turn off all access and then enable facilities as needed. Although it is always more convenient to start with everything turned on, and then look for paths that can be closed off, this also presents a huge security risk.
Install a Web application firewall to ensure that all the security policies are enforced. Use it just as you would a network firewall to secure your network.
Be prepared to act on what you discover during your scans. Revise your business methods or your security policy in the light of what you find out.
Consider using an automated tool to check your server code against the OWASP's top ten list of Web application vulnerabilities.
Install all security patches to the server operating system.
***
Yuval Ben-Itzhak, co-founder and Chief Technology Officer of KaVaDo, contributed this article. Our thanks go to him. To contact Yuval, telephone +44 (207) 397 3450 or email him at info@kavado.com .
|
About Office Memos
An Office Memo is an extended comment on what is happening in the world of the electronic business and elsewhere. Some memos will have appeared in Office Jotter; others are simply referred to in it.
You are free to disagree with, amplify or even agree with anything that appears in Office Jotter or an Office Memo. Of course, the rest of us will never know this unless you write in with your views, so please comment*.
Content from Office Jotter or Office Memo may be circulated freely, so long as you remember to credit its source.
Thanks,
Roger Whitehead
Publisher and editor
*No more than 1,000 words at a time, please. I edit material for publication but as lightly as possible.
Copyright Roger Whitehead, 2003. I hereby assert and give notice of my right under section 77 of the Copyright, Designs and Patents Act 1998 to be identified as the author of these publications.
|