Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3] 4   вперед  Ctrl      все
 Re: Защита от SQL-инъекций  [new]
Glory
Member

Откуда:
Сообщений: 104751
sphinx_mv
Не подскажете, кому в M$ оторвать руки за передачу нескольких значений в параметр строкой с разделителями (потенциально уязвимо - "by design")? А то я бы с удовольствием...

Передачей откуда ? Из вашего приложения ?
И какое отношение передача параметра имеет к способу формирования конечного текста запроса ?
16 ноя 15, 11:58    [18422821]     Ответить | Цитировать Сообщить модератору
 Re: Защита от SQL-инъекций  [new]
Ruuu
Member

Откуда: Иркутск
Сообщений: 4272
sphinx_mv
Не буду комментировать именно ЭТОТ код, но Вы очевидно, не сталкивались с такой "замечательным" решением внутри SSRS, когда нужно передать несколько значений для одного параметра (для той самой кляузы IN), и для используется передача строки из значений, разделенных запятой.
Теперь вопрос: из каких соображений может возникнуть 100% уверенность, что при парсинге переданного значения такого параметра не будет никаких "интересных" эффектов (хорошо если есть доступ к тексту этого парсера)? И второй вопрос: кто гарантирует, что при переходе на другую версию ПО поведение не изменится (даже для очень некоторых значений входного параметра)?

SQL-инъекция - следствие применения динамического SQL. Полностью отказаться от использования D-SQL не всегда возможно. И не всегда этот запрос можно построить без конкатенации пользовательского ввода.
Конкатенация пользовательского ввода - это уже всё-таки не паратмеризованный sql.
Что касается IN, то его можно заменить на table-valued parameter, или, если клиент не умеет с ними работать, то написать свою табличную функцию для парсинга.

А по-поводу SSRS, я думаю, мы тут говорим о коде на который можем влиять мы.
16 ноя 15, 12:00    [18422836]     Ответить | Цитировать Сообщить модератору
 Re: Защита от SQL-инъекций  [new]
а вы
Guest
Владислав Колосов
alexeyvg
пропущено...
"Бурное воображение"? Это массовая практика "мышкопрограммистов".

С чего это в коде серверной части сайта на веб-сервера можно сделать запрос конкатенированием строк, а в веб-сервисе нельзя?


Вы когда-нибудь писали веб-сервисы? Подозреваю, что нет, т.к. программист должен НАМЕРЕННО заложить в его функционал возможность инъектирования. По дефолту там нет такого.

...где "там"?
применительно к вопросу написания конкретных строчек программного кода, которые писать небезопасно в силу существования сабжа, каков вообще смысл упоминания здесь "__веб__сервисов__"?

в смысле, используемый _вами_ для разработки вебсервисов _фреймворк_ квотирует и эскейпит? ок.
или в смысле, что все что в вебе автоматически безопасно от инъекций? оно же _веб_. и, естественно, сервис.
wcf, soap, rest - вы про что? и кто из них sql пишет?
16 ноя 15, 12:01    [18422841]     Ответить | Цитировать Сообщить модератору
 Re: Защита от SQL-инъекций  [new]
invm
Member

Откуда: Москва
Сообщений: 9836
Не понимаю о чем спор.
Возможность инъекции зависит лишь от способа обработки пользовательского ввода при построении DSQL.
Не важно каким образом это ввод был получен.
16 ноя 15, 12:28    [18423012]     Ответить | Цитировать Сообщить модератору
 Re: Защита от SQL-инъекций  [new]
Glory
Member

Откуда:
Сообщений: 104751
invm
Не понимаю о чем спор.

О том, что хочется порой слепо верить, что кто-то решил эту проблему за тебя )
16 ноя 15, 12:29    [18423018]     Ответить | Цитировать Сообщить модератору
 Re: Защита от SQL-инъекций  [new]
Jaffar
Member

Откуда:
Сообщений: 633
Автор,

==> "where KEY in (123,124,134,342,333,...)"


Заменяется элементарно на параметр
без динамики

declare @PARAm1 varchar(max)
-----------------------------------
set @PARAM1 = ',1,2,12,123,100500,'
-----------------------------------


select t.*
from Table_1 t with(nolock)
where
		@Param1 like '%,'+cast(t.ID as varchar(1032))+',%'



Просто нужно продумать механизм взаимодействия сайта и сервера таким образом чтобы безопасность основывалась на принципиальных моментах, (т.е. на отсутствии динамики и прямых запросов на сервер + жестокое попрание в правах) а не на каких-то там самодельных мастырках или чужом говно_коде который с вероятностью 146% "отсекает" инъекции.

если 100500 параметров - то можно использовать xml
или просто собрать параметры в строку типа
'Param1=123, Param2=4, .... ParamN=ЖОПА_1,'
а уже в процедуре распарсить параметры в переменные и использовать, но опять же без динамики.
16 ноя 15, 12:53    [18423148]     Ответить | Цитировать Сообщить модератору
 Re: Защита от SQL-инъекций  [new]
skyANA
Member

Откуда: Зеленоград
Сообщений: 28355
sphinx_mv
skyANA
пропущено...
И? Я до этого ссылку приводил: 18419893.
Та ссылка демонстрирует только Ваше умение пользоваться гуглем.
Если Вы все еще уверены, что параметры защищают от инъекций на 100% - это просто сигнал о том, что Вы не совсем в курсе обсуждаемого вопроса.
Толсто.

Давайте может ещё тот код с точки зрения S.O.L.I.D. разберём?
16 ноя 15, 13:46    [18423567]     Ответить | Цитировать Сообщить модератору
 Re: Защита от SQL-инъекций  [new]
a_voronin
Member

Откуда: Москва
Сообщений: 4897
sphinx_mv
skyANA
пропущено...
Используйте параметры, не занимайтесь ерундой :)
Использование параметров НЕ дает 100% защиты от SQL-инъекций.


Расскажите нам как это сделать? А то мы никак сайт Пентагона никак взломать не можем.
16 ноя 15, 13:47    [18423575]     Ответить | Цитировать Сообщить модератору
 Re: Защита от SQL-инъекций  [new]
sphinx_mv
Member [заблокирован]

Откуда:
Сообщений: 1672
Glory
sphinx_mv
Не подскажете, кому в M$ оторвать руки за передачу нескольких значений в параметр строкой с разделителями (потенциально уязвимо - "by design")? А то я бы с удовольствием...

Передачей откуда ? Из вашего приложения ?
Это Вы про SSRS, и Report Builder? Ни разу не "наши" приложения... :)
Glory
И какое отношение передача параметра имеет к способу формирования конечного текста запроса ?
Способ передачи значений параметров имеет непосредственное отношение к тому, как этот набор параметров может быть использован в запросе. И нет совершенно никакой гарантии, что к написанию запроса, возвращающего набор данных для отчета, не приложил руку какой-нибудь "индусо-студент".
16 ноя 15, 14:17    [18423846]     Ответить | Цитировать Сообщить модератору
 Re: Защита от SQL-инъекций  [new]
Glory
Member

Откуда:
Сообщений: 104751
sphinx_mv
Это Вы про SSRS, и Report Builder? Ни разу не "наши" приложения... :)

А эти приложения сами что ли конкатенируют текст запроса ? Или может все же вы указали так делать
16 ноя 15, 14:21    [18423880]     Ответить | Цитировать Сообщить модератору
 Re: Защита от SQL-инъекций  [new]
a_voronin
Member

Откуда: Москва
Сообщений: 4897
Glory
sphinx_mv
Это Вы про SSRS, и Report Builder? Ни разу не "наши" приложения... :)

А эти приложения сами что ли конкатенируют текст запроса ? Или может все же вы указали так делать


Там прописывается тест запроса. И там есть нормальная система параметров.

Но умники могут там сделать и конкатенацию запросов и дать возможность для инъекций. Так что особого отличия от других систем не вижу. При правильном использовании инъекций не будет. При неправильном будут.
16 ноя 15, 14:40    [18424017]     Ответить | Цитировать Сообщить модератору
 Re: Защита от SQL-инъекций  [new]
Serg_77m
Member

Откуда: Донецк
Сообщений: 237
Jaffar
Автор,
==> "where KEY in (123,124,134,342,333,...)"

Заменяется элементарно на параметр
без динамики

declare @PARAm1 varchar(max)
-----------------------------------
set @PARAM1 = ',1,2,12,123,100500,'
-----------------------------------


select t.*
from Table_1 t with(nolock)
where
		@Param1 like '%,'+cast(t.ID as varchar(1032))+',%'
Да, только поиска по индексу при этом не будет. Впрочем, и это решаемо.
16 ноя 15, 14:43    [18424042]     Ответить | Цитировать Сообщить модератору
 Re: Защита от SQL-инъекций  [new]
sphinx_mv
Member [заблокирован]

Откуда:
Сообщений: 1672
Ruuu
sphinx_mv
Не буду комментировать именно ЭТОТ код, но Вы очевидно, не сталкивались с такой "замечательным" решением внутри SSRS, когда нужно передать несколько значений для одного параметра (для той самой кляузы IN), и для используется передача строки из значений, разделенных запятой.
Теперь вопрос: из каких соображений может возникнуть 100% уверенность, что при парсинге переданного значения такого параметра не будет никаких "интересных" эффектов (хорошо если есть доступ к тексту этого парсера)? И второй вопрос: кто гарантирует, что при переходе на другую версию ПО поведение не изменится (даже для очень некоторых значений входного параметра)?

SQL-инъекция - следствие применения динамического SQL. Полностью отказаться от использования D-SQL не всегда возможно. И не всегда этот запрос можно построить без конкатенации пользовательского ввода.
Конкатенация пользовательского ввода - это уже всё-таки не паратмеризованный sql.
До скольки уровней вложения отслеживать вызовы процедур? Особенно - с учетом того, что не для всех процедур может быть доступ к их определениям. И вполне может оказаться, что в верхнем вызывающем уровне все более-менее нормально, а внизу - дырка на дырке и дыркой погоняет.
Ruuu
Что касается IN, то его можно заменить на table-valued parameter, или, если клиент не умеет с ними работать, то написать свою табличную функцию для парсинга.
Да чего уж там: нам переписать SQL-сервер - как два пальца об асфальт!.. :)
Ruuu
А по-поводу SSRS, я думаю, мы тут говорим о коде на который можем влиять мы.
Даже наличие доступа к коду НЕ гарантирует возможности этот код изменить.
Вы с унаследованным софтом дело имели? Много "интересного" в нем бывает...
Видел систему, которая до сих пор работает на SQL2K. С главный аргументом против элементарной миграции "работает - не трогай".
16 ноя 15, 14:56    [18424118]     Ответить | Цитировать Сообщить модератору
 Re: Защита от SQL-инъекций  [new]
sphinx_mv
Member [заблокирован]

Откуда:
Сообщений: 1672
Glory
sphinx_mv
Это Вы про SSRS, и Report Builder? Ни разу не "наши" приложения... :)

А эти приложения сами что ли конкатенируют текст запроса ? Или может все же вы указали так делать
А если предположить, что вся система чуть по-сложнее велосипеда...
Из процедуры для отчета вызывается другая процедуру, которая вызывает третью и т.д. Ну, а 4-я процедура вообще может запускаться на другом сервере (который может находится не только в другой организации, но и на совершенно другой SQL-платформе от другого вендора), из всего доступа к которому может быть только логин и пароль для подключения и выполнения этой одной конкретной процедуры. Гарантии отсутствия SQL-инъекции никаких - от слова "вообще".
Ну, а значения параметров как передавались, так и передаются как параметры на каждом отдельно взятом уровне.
16 ноя 15, 15:19    [18424260]     Ответить | Цитировать Сообщить модератору
 Re: Защита от SQL-инъекций  [new]
Glory
Member

Откуда:
Сообщений: 104751
sphinx_mv
А если предположить, что вся система чуть по-сложнее велосипеда...

Настолько сложная ? Не, не могу представить

sphinx_mv
Из процедуры для отчета вызывается другая процедуру, которая вызывает третью и т.д. Ну, а 4-я процедура вообще может запускаться на другом сервере (который может находится не только в другой организации, но и на совершенно другой SQL-платформе от другого вендора), из всего доступа к которому может быть только логин и пароль для подключения и выполнения этой одной конкретной процедуры. Гарантии отсутствия SQL-инъекции никаких - от слова "вообще".
Ну, а значения параметров как передавались, так и передаются как параметры на каждом отдельно взятом уровне.

Уровень вложенности как-то связан с увеличением необходимости динамического запроса полученного конкатенацией ?
Гарантию от SQL-инъекции никаких дает четкое выполнение ТЗ, где должно быть описано отсутствие динамики.
И полноценное QA, которое проверит соответствие коду этому ТЗ
16 ноя 15, 15:24    [18424306]     Ответить | Цитировать Сообщить модератору
 Re: Защита от SQL-инъекций  [new]
sphinx_mv
Member [заблокирован]

Откуда:
Сообщений: 1672
Glory
sphinx_mv
А если предположить, что вся система чуть по-сложнее велосипеда...

Настолько сложная ? Не, не могу представить

sphinx_mv
Из процедуры для отчета вызывается другая процедуру, которая вызывает третью и т.д. Ну, а 4-я процедура вообще может запускаться на другом сервере (который может находится не только в другой организации, но и на совершенно другой SQL-платформе от другого вендора), из всего доступа к которому может быть только логин и пароль для подключения и выполнения этой одной конкретной процедуры. Гарантии отсутствия SQL-инъекции никаких - от слова "вообще".
Ну, а значения параметров как передавались, так и передаются как параметры на каждом отдельно взятом уровне.

Уровень вложенности как-то связан с увеличением необходимости динамического запроса полученного конкатенацией ?
Ну, хотя бы вызов хранимой процедуры (с параметрами!) на линк-сервере ORACLE. Кстати, параметры - специфических "оракловских" типов (коллекции, записи, етц.)... И доп-вводная: CLR - не предлагать...
Glory
Гарантию от SQL-инъекции никаких дает четкое выполнение ТЗ, где должно быть описано отсутствие динамики.
И полноценное QA, которое проверит соответствие коду этому ТЗ
Для начала необходимо, чтобы ТЗ соответствовало технологическим ограничениям и возможностям платформы, которую использует заказчик.
16 ноя 15, 23:05    [18426727]     Ответить | Цитировать Сообщить модератору
 Re: Защита от SQL-инъекций  [new]
Okmor
Member

Откуда:
Сообщений: 132
Всем повет.
Информация к размышлениям и вопрос:
Когда-то делал прокси для пробрасывания трафика по авторизации. То есть клиент логинится к проге и та по успешной авторизации пробрасывает трафик на SQL или нет.
Так вот. Трафик без включенного шифрования идёт прямым текстом. То есть все запросы клиента, все параметры запросов, все технические запросы видны лучше чем в профайлере. Чесались руки попробовать динамически изменять запросы, но время проекта поджимало и забросил.
Вопрос: воспримет ли SQL сервер измененный таким образом запрос или отбросить?
Кто с такими инъекциями сталкивался?
17 ноя 15, 03:34    [18427088]     Ответить | Цитировать Сообщить модератору
 Re: Защита от SQL-инъекций  [new]
Glory
Member

Откуда:
Сообщений: 104751
sphinx_mv
Ну, хотя бы вызов хранимой процедуры (с параметрами!) на линк-сервере ORACLE. Кстати, параметры - специфических "оракловских" типов (коллекции, записи, етц.)... И доп-вводная: CLR - не предлагать...

