Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
 Борьба с sql injections - локальное решение  [new]
анонимный
Guest
Здравствуйте, уважаемые гуры.
Я поддерживаю веб-приложение, которое постоянно подвергается попыткам взлома.
Использую хранимые процедуры, типизированые параметры, роли, и прочее, что доктор прописал, чтобы минимализировать опастность.
Но все равно остаются лазейки, наверное. Я не очень опчтный специалист.
И вот сейчас в голове одна идея, настолько простая, что я думаю, что я не вижу, что где-то у меня дырка в логике.
Скажите - в чем я не прав?
Все запросы, в которых от пользователя могут понадобиться текстовые данные - это имя, фамилия, улица, и тому подобное.
Приложение не интернациональное - только русские имена, название улиц и т.д.
И вот простая мысль - почему просто не проверять данные полученные от пользователя на наличие ключевых слов, таких как select, insert, delete, отклонять такие запросы, и все, можно спать спокойно.
Решение настолько простое, что думаю, что не вижу, что где-то у меня очевидная дырка в логике.
Подскажите пожалуйста, в чем я ошибаюсь?
12 дек 11, 11:22    [11747632]     Ответить | Цитировать Сообщить модератору
 Re: Борьба с sql injections - локальное решение  [new]
The Dim!
Member

Откуда: г. Белгород
Сообщений: 2171
А какми образом база данных взаимодействует с внешним миром?
Если WEB, то есть CMS, вот пусть она и фильтрует - вы изобретаете велосипед...

P.S.
В каком именно месте вы собираетесь фильтр поставить, ядро сиквеля перепишите? Так что в такой постановке вопроса как у Вас к MS SQL Server это не имеет никакого отношения.
12 дек 11, 11:30    [11747718]     Ответить | Цитировать Сообщить модератору
 Re: Борьба с sql injections - локальное решение  [new]
анонимный
Guest
The Dim!
А какми образом база данных взаимодействует с внешним миром?
Если WEB, то есть CMS, вот пусть она и фильтрует - вы изобретаете велосипед...


смс нету, велосипед изобретен до меня, переписывать никто не будет, я просто поддерживаю, и хочу спать спокойно :)


автор
P.S.
В каком именно месте вы собираетесь фильтр поставить, ядро сиквеля перепишите? Так что в такой постановке вопроса как у Вас к MS SQL Server это не имеет никакого отношения.


Да, наверное не в той ветке вопрос задал.
Проверять я буду в клиентском приложении.
В таком контексте не имеет значение - мс скл это, или постгри, например

П.С. И все-таки в такой посоновке - получается - это решает все мои вопросы, или я не понимаю чего-то?
12 дек 11, 11:36    [11747759]     Ответить | Цитировать Сообщить модератору
 Re: Борьба с sql injections - локальное решение  [new]
The Dim!
Member

Откуда: г. Белгород
Сообщений: 2171
Ну видете-ли... хрустальные шары опять нынче не работают, поэтому все проблемы или не все...

По сути. Ну поставить вы клиентском приложении защиту... и от кого она - от дурака-программиста...
Что мне помешает подключиться к Вашему сиквелю и выполнить "произвольный код"?
Такая проверка должна быть перед базой но после формирования клиентом запроса, описанная Вами проблема актуально для систем где клиентское приложение:
а) Обращается непосредственно к СУБД;
б) имеется возможность ввести произвольный запрос или модифицировать существующй до отправки его серверу.
12 дек 11, 11:41    [11747804]     Ответить | Цитировать Сообщить модератору
 Re: Борьба с sql injections - локальное решение  [new]
анонимный
Guest
The Dim!
Ну видете-ли... хрустальные шары опять нынче не работают, поэтому все проблемы или не все...

По сути. Ну поставить вы клиентском приложении защиту... и от кого она - от дурака-программиста...
Что мне помешает подключиться к Вашему сиквелю и выполнить "произвольный код"?
Такая проверка должна быть перед базой но после формирования клиентом запроса, описанная Вами проблема актуально для систем где клиентское приложение:
а) Обращается непосредственно к СУБД;
б) имеется возможность ввести произвольный запрос или модифицировать существующй до отправки его серверу.


Да, клиентское веб-приложение непосредственно работает с базой.
Я думал фильтровать параметры полученные от пользователя сразу по получении?
12 дек 11, 11:48    [11747864]     Ответить | Цитировать Сообщить модератору
 Re: Борьба с sql injections - локальное решение  [new]
The Dim!
Member

