Hackers manage to successfully break into systems much 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, in order to highlight weaknesses. And in around three quarters of all cases, they manage to break through even the most secure e-commerce sites and firewalls.
Criminals, too, are finding that hacking is getting easier as more companies move their business onto the Web. Not always because the systems are using inadequate protection systems, but because the designers and programmers have made basic, fundamental mistakes. And such mistakes can cost companies dearly. 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, when someone discovered just how easy it could be to access the mailbox of any Hotmail user? Just include details of that user’s account on the end of the hotmail.com URL and the system would divulge their details without thinking to ask for an ID or password.
Bringing a commercial Website to its knees is often no more difficult than running a freely-downloadable (and free!) hacking tool, then typing in the URL address of the Web server and watching as it crashes because of a default settings and configurations.
Keeping your Web-based business secure in today’s hacker-ridden internet means more than installing traditional network firewalls and intrusion detection, neither of which will detect or prevent the type of attacks mentioned above. You also need to ensure that the program code which drives your Web site is bug-free and, most critical of all, designed 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. Or unless you can find a way to automatically scan your application for known programming faults.
For example, financial institutions that allow their customers to execute money transfers or to apply other changes to their private bank accounts should make sure that Web application will not allow a hacker to do the same from his browser. Insurance companies that allow customers to purchase policies or adjust them to their needs should be extra cautious to hackers buying an insurance policy for accidents that have already occurred by starting a new policy with a retrospective start date before the accident occurred.
Here is another example, does your e-commerce site pass the cost of an item to your credit card processing system via a parameter in the URL? If so, it’s easy for a hacker to alter the price by simply changing the URL. Hackers have used this technique in the past to get products or services at a discount. Some even changed the prices to negative values, which credited their account each time they placed an order!
Although 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 obtained the file there’s nothing to stop him posting it on a public Web site for everyone to see and for all the search engines to find.
When Web sites comprised nothing more than a collection of HTML pages and fancy clipart, a Web server on the receiving end of a hacker’s attention merely deprived customers from looking at your electronic glossy brochures for a couple of hours. But as sites have become online versions of the traditional call centre, taking enquiries and processing orders and delivering quotes, a crash or hack which puts the site out of business for just a few minutes will cost you real money and impact your revenue. And lots of it. The hardest part is knowing that you’ve been attacked, and thus realising that you need to take action. Checking your Web pages, transaction database and security logs regularly, can not even ensure your continuing immunity.
Consider the current darling of the Web development scene, namely Content Management Systems. A CMS product allows anyone in your organisation to update your Web site using some simple HTML forms and a password, and they can do it from anywhere via the Web. No need to have 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, and which found its way onto the internet rumour mill, could halve a company’s share price. And the harder you work to publicise your denial of the story, the more people get alerted to the fact that you’ve been hacked. So the hacker wins twice.
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 assist the process. Web application scanners can be use during development, QA or even 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 vulnerabilities and positive attributes between the scanner and an application firewall can make sure that your Web application is secure.
However you manage your security, there’s a handful of key points that you can employ to ensure that your Web application isn’t leaking money:
1. Use a Web application scanner to discover vulnerabilities and develop a security policy for each application based on its unique positive attributes.
2. 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 on an as-needed basis. Although starting with everything turned on, and then looking for paths that can be closed off, is always more convenient, it’s also a huge security risk.
3. Install a Web application firewall to ensure that all the security policies are enforced, just like you use a Network firewall to secure your network.
4. Be prepared to act on what you discover during your scans, by revising your business methods or your security policy.
5. Consider using an automated tool to check your server code against the OWASP Top Ten Web Application Vulnerabilities list.
6. Install all server OS security patches.
Yuval Ben-Itzhak is Co-Founder & CTO of KaVaDo Inc. – www.kavado.com