Если я правильно помню, я думаю, что Джефф упомянул в подкасте Stack Overflow возможную слабость в подготовленных операторах 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 (при правильном использовании, а не как второй пример в вашей ссылке).