Откуда: г. Белгород
Сообщений: 2171
Клиентское WEB приложение работает с базой... но CMS нету...
Это как, HTML/JScript нынче умеют напрямую с драйверами баз данных работать )))
Значит, у вас есть своя CMS - WEB сервер, которы обрабатывает запросы. Вот там и пилите.

>Я думал фильтровать параметры полученные от пользователя сразу по получении?
Это где?
12 дек 11, 11:52    [11747906]     Ответить | Цитировать Сообщить модератору
 Re: Борьба с sql injections - локальное решение  [new]
анонимный
Guest
The Dim!
Клиентское WEB приложение работает с базой... но CMS нету...
Это как, HTML/JScript нынче умеют напрямую с драйверами баз данных работать )))
Значит, у вас есть своя CMS - WEB сервер, которы обрабатывает запросы. Вот там и пилите.

>Я думал фильтровать параметры полученные от пользователя сразу по получении?
Это где?


Ну все на одном сервере.
И база, и клиентский код.
То, что есть - смс язык не поворачивается просто назвать.
Просто куча кода.

Значит я правильно думаю, что это еще снизит опастность.
Спасибо вам за участие :)
12 дек 11, 11:55    [11747939]     Ответить | Цитировать Сообщить модератору
 Re: Борьба с sql injections - локальное решение  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6724
анонимный
Значит я правильно думаю, что это еще снизит опастность.
Нет. Опастности столко же.
А вот проблемы пользователям налицо.

Если у вас есть намерения писать код для фильтров. То вместо этого тупо проанализируйте код (во всех местах где вы хотели вписать фильтр). И пользы больше и эффект тот же, и при тех же затратах.
12 дек 11, 13:46    [11749204]     Ответить | Цитировать Сообщить модератору
 Re: Борьба с sql injections - локальное решение  [new]
анонимный
Guest
Mnior
Нет. Опастности столко же.

Не понимаю. Почему если я вычищаю параметры, опастности столько-же?
Если нет скл-инструкций, то как можно сделать скл-инжекшен?

Mnior
А вот проблемы пользователям налицо.

Не понял, какие проблемы пользователям?

автор
Если у вас есть намерения писать код для фильтров. То вместо этого тупо проанализируйте код (во всех местах где вы хотели вписать фильтр). И пользы больше и эффект тот же, и при тех же затратах.

Есть нечто, что условно назовем "слоем доступа к данным", а именно - несколько скриптовых файлов, которые выполняют непосредственное взаимодействие с сервером базы данных.
и есть штук 50 сайтов, которые используют этот dal
у каждого такого сайта есть куча кода, в котором есть своя бизнес логика
все это хозяйстко лежит на одном(нашем) сервере
тупо проанализирповать это количество кода займет месяцы, а также разрыв мозга обеспечен
не проще ли заткнуть дырку в одном месте?

не сердитесь, объясните, почему опастность не снижается?
12 дек 11, 18:51    [11752259]     Ответить | Цитировать Сообщить модератору
 Re: Борьба с sql injections - локальное решение  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6724
анонимный
Почему если я вычищаю параметры, опастности столько-же?
Патамушта тяжело всё вычистить:
'DR' + 'OP TA' + 'BLE Us' + 'ers'
анонимный
Не понял, какие проблемы пользователям?
Банально. Вот например, лично я не могу вот тут написать слово целиком 'xp_cmd' + 'shell'. В всё из-за тупых ограничений файервола.
А вы можете запретить набор символов и комбинаций, необходимый / желательный на одном из вашем 50 сайтов.

В итоге никаких гарантий. Во всяком случае измеряемых.
анонимный
Есть нечто, что условно назовем "слоем доступа к данным", а именно - несколько скриптовых файлов, которые выполняют непосредственное взаимодействие с сервером базы данных.
и есть штук 50 сайтов, которые используют этот dal
Т.е. на уровне этих нескольких файлов вы можете поствить фильтр, а проверить их код нет? (не тех 50 сайтов)

А) Если на основе этих пару файлов вы не можете сделать SQL Injection, то фильтр не нужен
Б) Если на основе этих пару файлов вы можете сделать SQL Injection, то фильтры вы даже всунуть в него не сможете.
Третьего не дано.

SQL Injection это проблемы интерфейса, а не кода. Запрос либо константа с параметрами или у вас есть Injection.

Фильтр помогает если вы явно будете его использовать в этих 100500 файлах кода.

