Есть ли Java-эквивалент PHP mysql_real_escape_string()?
Это должно избежать попыток SQL-инъекций, прежде чем передавать их в Statement.execute().
Я знаю, что вместо этого могу использовать PreparedStatement, но пусть это будут заявления с одним выстрелом, поэтому их подготовка приведет к снижению производительности . Я уже изменил код для использования PreparedStatement, но с учетом того, как был структурирован существующий код, функция escape() заставит изменения кода намного проще просмотреть и сохранить; Я предпочитаю легко поддерживать код, если нет веской причины для дополнительной сложности. Также PreparedStatements обрабатываются по-разному с помощью базы данных, поэтому это может привести к ошибкам в базе данных, с которой мы не сталкивались раньше, требуя большего тестирования перед выпуском в производство.
Apache StringEscapeUtils escapeSQL() избегает одиночных кавычек.
Послесловие: В окружении, которое я унаследовал, есть много тонкостей, которые я умышленно избегал в моем вопросе.
Рассматриваются две точки:
1) Подготовленные заявления не являются панацеей и не обеспечивают 100% -ную защиту от SQL-инъекций. Некоторые драйверы баз данных создают параметризованные запросы, используя небезопасную конкатенацию строк, а не предварительную компиляцию запроса в двоичную форму. Кроме того, если ваш SQL опирается на хранимые процедуры, вам необходимо убедиться, что хранимые процедуры сами по себе не строят запросы небезопасными способами.
2). Наиболее подготовленная реализация выполнения привязывает оператор к соединению с базой данных, на котором был создан оператор. Если вы используете пул соединений с базой данных, вы должны быть осторожны с используйте подготовленную ссылку справки только с соединением, которое оно было подготовлено. Некоторые механизмы объединения реализуют это прозрачно. В противном случае вы могли бы скомпилировать подготовленные операторы или (простейшие, но дополнительные служебные), создать новый подготовленный оператор для каждого запроса.