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

Откуда: Москва
Сообщений: 9836
Владислав Колосов
С какой стати, интересно, веб-метод должен выполнять прямые запросы, переданные в параметрах?
А каким образом веб-метод предотвратит инъекцию при вызове ХП, строящей DSQL из значений параметров?
13 ноя 15, 12:24    [18411474]     Ответить | Цитировать Сообщить модератору
 Re: Защита от SQL-инъекций  [new]
Владислав Колосов
Member

Откуда:
Сообщений: 8815
Вы занимаетесь софистикой и лукавите, молотком ведь не только гвозди можно забивать или пилой не только бревна пилить. Если разработчик веб-метода понимает риски, он сделает то, о чем вы все пишите, но веб-методов, реализующих сквозные запросы, из параметров быть не должно в безопасно построенной системе.
13 ноя 15, 12:42    [18411599]     Ответить | Цитировать Сообщить модератору
 Re: Защита от SQL-инъекций  [new]
Glory
Member

Откуда:
Сообщений: 104751
Владислав Колосов
Вы занимаетесь софистикой и лукавите

По-моему, это делаете вы. Призывая верить в то, что неизвестно кем и как написанный веб-метод гарантирует отсутствие инъекции
13 ноя 15, 12:45    [18411613]     Ответить | Цитировать Сообщить модератору
 Re: Защита от SQL-инъекций  [new]
Владислав Колосов
Member

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

почему неизвестно кем? ТС задал вопрос от своего имени - что мне делать, чтобы защититься от инъекций. Я ответил - использовать веб-методы при разработке клиент-серверного веб-приложения. Тут же нашли желающие указать на то, что можно написать такой метод, который позволит инъекции. Но для того ТС должен сознательно написать такой метод. Зачем же ему это делать?
13 ноя 15, 12:58    [18411690]     Ответить | Цитировать Сообщить модератору
 Re: Защита от SQL-инъекций  [new]
Glory
Member

Откуда:
Сообщений: 104751
Владислав Колосов
почему неизвестно кем?

Вы знаете всех создателей всех вебметодов лично ? И они вам присылали исходные коды этих веб-методов ?

Владислав Колосов
ТС задал вопрос от своего имени - что мне делать, чтобы защититься от инъекций. Я ответил - использовать веб-методы при разработке клиент-серверного веб-приложения.

Ага. Используйте правильно написанные программы, чтобы получить правильные результаты.
13 ноя 15, 13:05    [18411731]     Ответить | Цитировать Сообщить модератору
 Re: Защита от SQL-инъекций  [new]
Зайцев Фёдор
Member

Откуда: Лужки
Сообщений: 5308
первый же ответ в теме был верным и исчерпывающим.
что вы обсуждаете? можно мне тоже всякую ерунду пообсуждать?
Serg_77m
А если так?
string sql = "select SOME,THING from SOMETABLE where KEY=N'" + UserInput.Text.Replace("'","''") + "'";

пожалуйста, признайтесь, какая цель преследуется при UserInput.Text.Replace("'","''") ?
13 ноя 15, 19:59    [18414371]     Ответить | Цитировать Сообщить модератору
 Re: Защита от SQL-инъекций  [new]
Serg_77m
Member

Откуда: Донецк
Сообщений: 237
Зайцев Фёдор
пожалуйста, признайтесь, какая цель преследуется при UserInput.Text.Replace("'","''") ?
Удвоить одинарные кавычки в пользовательском вводе. Чтобы введённая кавычка не сломала синтаксис запроса (открывая дыру для инъекций), а корректно передалась в условие поиска.
13 ноя 15, 21:22    [18414702]     Ответить | Цитировать Сообщить модератору
 Re: Защита от SQL-инъекций  [new]
makar182
Member

Откуда:
Сообщений: 36
alexeyvg
Но делать такую строку в клиенте "EXEC PROC_CREATE_USER @NAME = ..." нельзя, нужно вызывать процедуру с параметрами.


