Recently I saw a StackOverflow discussion on dynamic SQL devolve into an argument against it because it always constitutes a SQL Injection vector. This brings up something I formulated for my database security class. Dynamic SQL by itself is not sufficient for a SQL Injection Attack. The following three conditions are each necessary and together they are sufficient for a SQL Injection Attack.
|1.||Dynamic SQL||Yes, it’s necessary. But let’s be a bit more general: the application must generate and submit a SQL command text with non-sanitized varying subtexts.|
|2.||Escalated DB Privileges||SQL Injection as an attack vector only makes sense if you assume the vulnerable application carries more database privileges than you want its end user to have. If you have a legitimate database account with the correct privileges, who cares what you do? I mean, you can probably use an interactive SQL client, right? You can use APEX or any of the scores of interactive web interfaces but since it’s under your account, well – no problem.|
|3.||Poor Authentication||One thing about SQL injection is that it’s time-consuming. It’s really pretty easy to track any known user who is trying to go through the steps of SQL injection. There are too many failed queries that are recognizable injection attempts. An attacker has to do a lot of experimentation, trial and error. Even using an “injection toolkit,” there is a lot of database traffic. It only reduces the attacker’s workload. In fact, these toolkits usually presuppose poor authentication.|
Now it’s important to note that any web application that allows you to search product information probably has what I would call “poor authentication.” Do you have to sign in to look for the closest bank branch? Anything with a search box has at least this criterion for SQL injection.
You shouldn’t cross out Dynamic SQL out of hand as if it were always causing an injection vulnerability. Know the tools, know their weaknesses.