Доброго времени суток!

Народ помогите советом!
Есть прослойка между приложением и MSSQL Server. Она умеет генерить запросы из инфы, пришедшей от приложения и выполнять их на сервере. Сейчас это сделано след образом: из запроса от приложения собираются искомые поля и ограничения. На их основе формируется sql запрос в виде строки.(String) Затем Создается Statement и выполняется. Все работает отлично.

Но, наш заказчик тут выдал следущую мысль:

и вот такой пример:


Чем поверг нас в большие непонятки.
Так вот, собственно сам вопрос: чем PreparedStatement лучше с точки зрения какой либо безопасности? 
Или может мы упустили какой то другой момент?

Заранее спасибо!

На мой взгляд, проверки на подставляемые в коде значения надо проводить по мере получения параметров извне (прослойка, браузер или другое приложение). А разница между Statement и PrepareStatement в плане безопасности отстуствует и не надо об этом зацикливаться. Тщательно проверяйте все что идет на входе до выполнения каких-либо операций.

Весьма смелое, но, увы, ошибочное заявление. Чтобы понять, о чем говорит заказчик, надо представлять себе технику SQL injection аттак. Если на пальцах, то примерно следующим образом.

Допустим, на странице вебсайта есть поле для логина/пароля. Что делает злоумыленник? Очень тривиальную вещь! Он исходит из предположения, что параметры входа так или иначе будут использованы серверным скриптом в виде следующей конструкции:



Понятно, что названия столбцов плохишу будут скорее всего неизвестны, но ему это и не нужно. Он просто возьмет и ведет такие значения:

логин: admin
пароль: asdf' or 1 = 1

Нетрудно видеть, что если скрипт не предусматривает защиту от SQL injection, то по исполнении сгенерированного запроса злоумышленнику с радостью предоставят все админские полномочия:



Так вот, в случае использования PreparedStatement такая подстановка в принципе невозможна, что, собственно, и имел в виду заказчик.


Это сообщение отредактировал(а) Stampede - 22.8.2006, 18:39

все верно, надо вырезать "левое" из логина и пароля, а потом подставлять в SQL, неважно как реализуемый

Уххх.... точно... вот это ребусик 
В репу.

Определить, что именно левое, а что правое - в общем случае задача достаточно нетривиальная. К тому же учти, что речь может идти не только о логине, но и о вполне безобидных на первый взгляд запросах, таких как получение списка сообщений, удовлетворяющих некоторому условию.

Поэтому еще раз: если запросы фиксированного формата, то использование PreparedStatement было бы самым простой и естественной формой защиты. Если, как у вас, запросы строятся "на лету", то тут трудно предложить что-либо конкретное, не владея подробной инфой о структуре проложения и характере запросов.

Например, что из себя представляет типичный запрос? Сколько и каких параметров он принимает? Сколько таблиц могут фигурировать в запросе? Откуда берутся метаданные?

Ну и так далее.

Stampede, Огромнейшее спасибо! Есть над чем поразмыслить. Завтра с работы подкину новую партию мыслей для обсуждения.

Stampede, вообще верно, но допустим если у меня еще будет проверка на вводимые числа? Если я в промежутке(допустим вместо пароля пин карточки, что есть цифры) я еще буду проверять чтобы все символы были цифрами, то как минимум наличие пробела и "=" уже не даст дойти до запроса.
А написать такую бональную проверку, две минуты.   

А насколько безопасен такой код:

если логин осуществляется только по e-mail.

Всем спасибо за советы. Ща сидел проверял на подобные штуки наш код. 
Вроде бы мы не наткнулись на эти грабли. Тк все поля обрабатываются и засовываются в ковычки, то пример, приведенный Stampede, не работает. Ща еще капаю в эту сторону. Но пока склоняюсь к тому, что не буду ни чего переделовать 

Интерестно как это у вас происходит, учитываюя что код Stampede работает с кавычками?

http://www.unixwiz.net/techtips/sql-injection.html

К примеру, у нас полдучается вот такой код:

Соответсвенно, OR внутри строкового параметра. Поэтому все норм. 
Я пока не могу говорить, что наш код полностью от этого защищен(Я скорей  уверен в том, что это не так )

Пока ищу еще возможности для атаки.

Ты невнимательно прочитал пост Stampede, там именно такой случай и рассматривается.
Пусть мы генерируем запрос таким макаром:

Если в качестве param передать строку:

То получим запрос:

 Ты идешь моим же путем! Я проверял этот вариант. Но он тоже не проходит, тк наша прога при получении ограничений, просматривает их. Если находит внутри ковычки, то она экранирует их ковычкой. Те этот пример у нас будет выглядеть так:


Большое спасибо за кропотливость!