Внедрения SQL с подготовленными операторами?
РЕШЕНО:
Я добавил более старую версию JNA, не поддерживающую эту функцию, а также версию 4.0.1, при проверке перечисленных зависимостей при удалении старой версии исправлена проблема!
[ 112] Спасибо, @Slaw! Вы указали мне правильное направление, чтобы обнаружить мою ошибку.
4 ответа
Я думаю, что он сказал, был то, что при использовании Подготовленных Операторов 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', например. Так, это не оптимизирует. Это взяло меня некоторое время для понимания этого. Это заставляло мою базу данных страдать.:(
Надежда это помогает.
Вне нормального внедрения SQL (что мы могли бы назвать первым порядком) нападение там является вторичными уровнями. Например, его весьма общие, чтобы иметь хранимые процедуры используют конкатенацию строк для создания запроса, который она затем выполняет. Если результат полученных значений полей включен в такую конкатенацию затем существует опасность инжекции.
Если оператору, который подготовлен, создали параметры динамично всегда, то это больше, чем, вероятно, было бы источником слабости.
Если Вы пользуетесь надлежащей библиотекой базы данных с протестированными классами для установки параметров, то Вы не открываете себя до Внедрения SQL ни в какой точке, подготовленном операторе или нет.
Помните, просто потому что оператор подготовлен, или потому что Вы используете хранимую процедуру, это не означает, что Вы в безопасности от инжекционных нападений. Это только, когда Вы используете код поставщика БД, который санирует вход параметров (а также применение его ко всем параметрам, которые могут использоваться), что Вы получаете защиту от Внедрения SQL.
Я не слушал подкаст, но по моему опыту только хороший прибывает из подготовленных операторов. Это часто улучшает производительность приложения и предотвращает Внедрение SQL (если используемое право, не как второй пример в Вашей ссылке).