CMS в 90% случае не фильтрует, а предоставляет интерфейс разработки бизнес логики, минимизирующий написание потенциально опасного кода. И только в (1%) случаях где есть сложная динимика запроса (с попаданием данных в тело запроса), только там и срабатывает фильтр.
Т.е. есть существует класс QueryBuilder/QueryFormat у которого также можно подавать только константы и параметры, но только у него и фильтруются параметры (которые формируют сам запрос).

Это всё к тому что вы, скорее всего, оперируете эфемерным понятием "поставлю фильтр".
Хотя не так много тех кто понимает что 95% окружающего это симулякры.
12 дек 11, 19:46    [11752589]     Ответить | Цитировать Сообщить модератору
 Re: Борьба с sql injections - локальное решение  [new]
анонимный
Guest
Mnior,

Спасибо за такой развернутый ответ.
Я постараюсь объяснить подробней.

Есть некое количество сайтов.
В любом из сайтов, в любом из скриптов может быть(и есть)нечто вроде:
query = 'SELECT u.* FROM t_users u WHERE u.id = ' + request('id')

то-есть зияющая дыра
почему так получилось - дело прошлое, и останется на совести "изготовителей" этих сайтов
нету совершенно никакой временной и материальной возможности осилить( а тем паче переписать )ЭТО
есть желание прикрыть зад
и есть возможность сделать так:
header(пофигу, какой сайт)

