Клиентский софт не требует защиты от SQL-инъекций. Он может стать только их источником.
Правильное клиентское приложение не содержит полей через которые можно было бы повлиять на формирование непосредственно текста SQL-запроса. Сам текст формируемого запроса скрыт за органами управления: списками, чек-боксами, редакторами текстовых полей... Разве только через последние. Но при формировании фильтров надо анализировать входную информацию из этих полей и они как минимум не должны быть последним звеном SQL-запроса. Если текст без вариантов последний фильтр, то надо в программе (!) предусматривать анализ вводимой информации или использовать маски ввода. Например, жестко фильтровать скобки, запятые...
Со стороны сети уже ничего не сделать. В момент, когда SQL-запрос пульнули на сервер, он на стороне сервера никак не будет отличим от любого другого запроса. На этом и основывается SQL-инъекция. На удачном выполнении сервером любого синтаксически верного SQL-запроса.

А вот всякие веб-системы, принимающие по-дурацки параметры в командной строке и не анализирующие вводимый текст ни на размер, ни на состав - эти подвержены всякого рода SQL-инъекциям. Через адресную строку скриптам через параметры напихивают всякого.

FireMopsТо есть, если в дельфовый Edit/DBEdit записать 'union all select admin_password from ...' это сработает?
У тебя, может, и сработает. Получишь при прочих равных красивый


и успокоишься

Это и в FB можно сделать. При желании можно достаточно параноидально СКД настроить. Именно только через права юзеру на процедуры и просмотры. А к таблицам - неа.
И тогда SQL-инъекции будут бесполезны даже при наличии возможности.
Но и параметризованные запросы, как уже было сказано выше, решают эту проблему. Так что вопрос выбора метода контроля доступа к объектам базы зависит только от тараканов в голове "безопасников".
Но таки да - это уже собственно к инъекциям не имеет ни малейшего отношения.

rdb_dev Если SQL запрос попал в SQL сервер, то да - ничего уже не сделать, но если перед SQL сервером создать фильтр с разбором запросов, который будет знать, как "выглядят" допустимые запросы к серверу и анализировать переменные части запросов, то реализовать защиту от SQL инъекций "на стороне сервера" вполне возможно.
Невозможно. Я как разработчик даже не могу спрогнозировать, что клиенту приспичит выпросить из базы завтра, какой хитровывернутый отчет состряпать, с какими фильтрами, группировками, CTE и прочим. К примеру, UNION используется порой активно и совершенно штатным образом.
И что-то будет изводить меня в результате ложными срабатываниями по принципу "Вы - гнусный хакер! Отвалите!?"?