Уточню - т.е. надо использовать sp_executesql? А в чем проблема использования "EXEC PROC_CREATE_USER @NAME = ...", что в нем плохого?
14 ноя 15, 01:19    [18415771]     Ответить | Цитировать Сообщить модератору
 Re: Защита от SQL-инъекций  [new]
а если подорожник приложить
Guest
makar182,

вы до текста с описанием проблематики sql-инъекций доберетесь когда-нибудь?
14 ноя 15, 10:38    [18416311]     Ответить | Цитировать Сообщить модератору
 Re: Защита от SQL-инъекций  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31961
Владислав Колосов
alexeyvg
пропущено...
Да-да. Пользователь вводит строку, строка передаётся веб-сервису, веб-сервис её выполняет от имени сисадмина на сервере :-)

От названия технологий и количества уровней защита не зависит. Это разводить тупых менеджеров не-технарей хорошо.
С какой стати, интересно, веб-метод должен выполнять прямые запросы, переданные в параметрах? Это уж очень бурное воображение должно быть, чтобы реализовать такой метод :)
"Бурное воображение"? Это массовая практика "мышкопрограммистов".

С чего это в коде серверной части сайта на веб-сервера можно сделать запрос конкатенированием строк, а в веб-сервисе нельзя?
14 ноя 15, 12:02    [18416465]     Ответить | Цитировать Сообщить модератору
 Re: Защита от SQL-инъекций  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31961
Зайцев Фёдор
первый же ответ в теме был верным и исчерпывающим.
что вы обсуждаете? можно мне тоже всякую ерунду пообсуждать?
Serg_77m
А если так?
string sql = "select SOME,THING from SOMETABLE where KEY=N'" + UserInput.Text.Replace("'","''") + "'";


пожалуйста, признайтесь, какая цель преследуется при UserInput.Text.Replace("'","''") ?
Ну как, это хзамечание по теме топика - это защищает от инжекшенов. Любой текст, который передаст злоумышленник, останется просто строковой константой в запросе.

Риски тут уже будут другие, о которых я выше написал 18409772

makar182
alexeyvg
Но делать такую строку в клиенте "EXEC PROC_CREATE_USER @NAME = ..." нельзя, нужно вызывать процедуру с параметрами.


Уточню - т.е. надо использовать sp_executesql? А в чем проблема использования "EXEC PROC_CREATE_USER @NAME = ...", что в нем плохого?
Проблема в том же - если сделать конкатенированную строку "EXEC PROC_CREATE_USER @NAME = ...", то пользователь может передать дополнительный запрос, кроме самого параметра и вызова процедуры.

Правда, если у вас разрешены только вызовы процедур, то его возможности будут сильно ограничены - но вот Гавриленко Сергей Алексеевич уже выше указал, как можно положить сервер, не имея прав.
14 ноя 15, 12:09    [18416479]     Ответить | Цитировать Сообщить модератору
 Re: Защита от SQL-инъекций  [new]
skyANA
Member

Откуда: Зеленоград
Сообщений: 28355
makar182
alexeyvg
пропущено...
Если пользователь передаёт в процедуру текст, а процедура этот текст выполняет как SQL команды, то сервер уязвим для SQL-иньекций.

Если веб-сайт обращается к СУБД без хранимых процедур, прямыми запросами, но пользователю не предоставляется возможность написать текст, который будет выполняться сайтом на СУБД, то сервер не уязвим для SQL-иньекций.

То есть использование или не использование хранимок никак не кореллируют с этой уязвимостью.


Можете подсказать как защититься от инъекций хоть на каком-то уровне с учетом того, что текст передавать все же можно? И кстати - запрет ввода текста должен быть на стороне Web или, например, данные должны забиваться в переменную типа INT, а значит текст даст ошибку? Web написан на C# (может там что-то можно сделать?)
ASP.NET how to protects from SQL injections
15 ноя 15, 14:39    [18419893]     Ответить | Цитировать Сообщить модератору
 Re: Защита от SQL-инъекций  [new]
