It’s hard to believe, but SQL injection as we know it has been around for 13 years. Yet, SQL injection is as prevalent as ever as highlighted in The 2011 Mid-Year Top Cyber Security Risks Report.
Back in the dot-com era of 1998-99, you may recall that Internet security was all about firewalls and SSL. Interesting (and sadly), that’s still the case in so many situations. The mantra is lock down the perimeter and everything will be fine. It’s an interesting study in human psychology. Like seatbelts, cigarettes and poor diet, the elephant is in the room; yet so many people choose to ignore the consequences. Ditto with SQL injection. We know what’s hurting us yet we don’t do anything about it. Case in point, the 2011 Ponemon Institute State of Web Application Security survey found that 69% of organizations rely on firewalls to secure web applications. I’m not surprised based on what I see in my work, but wow! Not much has changed in nearly a decade and a half.
Just in the past year, we’ve seen numerous high-profile SQL injection attacks against businesses such as Barracuda Networks, Expedia and HBGary. If it’s happening to these businesses, we can only imagine how bad the SQL injection problem is with smaller or less risk-savvy organizations!
Interestingly, I just completed a Web security assessment of an application that used to have SQL injection. The issue was originally fixed but has since returned. Talk about regression at its worst. Granted, authentication in to the application was required to access the vulnerable pages but the problem is still there for exploitation by a malicious user or an attacker who has stolen someone else’s login credentials. Making the problem more complex was the fact that SQL injection only existed when logged-in with certain user roles. SQL injection wasn’t exploitable at every level simply because the pages weren’t accessible to those users.
Let this be a reminder that SQL injection is out there. It’s in your in-house applications as well as in your commercial off the shelf and cloud applications. And sensitive data is there for the taking. Traditional security controls like firewalls, SSL, passwords and the like aren’t going to help. You have to step back and look at the bigger picture. Are you performing the right tests? Are you checking all possible user role levels to see which users have access to what? Are you checking back periodically to make sure old flaws haven’t returned or new ones haven’t surface? Are you developers on board? Are you asking the right questions of your vendors? You’ll never really know unless and until you dig in deeper.
Get the latest content on web security
in your inbox each week.
THE AUTHOR