include filter;
filter.exec(request)
....
in filter:
defun exec(params)
    params.each(p){ p.replace(['select', 'delete'], '')

по любому это резко снижает угрозу
да, возможно пользователи пострадают где-то(хотя наврядли, я писал - работа только с русским текстом)
но хотя-бы данные с гораздо большей вероятностью уцелеют.
разве не так?
12 дек 11, 23:42    [11753626]     Ответить | Цитировать Сообщить модератору
 Re: Борьба с sql injections - локальное решение  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6724
анонимный
может быть(и есть)нечто вроде:
query = 'SELECT u.* FROM t_users u WHERE u.id = ' + request('id')
А если там не только из request?
анонимный
Для каждого сайта
header(пофигу, какой сайт)
include filter;
filter.exec(request)
Рубим с плеча. Ээх.
И теперь для каждого HTTP запроса, для каждого параметра проверка. И сайты присели.
анонимный
in filter:
defun exec(params)
    params.each(p){ p.replace(['select', 'delete'], '')
по любому это резко снижает угрозу
Как вы видите, проверка только для явных тупых запросов в вакууме. Нормальный взломщик так явно не напишет.
анонимный
но хотя-бы данные с гораздо большей вероятностью уцелеют
Пока только от случайных ошибок. Главное что вы признали, что защита не гарантированная и неизвестно на сколько эффективная.
Не зная всего разнообразия типов запросов нельзя ничего сказать. Банально, если в некоторых запросах нет терминироавания кавычек, то это незакрываемое технологическое отверстие. А т.к. где-то есть терминирование, то вы либо запретите кавычки для ввода или пойдут дубли в данных.

Но фиговее то что это может нарушить эти говно-скрипты. А вдруг SELECT / DELETE / кавычки приходят с брузера.

А вот вам на злобу дня:
invm
Быдлокодерство выгодно всем, кроме конечного пользователя. Поэтому оно и поощряется всячески.
Вы должны эйфорически радоваться, у вас есть работа.
13 дек 11, 12:27    [11755377]     Ответить | Цитировать Сообщить модератору
 Re: Борьба с sql injections - локальное решение  [new]
invm
Member

Откуда: Москва
Сообщений: 9842
анонимный,

Версия сервера?
Каковы полномочия учетки, под которой все это хозяйство работает?
Каково соотношение запросов на чтение и вставку/модификацию/удаление?
13 дек 11, 14:07    [11756376]     Ответить | Цитировать Сообщить модератору
 Re: Борьба с sql injections - локальное решение  [new]
The Dim!
Member

Откуда: г. Белгород
Сообщений: 2171
А зачем вам фильтр, если вы используете хранимки - как я понял - которые клиентами и вызываются. Т.е. от клиента не прелетает SQL-запроса а приходит вызов хранимки, или я не так понял?
13 дек 11, 15:02    [11756987]     Ответить | Цитировать Сообщить модератору
 Re: Борьба с sql injections - локальное решение  [new]
Deff
Member

Откуда: Пермь
Сообщений: 18328
Я вообще не понимаю в че проблема.
Есть же sp_executesql, которая решат проблему sql injections.
14 дек 11, 10:55    [11762178]     Ответить | Цитировать Сообщить модератору
 Re: Борьба с sql injections - локальное решение  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6724
Deff
Я вообще не понимаю в че проблема.
Есть же sp_executesql, которая решат проблему sql injections.
Для пяйсателей:
анонимный
и есть штук 50 сайтов, которые используют этот dal
у каждого такого сайта есть куча кода, в котором есть своя бизнес логика
тупо проанализирповать это количество кода займет месяцы, а также разрыв мозга обеспечен
14 дек 11, 11:25    [11762454]     Ответить | Цитировать Сообщить модератору
 Re: Борьба с sql injections - локальное решение  [new]
Deff
Member

Откуда: Пермь
Сообщений: 18328
Mnior
Deff
Я вообще не понимаю в че проблема.
Есть же sp_executesql, которая решат проблему sql injections.
Для пяйсателей:
анонимный
и есть штук 50 сайтов, которые используют этот dal
у каждого такого сайта есть куча кода, в котором есть своя бизнес логика
тупо проанализирповать это количество кода займет месяцы, а также разрыв мозга обеспечен


Читать надо первый и последний пост.
автор
Использую хранимые процедуры, типизированые параметры, роли, и прочее, что доктор прописал, чтобы минимализировать опастность.
Т.е. код таки собирается на сервере, а значит можно все еxec заменить на sp_executesql.
Не легко конечно, но речи по крайней мере не идет по 50 сайтах.
14 дек 11, 11:35    [11762544]     Ответить | Цитировать Сообщить модератору
 Re: Борьба с sql injections - локальное решение  [new]
Maxx
Member [скрыт]

Откуда:
Сообщений: 24290
а права юхверям настроить не пробовали ? DDL триггера на уровне БД например....
у вас что все имеют права на все ???? Если да - то умудохаетесь писать проверки,честное слово
14 дек 11, 11:40    [11762599]     Ответить | Цитировать Сообщить модератору
 Re: Борьба с sql injections - локальное решение  [new]
Jovanny
Member

Откуда:
Сообщений: 1196
Deff
Есть же sp_executesql, которая решат проблему sql injections.

А можно ссылочку? Как-то я упустил этот момент.
14 дек 11, 11:42    [11762610]     Ответить | Цитировать Сообщить модератору
 Re: Борьба с sql injections - локальное решение  [new]
Maxx
Member [скрыт]

Откуда:
Сообщений: 24290
Jovanny,

BOL
14 дек 11, 11:43    [11762615]     Ответить | Цитировать Сообщить модератору
 Re: Борьба с sql injections - локальное решение  [new]
Deff
Member

Откуда: Пермь
Сообщений: 18328
Jovanny
Deff
Есть же sp_executesql, которая решат проблему sql injections.

А можно ссылочку? Как-то я упустил этот момент.


exec sp_executesql N'SELECT * from table1 where Name = @Name', N'@Name varchar(100)', 'UserName'

Это безопасный код.
14 дек 11, 11:49    [11762669]     Ответить | Цитировать Сообщить модератору
 Re: Борьба с sql injections - локальное решение  [new]
Jovanny
Member

Откуда:
Сообщений: 1196
Maxx,

Огромное спасибо! Прямо не знаю, чтобы я делал!
Открываю http://msdn.microsoft.com/ru-ru/library/ms188001.aspx
и сразу вижу:

Примечание по безопасности

Компиляция инструкций Transact-SQL во время выполнения открывает путь для атак злоумышленников, например, методом SQL injection.
14 дек 11, 11:51    [11762682]     Ответить | Цитировать Сообщить модератору
 Re: Борьба с sql injections - локальное решение  [new]
Jovanny
Member

Откуда:
Сообщений: 1196
Кривым рукам и sp_executesql не поможет. Корректнее будет сказать, не снимает проблему, а снижает вероятность успешной атаки.
14 дек 11, 11:53    [11762702]     Ответить | Цитировать Сообщить модератору
 Re: Борьба с sql injections - локальное решение  [new]
Deff
Member

Откуда: Пермь
Сообщений: 18328
--БЕЗОПАСНЫЙ КОД
exec sp_executesql N'SELECT * from table1 where Name = @Name', N'@Name varchar(100)', 'UserName'


--ОПАСНЫЙ КОД
declare @exec nvarchar(8000)
ser @exec = 'SELECT * from table1 where Name = '+ @Name
exec sp_executesql  @exec
14 дек 11, 11:54    [11762712]     Ответить | Цитировать Сообщить модератору
 Re: Борьба с sql injections - локальное решение  [new]
Maxx
Member [скрыт]

Откуда:
Сообщений: 24290
msdn
not msdn
not msdn2
google
14 дек 11, 11:58    [11762745]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить