It used to be that if you wanted to do something on the computer, you’d boot up your PC or Mac and open a piece of installed software to go about your business.
Those were the simple times.
Now though, with the explosion of Internet-connected smartphones and software-as-a-service, the hardware-based operating system and all the protections that come with it have gone out the door. Firewalls, antivirus software, and heavily secured system coding have all been rendered useless as applications delivered through the Web to your mobile device or computer have become the new operating systems. In the past six months, we have seen literally hundreds of breaches affecting hundred of millions of consumers. From your local bank to three-letter government agencies, all have had Web-facing presences that were epically breached.
This shift in computing and the consumption of software has also shifted the perceptions of who and how online security is to be handled. Where before, your safety was assumed to be coming from the operating system and a handful of third-party AV solutions, now it is up to the expert coding of those writing the applications we dutifully use. As these applications have become increasingly powerful and linked to all of our devices, our personal data has moved to the Internet with them, meaning, theoretically, that anyone with Internet access could potentially steal that information.
The mobile paradigm brings a new problem of insecurity as well, as not only is your data accessible via the Internet on your device, but you can physically lose a cell phone much more easily than a computer. So now your data can be either digitally or physically stolen and it’s up to developers to make sure that any digital information remains safe from being compromised.
The rise of the application as the de facto way to function today means that there is a huge burden placed on the companies who normally just provided operating systems.
SQL Injection, the remote root exploit for Web applications, has been the initial attack vector behind several high profile compromises over the last six months. MySQL.com, Sun.com, HBGary Federal, Comodo’s RA (GlobalTrust.it/InstantSSL.it), eHarmony, Nasdaq, Savannah GNU, PlentyOfFish, Royal Navy Website, BoingBoing, and no doubt countless others we’ll never hear about. Let’s also not forget if a website is serving up drive-by-download malware, as many thousands have already, chances are it’s because a SQL Injection exploit inserted a malicious iFrame. Clearly OWASP made a good call placing “Injection” at the top of the Top Ten.
Here are some quick tips to avoid becoming tomorrows headline and an end of the year statistic:
- If Parameterized SQL statements, not Stored Procedures, are used everywhere in the code, the odds of SQL Injection vulnerabilities will drop dramatically. Purge all forms of concatenated database query strings and add a healthy code of input validation. There is no substitute.
- Suppression of verbose error messages is still a good idea, but DO NOT do so just to get the vulnerability to “go away” in the application vulnerability scanner report. Fix your code. Don’t be fooled by vendors claim of Blind SQL Injection detection in scanning products. The lack of verbose error messaging remains serious hindrance to automated detection with painful side effects. Direct source code access the has advantage here on comprehensiveness — use to your advantage.
- Hack yourself first. That means ALL your websites. Not just the “main” ones. Learn what the bad guys know or eventually will. Attackers are quite capable and smart enough to compromise secondary websites, use them as launching pads, and then pivot around the network.
- Detect any malware on website(s) before Google does. Failure to do so will get you black listed from search results. Give Dasient a look.
Yes there are many other things you can do to prevent SQL Injection, like detecting attacks with WAFs/IDS or database hardening procedures. Only let’s get some of the basics down first shall we?