Как предотвратить SQL-инъекцию, если у меня нет возможности использовать «PreparedStatement» в Java / J2EE

Question

У меня есть одно приложение, в котором я не могу использовать «PreparedStatement» в некоторых местах.

Большинство запросов SQL похожи на….String sql = "delete from" + tableName;

Так что мне нравится знать, как исправить проблему «SQL-инъекция» в моем коде.

С уважением, Санджай Сингх

======================= Отредактировано После получения ответа и нравится проверять решение ========== В соответствии с предложенным предложением я определил одну стратегию предотвращения внедрения SQL в моем случае….Хотелось бы узнать представления, я работаю над сертификатом VeraCode для нашего приложения…

Фильтр данных, чтобы он не содержал пробелов и не экранировал символ SQL (поэтому, если есть какой-либо внедренный код, он не будетчасть моего динамического SQL, поэтому имя моего столбца и имя таблицы нельзя использовать для вставки SQL-запроса).

public static String getTabColName (String tabColName)
{
if (tabColName == null|| "" .equals (tabColName.trim ()))
return "";
String tempStr = StringEscapeUtils.escapeSql (tabColName.trim ());
// Если это значение содержимого пространства, это означаетэто недопустимая таблица
// или имя столбца, поэтому не используйте его в динамически генерируемом SQL
// используйте пробел, чтобы создать недопустимый запрос SQL
return tempStr.indexOf ('')== -1?tempStr: "";
} ​​

Answer 1

Параметризованные запросы являются важным шагом на пути предотвращения атак SQL-инъекций. Если вы не можете их использовать, у вас есть такой же серьезный удар в ваших руках. Вы можете несколько смягчить опасность с помощью:

• проверка входной строки. И я имею в виду валидацию со всеми прибамбасами, которые иногда могут достигать уровня полноценного парсера, а не только нескольких проверок.

• манипулирование вводом (например, цитирование и экранирование строки). Опять же, вы должны сделать это правильно, что может быть сложнее, чем кажется.

Обе технологии проблематичны - вы должны разрешить действительный ввод через без изменений , чтобы поддерживать совместимость с вашей текущей кодовой базой, в то же время эффективно защищая вашу систему. Удачи с этим ...

Исходя из моего опыта, рефакторинг - или даже переписывание - ваш код для использования подготовленных операторов сэкономит вам много времени и слез в долгосрочной перспективе.

Answer 2

Убедиться в том, что ввод содержит только разрешенные символы, является лишь важным первым шагом. Ваш пример оператора является хорошим примером для значения стратегии «найти вход в списке всех хороших значений» (вы наверняка знаете, набор таблиц в вашей базе данных и подмножество таблиц, которые разрешено использовать пользователям). «Сравните входные данные с правдоподобным диапазоном» (зарплата не должна быть увеличена на миллионы или полцента), или «сопоставьте входные данные с регулярным выражением, чтобы выявить структурные нарушения», - другие примеры.

Чтобы обрести уверенность в своей защите, вы можете рассмотреть возможность использования библиотеки тестирования, подобной QuickCheck, для атаки на ваши функции проверки (подходящим образом смещенными) случайными строками. В этой статье перечислены реализации для языков, отличных от Haskell.

Answer 3

Если у вас нет рецензируемой библиотеки функций экранирования строк, по крайней мере, вы должны использовать символы белого списка, которые, как вы знаете, безопасны для встраивания в строки.Например, убедитесь, что ваши строки состоят только из букв, цифр и подчеркиваний, и ничего больше.Черный список известных "плохих персонажей" готов доставить вам неприятности.