4 Misconceptions About SQL Injection Vulnerabilities

Interested in learning more about SQL injection attacks, including how to prevent them? Attend my online webcast on Friday March 16, 2018 at 9AM Eastern at the free online GroupBy conference . injection continues to be one of the biggest risks that we face as developers and database professionals. SQL security Every year, millions of users’ personal information is leaked due to poorly written queries exploited by SQL injection. The sad truth is that SQL injection is completely preventable with the right knowledge. My goal today is to cover four common misconceptions that people have about SQL injection in an effort to dissuade any illusions that an injection attack is not something that can happen to you. Prefer to watch me get angry about these common misconceptions? You can watch this content on my YouTube channel. 1. “My database information isn’t public” Let’s see, without me knowing anything about your databases, I’m guessing you might have some tables with names like: Users Inventory Products Sales etc… Any of those sound familiar? You might not be publicly publishing your database object names, but that doesn’t mean they aren’t easy to guess. All a malicious user needs is a list of common database table names and they can iterate over the ones they are interested in until they find the ones that match in your system. 2. “But I obfuscate all of my table and column names!” Oh jeez. I hope you don’t do this. Some people do this for job security (“since only I can understand my naming conventions, I’m guaranteeing myself a job!”) and that’s a terrible reason in and of itself. Doing it for security reasons is just as horrible though. Why? Well, have you ever heard of some system tables like sys.objects and sys.columns? SELECTt.name, c.nameFROMsys.objects tINNER JOIN sys.columns c on t.object_id = c.object_idon t.object_id = c.object_id A hacker wanting to get into your system can easily write queries like the ones above, revealing your “secure” naming conventions. Security through obscurity doesn’t work. If you have table names that aren’t common, that’s perfectly fine, but don’t use that as your only form of prevention. 3. “Injection is the developer’s/dba’s/somebody else’s problem” You’re exactly right. SQL injection is a problem that be tackled by the developer/dba/other person. should But it’s also a problem that benefits from multiple layers of security, meaning it’s problem to solve as well. your . Preventing sql injection is hard Developers should be validating, sanitizing, parameterizing etc… DBAs should be parameterizing, sanitizing, restricting access, etc.. Multiple layers of security in the app and in the database are the only way to confidently prevent an injection attack. 4. “I’m too small of a fish in a big pond — no one would go out of their way to attack me” So you run a niche business making and selling bespoke garden gnomes. You only have a few dozen/hundred customers, so who would bother trying to steal your data with SQL injection? Well, most SQL injection attacks can be completely automated with tools like . Someone might not care about your business enough to handcraft some SQL injection code, but that won’t stop them from stealing your handcrafted garden gnome customers’ data through automated means. sqlmap No app, big or small, is protected from the wrath of automated SQL injection tooling. Interested in learning more about SQL injection attacks, including how to prevent them? Attend my online webcast on Friday March 16, 2018 at 9AM Eastern at the free online GroupBy conference . Thanks for reading. You might also enjoy following me on Twitter.