skyANA
Member

Откуда: Зеленоград
Сообщений: 28355
Serg_77m
alexeyvg
2. В запросах от веб-сервера не делать строку выполнения конкатенированием с пользовательским вводом. Вместо этого использовать объекты вроде "команда с параметрами" (например, в C# это будет SqlCommand и SqlPaarmeter). Это относится в том числе и к вызовам хранимых процедур.
А если так?
string sql = "select SOME,THING from SOMETABLE where KEY=N'" + UserInput.Text.Replace("'","''") + "'";
Используйте параметры, не занимайтесь ерундой :)

Serg_77m
Иногда параметры неудобны. Примеры:
  • В зависимости от пользовательского ввода добавлять или не добавлять условие во where
  • Сформировать условие вида: "where KEY in (123,124,134,342,333,...)" (список переменный)
  • Что же такого неудобного в дополнительном if и for? Лень писать код? Воспользуйтесь ORM.
    15 ноя 15, 14:58    [18419926]     Ответить | Цитировать Сообщить модератору
     Re: Защита от SQL-инъекций  [new]
    makar182
    Member

    Откуда:
    Сообщений: 36
    alexeyvg
    Зайцев Фёдор
    первый же ответ в теме был верным и исчерпывающим.
    что вы обсуждаете? можно мне тоже всякую ерунду пообсуждать?
    пропущено...

    пожалуйста, признайтесь, какая цель преследуется при UserInput.Text.Replace("'","''") ?
    Ну как, это хзамечание по теме топика - это защищает от инжекшенов. Любой текст, который передаст злоумышленник, останется просто строковой константой в запросе.

    Риски тут уже будут другие, о которых я выше написал 18409772

    makar182
    пропущено...


    Уточню - т.е. надо использовать sp_executesql? А в чем проблема использования "EXEC PROC_CREATE_USER @NAME = ...", что в нем плохого?
    Проблема в том же - если сделать конкатенированную строку "EXEC PROC_CREATE_USER @NAME = ...", то пользователь может передать дополнительный запрос, кроме самого параметра и вызова процедуры.

    Правда, если у вас разрешены только вызовы процедур, то его возможности будут сильно ограничены - но вот Гавриленко Сергей Алексеевич уже выше указал, как можно положить сервер, не имея прав.


    Понял. А вот такой вопрос - а что если создать две БД. Одна БД работает только на прием данных из форм, в этой базе ничего не хранится. Оттуда триггером вся информация заливается во вторую БД и удаляется из первой БД. При этом права пользователю выдать только на первую БД. Это может увеличить безопасность?
    15 ноя 15, 15:58    [18420045]     Ответить | Цитировать Сообщить модератору
     Re: Защита от SQL-инъекций  [new]
    a_voronin
    Member

    Откуда: Москва
    Сообщений: 4900
    makar182
    alexeyvg
    пропущено...
    Ну как, это хзамечание по теме топика - это защищает от инжекшенов. Любой текст, который передаст злоумышленник, останется просто строковой константой в запросе.

    Риски тут уже будут другие, о которых я выше написал 18409772

    пропущено...
    Проблема в том же - если сделать конкатенированную строку "EXEC PROC_CREATE_USER @NAME = ...", то пользователь может передать дополнительный запрос, кроме самого параметра и вызова процедуры.

    Правда, если у вас разрешены только вызовы процедур, то его возможности будут сильно ограничены - но вот Гавриленко Сергей Алексеевич уже выше указал, как можно положить сервер, не имея прав.


    Понял. А вот такой вопрос - а что если создать две БД. Одна БД работает только на прием данных из форм, в этой базе ничего не хранится. Оттуда триггером вся информация заливается во вторую БД и удаляется из первой БД. При этом права пользователю выдать только на первую БД. Это может увеличить безопасность?


    Чем дальше в лес, тем более бредовей у вас становятся идеи.

    Сделайте ORM слой. Вы понимаете что это? Сейчас 2015 год, уже всё придумано.

    Все параметризация уже там сделана и будет сгенерена. Все DROP DATABASE сохраняться в БД как строковые константы.
    15 ноя 15, 16:20    [18420080]     Ответить | Цитировать Сообщить модератору
     Re: Защита от SQL-инъекций  [new]
    sphinx_mv
    Member [заблокирован]

    Откуда:
    Сообщений: 1672
    skyANA
    Serg_77m
    пропущено...
    А если так?
    string sql = "select SOME,THING from SOMETABLE where KEY=N'" + UserInput.Text.Replace("'","''") + "'";
    
    Используйте параметры, не занимайтесь ерундой :)
    Использование параметров НЕ дает 100% защиты от SQL-инъекций.
    15 ноя 15, 21:17    [18421074]     Ответить | Цитировать Сообщить модератору
     Re: Защита от SQL-инъекций  [new]
    sphinx_mv
    Member [заблокирован]

    Откуда:
    Сообщений: 1672
    a_voronin
    Сделайте ORM слой. Вы понимаете что это? Сейчас 2015 год, уже всё придумано.
    Интересно... Какая-нибудь система генерации отчетов имеет хоть какое-то представление о ООП (не говоря уже про ORM)?
    15 ноя 15, 21:20    [18421083]     Ответить | Цитировать Сообщить модератору
     Re: Защита от SQL-инъекций  [new]
    alexeyvg
    Member

    Откуда: Moscow
    Сообщений: 31961
    makar182
    а что если создать две БД. Одна БД работает только на прием данных из форм, в этой базе ничего не хранится. Оттуда триггером вся информация заливается во вторую БД и удаляется из первой БД. При этом права пользователю выдать только на первую БД. Это может увеличить безопасность?
    Ну, тогда защита "дать пользователю только необходимые права" сработает не хуже, если доступ будет уже к нужной базе.

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

    В общем, не нужен этот дополнительный слой, ничего он не даёт.
    a_voronin
    Сделайте ORM слой. Вы понимаете что это? Сейчас 2015 год, уже всё придумано.

    Все параметризация уже там сделана и будет сгенерена. Все DROP DATABASE сохраняться в БД как строковые константы.
    Это называется - использовать правильные библиотеки.

    Модное слово ORM тут совсем не к месту. Параметризация вызовов без ORM делается ничуть не сложнее.

    Это всё равно что написать "Дураки вы все, используйте SAP, все параметризация уже там сделана и будет сгенерена". То есть да, будет использована, будет сгенерена, только это как бы не по теме топика.
    16 ноя 15, 00:40    [18421582]     Ответить | Цитировать Сообщить модератору
     Re: Защита от SQL-инъекций  [new]
    Ruuu
    Member

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

    Вот например, как передать sql-инъекцию в этот код? Или как изменить этот код так, чтобы инъекция была возможна?
    Специально сделал параметр varchar(500), чтобы можно было добавлять инъекции.

    create procedure dbo.usp_testSQLInjection
     @v varchar(500)
    AS
    
    set nocount on
    
    declare @sql nvarchar(max)
    declare @param_list nvarchar(4000)=N'@v varchar(500)'
    
    set @sql=N'/* табличная переменная вместо тестовой таблицы */
    declare @tbl table (v varchar(500))
    
    insert @tbl values (1),(2),(3)
    
    SELECT v
    from @tbl
    where v=@v'
    
    exec sp_executesql @sql, @param_list, @v
    
    GO
    
    EXEC dbo.usp_testSQLInjection @v=1
    GO
    
    DROP PROCEDURE dbo.usp_testSQLInjection
    GO
    
    16 ноя 15, 07:46    [18421805]     Ответить | Цитировать Сообщить модератору
     Re: Защита от SQL-инъекций  [new]
    skyANA
    Member

    Откуда: Зеленоград
    Сообщений: 28355
    sphinx_mv
    skyANA
    пропущено...
    Используйте параметры, не занимайтесь ерундой :)
    Использование параметров НЕ дает 100% защиты от SQL-инъекций.
    И? Я до этого ссылку приводил: 18419893.
    16 ноя 15, 10:18    [18422208]     Ответить | Цитировать Сообщить модератору
     Re: Защита от SQL-инъекций  [new]
    sphinx_mv
    Member [заблокирован]

    Откуда:
    Сообщений: 1672
    Ruuu
    sphinx_mv
    Использование параметров НЕ дает 100% защиты от SQL-инъекций.
    Наверняка и с параметрами можно сделать так, чтобы были возможны инъекции. Но если использовать параметры именно как параметры, то трудно представить как это сделать.

    Вот например, как передать sql-инъекцию в этот код? Или как изменить этот код так, чтобы инъекция была возможна?
    Специально сделал параметр varchar(500), чтобы можно было добавлять инъекции.

    ...
    

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

    SQL-инъекция - следствие применения динамического SQL. Полностью отказаться от использования D-SQL не всегда возможно. И не всегда этот запрос можно построить без конкатенации пользовательского ввода. Соответственно, 100% защиты от инъекций нет.
    16 ноя 15, 10:51    [18422375]     Ответить | Цитировать Сообщить модератору
     Re: Защита от SQL-инъекций  [new]
    sphinx_mv
    Member [заблокирован]

    Откуда:
    Сообщений: 1672
    skyANA
    sphinx_mv
    пропущено...
    Использование параметров НЕ дает 100% защиты от SQL-инъекций.
    И? Я до этого ссылку приводил: 18419893.
    Та ссылка демонстрирует только Ваше умение пользоваться гуглем.
    Если Вы все еще уверены, что параметры защищают от инъекций на 100% - это просто сигнал о том, что Вы не совсем в курсе обсуждаемого вопроса.
    16 ноя 15, 10:55    [18422392]     Ответить | Цитировать Сообщить модератору
     Re: Защита от SQL-инъекций  [new]
    Glory
    Member

    Откуда:
    Сообщений: 104751
    sphinx_mv
    Полностью отказаться от использования D-SQL не всегда возможно. И не всегда этот запрос можно построить без конкатенации пользовательского ввода.

    Ну если писать один типа универсальный запрос, то да. Только за такое руки надо отрывать, а не пенять на "особые обстоятельства"
    16 ноя 15, 10:58    [18422402]     Ответить | Цитировать Сообщить модератору
     Re: Защита от SQL-инъекций  [new]
    Владислав Колосов
    Member

    Откуда:
    Сообщений: 8815
    alexeyvg
    Владислав Колосов
    пропущено...
    С какой стати, интересно, веб-метод должен выполнять прямые запросы, переданные в параметрах? Это уж очень бурное воображение должно быть, чтобы реализовать такой метод :)
    "Бурное воображение"? Это массовая практика "мышкопрограммистов".

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


    Вы когда-нибудь писали веб-сервисы? Подозреваю, что нет, т.к. программист должен НАМЕРЕННО заложить в его функционал возможность инъектирования. По дефолту там нет такого.
    16 ноя 15, 11:41    [18422706]     Ответить | Цитировать Сообщить модератору
     Re: Защита от SQL-инъекций  [new]
    sphinx_mv
    Member [заблокирован]

    Откуда:
    Сообщений: 1672
    Glory
    sphinx_mv
    Полностью отказаться от использования D-SQL не всегда возможно. И не всегда этот запрос можно построить без конкатенации пользовательского ввода.

    Ну если писать один типа универсальный запрос, то да. Только за такое руки надо отрывать, а не пенять на "особые обстоятельства"
    Не подскажете, кому в M$ оторвать руки за передачу нескольких значений в параметр строкой с разделителями (потенциально уязвимо - "by design")? А то я бы с удовольствием...
    16 ноя 15, 11:55    [18422798]     Ответить | Цитировать Сообщить модератору
    Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3 4   вперед  Ctrl      все
    Все форумы / Microsoft SQL Server Ответить