Generally, the DBAs have very little role in knowing whether any part of their application is vulnerable to SQL injection, and on top of that they can't mitigate very well against it.
They can do the basic things: don't use the root MySQL user, restrict privileges on each MySQL user, use AppArmor or SELinux to isolate the mysqld process, etc. This does prevent an attacker, in most cases, from instantly uploading a shell as soon as they find any sort of injection vector.
But it does not stop an attacker from reading arbitrary values from any table in any of the databases the MySQL user has read-permissions to (which in many cases is every database on the server).
And if an attacker can effectively dump your database, generally it's a matter of cracking admin password hashes and using those to login and escalate their access. DBAs really play no part in any of that; it is the developers of the application who must be blamed here. It's their job to use good hashing mechanisms, and to prevent admin accounts from being able to escalate privileges and upload a shell to the server. And above all, to code securely and prevent SQL injection in the first place.
Also, this isn't reddit, please don't say "I know I'll get downvoted for this."
Question: Can/do they do "fuzzing" on their database applications? Has anyone built a fuzzer for this purpose that tries an assortment of possible vectors as well as random strings? I still do not understand why the injection vectors cannot be preempted to begin with. It seems to me as if the folks securing the database are unable to predict possible ways someone could exploit what their application considers "valid" queries. If so, why?
Also, I don't follow reddit, so I didn't know they say that.
You're attacking the problem from the wrong angle. The fault lies with whomever builds the application /interfacing/ with the DB, not whomever manages the database.
In an application you may need to read user-selected data from some sort of database. As a simple example, you might accept a user's input of an article ID to fetch said article from a db. That might look something like this:
"SELECT * FROM articles WHERE id = $article_id"
Where $article_id is the input you received from your user. A valid $article_id could for example be "7", an invalid one might be "7 OR 1=1". If the latter value is not escaped, it'd change the statement to read "SELECT * FROM articles WHERE id = 7 OR 1=1, returning all articles.
Any somewhat competent programmer would then check if $article_id contains a value of the expected type (i.e. integer, string, string that looks like an email address, ...) and use an escaping function (in PHP this might be mysql_real_escape_string) to escape any special characters (e.g. turn " into \").
If you're doing things right, you'll use a prepared statement. You'll tell your database driver the format of your query first ("SELECT * FROM articles where id = ?"), then provide the contents for your placeholders (? -> $article_id).
Prepared statements are considered more elegant and comfortable to work with; both approaches are secure when done correctly.
All of this is done by the application developer. Now the DBA only gets to work with the assembled query. How would they be able to tell a valid "OR 1=1" from an injected one?
Nonetheless, your point on holding the responsible party accountable stands -- but it's the developers, not the DBAs.
I assumed (incorrectly) that the person designing the database was also involved in selecting the "prepared statements" or "assembled queries", or was the same person.
Now I'm thinking the problem may be more with the people building the interfaces to these SQL databases, and the languages they are using to build them.
If that's true, then "SQL injection" seems like less of an SQL-specific problem and more of popular label for a more general "santization of user input" in internet-facing programs problem. That problem is as old as the web. And now we encourage every program to be a web-facing application, hosted in "the cloud". Yikes.
Anyway, I think my original comment may indeed be valid: in 200xx, in too many cases, programmer knowledge of escaping and quoting (rules that if I'm not mistaken originated when more people were more familiar with terminals and shells) is inadequate.
To answer your second question, Standard Query Language is very, very complicated, and you would have to be a genius to make a proper input scrubber. That's why you are supposed to use things like parameterized queries and bypass the danger of sql injection entirely. However, security mistakes still happen, and you should code in such a way that database leaks are not catastrophic.
They can do the basic things: don't use the root MySQL user, restrict privileges on each MySQL user, use AppArmor or SELinux to isolate the mysqld process, etc. This does prevent an attacker, in most cases, from instantly uploading a shell as soon as they find any sort of injection vector.
But it does not stop an attacker from reading arbitrary values from any table in any of the databases the MySQL user has read-permissions to (which in many cases is every database on the server).
And if an attacker can effectively dump your database, generally it's a matter of cracking admin password hashes and using those to login and escalate their access. DBAs really play no part in any of that; it is the developers of the application who must be blamed here. It's their job to use good hashing mechanisms, and to prevent admin accounts from being able to escalate privileges and upload a shell to the server. And above all, to code securely and prevent SQL injection in the first place.
Also, this isn't reddit, please don't say "I know I'll get downvoted for this."