10 great ways to get hacked in the New Year

It’s that time of year for us to get inundated with all those Top 10 lists to help us achieve this, prevent that and so on. Those lists are valuable indeed, especially if you need some motivation to get your year started off on the right foot. So, in the same vein, I thought I’d put together a list of things you (and management) can do in order to experience the splendor of a Web-related security breach in the New Year. Some are technical issues, some operational; here they are in no particular order:

1.       Don’t bother enforcing strong passwords or intruder lockout in your application. They’ll just get in the way of your users and lead to increased customer support calls.

2.       Put a Web application firewall in place to cover up known SQL injection issues and similar problems.

3.       Ignore those oracle padding vulnerabilities that keep cropping up. Someone will probably patch the server eventually anyway.

4.       Use production data in development, QA, and staging – especially if it contains PII. Ideally, keep your development and QA servers unhardened with no patches, weak/default passwords, and open server shares to assist malicious insiders gain access. A well-positioned staging server with a similar configuration accessible via the Internet is good too.

5.       Assume, like many others, that Web-based malware couldn’t really affect your code. An added benefit would be to not install anti-malware software on your servers. It’ll just slow them down.

6.       Web services are hidden from hackers so there’s no need to test how they hold up to attacks.

7.       Don’t manually test your applications for flaws or even bother to validate what your Web vulnerability scanner turns up. It just takes too much time and requires too much brain power.

8.       Rely on vendor promises that your systems are secure in their facilities. This is especially true if they have one of those SAS 70 Type II audit reports that people are oh so eager to hand out when questioned about security.

9.       If you’re lucky enough to have a lawyer representing your business, let him or her handle all the contractual stuff affecting your Web presence. From hosting SLAs to software development contracts, legal counsel should be trusted to do the right things for the business without getting IT involved.

10.   Focus your efforts on pleasing your compliance manager and internal or external auditors. As long as they’re happy that’s usually a good indicator of overall security health.

Seriously folks, these are actual issues I’ve seen in my work but obviously they’re things you should strive to avoid. Whatever your perspective, Web application security is a mine field to say the least so watch where you step. Here’s to a great – and secure – New Year!

Share this post
  • Amazingly articulated list – I’ve picked up my actionabls / TODOs for 2011 looking at this list – thanks

  • I have to disagree with your wording for #2. Deploying a web application firewall does not make you less secure than not deploying one. I believe more accurate wording would be when organizations decide to deploy a WAF with no plans to ever fix the underlying issues. There are situations where the source code can not be fixed at all so a WAF is the only option. So are you saying that they shouldn’t do anything to help protect themselves?

    The WAF raises the bar for exploitation but it is not 100% and given a persistent/skilled attacker, they will most likely find a way around the protections. WAFs are great for immediate virtual patching to buy time to fix the code.

    Stating that by deploying a WAF you any less secure is bogus.

  • You’re right Ryan. A gentleman by the name of Steve Brown summed this approach up nicely: “Anything worth doing is worth doing poorly – until you learn to do it well.”

    In fact, I just heard someone say that they’re thinking about putting a WAF in place to cover up a known SQL injection issue rather than investing the resources to fix the problem at its source. This inspired my #2 in the list above. Sure, a WAF may be a short-term fix but it doesn’t mitigate the real risk long term.

    My premise is that if you have a known serious problem and you cover up the hole to make it look like it’s been fixed, the problem is still there. And the problem can potentially be exploited given the right scenario (disabled WAF, attack via SSL that the WAF cannot see, insider breach, etc.).

    The approach of slapping a firewall onto a system to cover up a bigger problem is a bit short-sighted and better serves the desire for immediate gratification (to please an auditor most likely) than to do what’s right for the business long term.

    Developers and security folks that understand the real issues often have their hands tied in these situations…it’s often management making such decisions and everyone’s at their mercy. Perhaps it’s a weakness of the technical folks for not properly communicating the issue at hand so management can make *better* decisions? Regardless, it’s an issue that we all must learn to deal with and improve upon if we’re going to get our arms around these risks.

  • Leave a Reply

    Your email address will not be published.