SQL Injection – It’s Not Just About Your Code
There’s an area that gets overlooked much more frequently than it should as you look to protect your systems from threats like SQL Injection. That area is third-party applications.
There are so many applications that you rely on that it’s easy to overlook third party apps assuming that they’re polished and protected. In short, don’t make this assumption. Make sure you talk with the vendor – ask the tough questions, make sure you know how the application is talking to your databases. There are a few things to check that can help in this regard:
– Make sure the logins used by the application are "sandboxed" and protected – if you can, move the application to its own database, limit the user access to that database only. This way, if something happens with the application, if someone gets in, it’s only accessing that database, not your entire system.
– Make sure you check code that you have access to. Make sure it’s not vulnerable to attacks, and in particular, SQL injection attacks. You can do this a couple of ways. First, google it. See if other users of the application are experiencing issues. Second, check out the code if you can. Many applications provide source, particularly if they’re web-based. Do a once-over and see what’s happening. Look for data type checks like isdate, isnumeric and look for cleaning routines to make sure quotes are scrubbed and other filters are applied.
– Know how to recover the application. Know that your backups are working, that you can recover, and what your recovery timeframe is. In other words, understand how much information (typically an amount of time) you have at risk. What would be lost if you had to recover the system right now without notice?
This gets you started, but what have you seen with applications? Do you find yourself having to play security-police with your vendors? How do you approach it?
What do you think? Let me know…