SQL-инъекции с подготовленными утверждениями?

Question

Если я правильно помню, я думаю, что Джефф упомянул в подкасте Stack Overflow возможный недостаток подготовленных операторов SQL. Мне интересно, о какой (ых) слабости (с) он имел в виду? Возможно, это просто неуместное использование или что-то более зловещее?

Подкаст, насколько я помню, не углублялся в предмет, это был просто закадровый комментарий.

Answer 1

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

Он также упомянул новую функцию SQL Server 2008, которая заставляет механизм переоценивать планы выполнения, которые он использовал для преодоления этой ситуации.

С подготовленными заявлениями у меня есть только одна проблема. Рассмотрим следующий код Java:

String sql = "select * from table where name like ?";
PreparedStatement pstmt = conn.prepareStatement(sql);
pstmt.setString(1, "PATTERN%");
ResultSet rs = pstmt.executeQuery();

Здесь вы ожидаете, что если у вас есть индекс для таблицы (имя), он будет использоваться планом запроса. Ну, это не так. Потому что PraparedStatement должен прекомпилироваться и ожидать худшего: «% PATTERN%», например. Таким образом, это не будет оптимизировать. Мне потребовалось время, чтобы понять это. Это заставляло мою базу данных страдать. (

Надеюсь, это поможет.

Answer 2

Помимо обычной атаки SQL-инъекцией (то, что мы можем назвать первым порядком), существуют вторичные уровни. Например, нередко хранимые процедуры используют конкатенацию строк для построения запроса, который затем выполняется. Если результат извлеченных значений полей включен в такую ​​конкатенацию, то существует опасность внедрения.

Answer 3

Если подготовленное утверждение имеет параметры, динамически построенные каким-либо образом, то это, скорее всего, будет источником слабости.

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

Помните, только то, что инструкция подготовлена ​​или вы используете хранимую процедуру, не означает, что вы защищены от атак инъекций. Только когда вы используете код поставщика базы данных, который будет очищать ввод параметров (а также применять его ко всем параметрам, которые можно использовать), вы получаете защиту от внедрения SQL.

Answer 4

Я не слушал подкаст, но по моему опыту только хорошее исходит из готовых заявлений. Это часто повышает производительность приложения и предотвращает внедрение SQL-кода (при правильном использовании, а не во втором примере в вашей ссылке).