sphinx_mv
Для начала необходимо, чтобы ТЗ соответствовало технологическим ограничениям и возможностям платформы, которую использует заказчик.

Вы слышали сказку про то, как заказчик хотел, чтобы исполнитель из одной шкуры сшил 7 шапок ?
17 ноя 15, 09:35    [18427408]     Ответить | Цитировать Сообщить модератору
 Re: Защита от SQL-инъекций  [new]
Glory
Member

Откуда:
Сообщений: 104751
Okmor
Вопрос: воспримет ли SQL сервер измененный таким образом запрос или отбросить?
Кто с такими инъекциями сталкивался?

Вы собрались на лету подменять последовтельность сетевых пакетов что ли ?
17 ноя 15, 09:36    [18427416]     Ответить | Цитировать Сообщить модератору
 Re: Защита от SQL-инъекций  [new]
sphinx_mv
Member [заблокирован]

Откуда:
Сообщений: 1672
Glory
sphinx_mv
Ну, хотя бы вызов хранимой процедуры (с параметрами!) на линк-сервере ORACLE. Кстати, параметры - специфических "оракловских" типов (коллекции, записи, етц.)... И доп-вводная: CLR - не предлагать...

sphinx_mv
Для начала необходимо, чтобы ТЗ соответствовало технологическим ограничениям и возможностям платформы, которую использует заказчик.

Вы слышали сказку про то, как заказчик хотел, чтобы исполнитель из одной шкуры сшил 7 шапок ?
Другими словами, рассказывать сказки, про то, как плохо использовать динамический SQL, Вы можете, а предложить другое простое и - самое главное! - работающее решение не менее простой задачи по вызову ХП с параметрами "сложного" типа - нет. Бывает...

Да, что там "чужеродный" оракл: не знаете, не сталкивались, и все такое прочее...
Тогда просто попробуйте вызвать запрос (не обязательно ХП, но обязательно с "табличным" параметром) в другой базе данных. Даже на том же самом инстансе SQL-сервера.
17 ноя 15, 10:40    [18427862]     Ответить | Цитировать Сообщить модератору
 Re: Защита от SQL-инъекций  [new]
sphinx_mv
Member [заблокирован]

Откуда:
Сообщений: 1672
Glory
Okmor
Вопрос: воспримет ли SQL сервер измененный таким образом запрос или отбросить?
Кто с такими инъекциями сталкивался?

Вы собрались на лету подменять последовтельность сетевых пакетов что ли ?
Вы в интернет через прокси-сервер никогда не ходили?
17 ноя 15, 10:42    [18427871]     Ответить | Цитировать Сообщить модератору
 Re: Защита от SQL-инъекций  [new]
Glory
Member

Откуда:
Сообщений: 104751
sphinx_mv
Другими словами, рассказывать сказки, про то, как плохо использовать динамический SQL, Вы можете, а предложить другое простое и - самое главное! - работающее решение не менее простой задачи по вызову ХП с параметрами "сложного" типа - нет. Бывает...

Другими словами, если вам нужна шапка, чтобы носить, то она будет одна.
А если вам нужно просто много шапок, то носить вы их не сможете.
И дело не в сложности.

sphinx_mv
Да, что там "чужеродный" оракл: не знаете, не сталкивались, и все такое прочее...
Тогда просто попробуйте вызвать запрос (не обязательно ХП, но обязательно с "табличным" параметром) в другой базе данных. Даже на том же самом инстансе SQL-сервера.

Древние египтяне с помощью рычагов и топоров построили пирамиды. Которые стоят до сих
Все ваши доводы про невозможность решения задачи без _конкатенации строк в запрос_ считают лищь отговорками в духе "ну это же было так трудно сделать". И останусь при своем мнении.

sphinx_mv
Вы в интернет через прокси-сервер никогда не ходили?

