Если я правильно помню, я думаю, что Джефф упомянул в подкасте Qaru возможную слабость в подготовленных SQL-отчетах. Мне интересно, к каким типам (-ам) слабости (-ов) он обращался? Возможно ли это примерно в неправильном использовании или что-то более зловещее?
Подкаст, к моему воспоминанию, не стал углубляться в тему, это было просто пропуском.
Я думаю, что он сказал, что, когда вы используете Подготовленные утверждения, 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 (если используется правильно, а не как второй пример в вашей ссылке).