Прокси сервер на лету подменяет содержимое сетевых пакетов ?
17 ноя 15, 10:50    [18427954]     Ответить | Цитировать Сообщить модератору
 Re: Защита от SQL-инъекций  [new]
a_voronin
Member

Откуда: Москва
Сообщений: 4897
sphinx_mv
Другими словами, рассказывать сказки, про то, как плохо использовать динамический SQL, Вы можете, а предложить другое простое и - самое главное! - работающее решение не менее простой задачи по вызову ХП с параметрами "сложного" типа - нет. Бывает...


Вопрос в этой теме был про SQL-инъекции при вставке данных введенных в текстовое поле на просторах инета. Вы же ушли в какие-то странные дебри про передачу табличный параметров.

Если вы динамически собираете запрос к сторонней системе, где нет параметризации, никто не отрицает, что можно собрать запрос динамически, но только в том случае, если вы полностью знаете все его части. И обычно это делается на стороне сервера, внутри пакета или процедуры. Но если вам надо в этот динамически созданный запрос подставить что-то, что пришло от пользователя, вы можете в него динамически добавить параметры. И использовать параметры для защиты от инъекций.
17 ноя 15, 11:15    [18428130]     Ответить | Цитировать Сообщить модератору
 Re: Защита от SQL-инъекций  [new]
sphinx_mv
Member [заблокирован]

Откуда:
Сообщений: 1672
Glory
sphinx_mv
Другими словами, рассказывать сказки, про то, как плохо использовать динамический SQL, Вы можете, а предложить другое простое и - самое главное! - работающее решение не менее простой задачи по вызову ХП с параметрами "сложного" типа - нет. Бывает...

Другими словами, если вам нужна шапка, чтобы носить, то она будет одна.
А если вам нужно просто много шапок, то носить вы их не сможете.
И дело не в сложности.
Может, Вам лучше в сказочники податься?
Сугубо потому как есть задача, но конкретно Вы ее решить не можете.
ЗЫ. Могу рассказать сказку про дорогу в лес.
Glory
sphinx_mv
Да, что там "чужеродный" оракл: не знаете, не сталкивались, и все такое прочее...
Тогда просто попробуйте вызвать запрос (не обязательно ХП, но обязательно с "табличным" параметром) в другой базе данных. Даже на том же самом инстансе SQL-сервера.

Древние египтяне с помощью рычагов и топоров построили пирамиды. Которые стоят до сих
Все ваши доводы про невозможность решения задачи без _конкатенации строк в запрос_ считают лищь отговорками в духе "ну это же было так трудно сделать". И останусь при своем мнении.
Где-нибудь можно подсмотреть Ваше "самое лучшее" решение?
Потому как Ваше "бла-бла-бла" слегка приелось...
Glory
sphinx_mv
Вы в интернет через прокси-сервер никогда не ходили?

Прокси сервер на лету подменяет содержимое сетевых пакетов ?
Он может это сделать - "легко и непринужденно" (с)
17 ноя 15, 12:43    [18428705]     Ответить | Цитировать Сообщить модератору
 Re: Защита от SQL-инъекций  [new]
Glory
Member

Откуда:
Сообщений: 104751
sphinx_mv
Может, Вам лучше в сказочники податься?
Сугубо потому как есть задача, но конкретно Вы ее решить не можете.
ЗЫ. Могу рассказать сказку про дорогу в лес.

Я на слабо не ведусь.

sphinx_mv
Где-нибудь можно подсмотреть Ваше "самое лучшее" решение?
Потому как Ваше "бла-бла-бла" слегка приелось...

Бла-блакает пока только вы. Ваши жалобы на "суровые обстоятельства" вызывают зевоту.
Никто не застваляет вас соблюдать защиту от SQL-инъекций.

sphinx_mv
Он может это сделать - "легко и непринужденно" (с)

Охренеть просто. А на что он их заменит ?
17 ноя 15, 12:48    [18428734]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3] 4   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить