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

Откуда:
Сообщений: 36
Добрый день,

Подскажите, пожалуйста, если web-приложению создать пользователя и выдать ему права только на запуск определенных процедур(в самих процедурах будет происходит необходимая выборка и модификация данных), то поможет ли это избежать SQL-инъекций?

Опираясь на схему, описанную в первом абзаце, если в параметр процедуры, который получен из формы на сайте, подать SQL-код/инъекцию, то будет ли этот код запущен, с учетом того, что права у пользователя есть только на запуск процедуры, но не на её редактирование (а тут ведь получается, что произойдет именно редактирование процедуры, так?)
11 ноя 15, 20:42    [18402644]     Ответить | Цитировать Сообщить модератору
 Re: Защита от SQL-инъекций  [new]
Glory
Member

Откуда:
Сообщений: 104760
makar182
Подскажите, пожалуйста, если web-приложению создать пользователя и выдать ему права только на запуск определенных процедур(в самих процедурах будет происходит необходимая выборка и модификация данных), то поможет ли это избежать SQL-инъекций?

SQL-инъекция возникает не от наличия прав
Она возникает от того, что тексты запросов формируются путем конкатенации фрагментов, задаваемых пользователем
11 ноя 15, 21:01    [18402732]     Ответить | Цитировать Сообщить модератору
 Re: Защита от SQL-инъекций  [new]
makar182
Member

Откуда:
Сообщений: 36
Glory
makar182
Подскажите, пожалуйста, если web-приложению создать пользователя и выдать ему права только на запуск определенных процедур(в самих процедурах будет происходит необходимая выборка и модификация данных), то поможет ли это избежать SQL-инъекций?

SQL-инъекция возникает не от наличия прав
Она возникает от того, что тексты запросов формируются путем конкатенации фрагментов, задаваемых пользователем


Но если у пользователя нет права на запуск каких бы то ни было запросов, кроме определенной процедуры? Если он что-то и передает, то разве это не считается как изменение процедуры, на что, в свою очередь, прав у пользователя нет?
11 ноя 15, 21:34    [18402870]     Ответить | Цитировать Сообщить модератору
 Re: Защита от SQL-инъекций  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31435
makar182
Glory
пропущено...

SQL-инъекция возникает не от наличия прав
Она возникает от того, что тексты запросов формируются путем конкатенации фрагментов, задаваемых пользователем


Но если у пользователя нет права на запуск каких бы то ни было запросов, кроме определенной процедуры? Если он что-то и передает, то разве это не считается как изменение процедуры, на что, в свою очередь, прав у пользователя нет?
Если пользователь передаёт в процедуру текст, а процедура этот текст выполняет как SQL команды, то сервер уязвим для SQL-иньекций.

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

То есть использование или не использование хранимок никак не кореллируют с этой уязвимостью.
11 ноя 15, 21:38    [18402886]     Ответить | Цитировать Сообщить модератору
 Re: Защита от SQL-инъекций  [new]
Glory
Member

Откуда:
Сообщений: 104760
makar182
Но если у пользователя нет права на запуск каких бы то ни было запросов, кроме определенной процедуры? Если он что-то и передает, то разве это не считается как изменение процедуры, на что, в свою очередь, прав у пользователя нет?

Причем здесь права на процедуру ?
SQL injection получается только тогда, когда введенные пользователем данные используются для _формирования текста запроса_.
11 ноя 15, 21:43    [18402903]     Ответить | Цитировать Сообщить модератору
 Re: Защита от SQL-инъекций  [new]
makar182
Member

Откуда:
Сообщений: 36
alexeyvg
makar182
пропущено...


Но если у пользователя нет права на запуск каких бы то ни было запросов, кроме определенной процедуры? Если он что-то и передает, то разве это не считается как изменение процедуры, на что, в свою очередь, прав у пользователя нет?
Если пользователь передаёт в процедуру текст, а процедура этот текст выполняет как SQL команды, то сервер уязвим для SQL-иньекций.

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

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


Можете подсказать как защититься от инъекций хоть на каком-то уровне с учетом того, что текст передавать все же можно? И кстати - запрет ввода текста должен быть на стороне Web или, например, данные должны забиваться в переменную типа INT, а значит текст даст ошибку? Web написан на C# (может там что-то можно сделать?)
11 ноя 15, 22:11    [18403001]     Ответить | Цитировать Сообщить модератору
 Re: Защита от SQL-инъекций  [new]
makar182
Member

Откуда:
Сообщений: 36
Glory
makar182
Но если у пользователя нет права на запуск каких бы то ни было запросов, кроме определенной процедуры? Если он что-то и передает, то разве это не считается как изменение процедуры, на что, в свою очередь, прав у пользователя нет?

Причем здесь права на процедуру ?
SQL injection получается только тогда, когда введенные пользователем данные используются для _формирования текста запроса_.


Мне не понятен сам механизм - если у пользователя права только на запуск процедуры, то как он может запустить произвольный запрос?
11 ноя 15, 22:12    [18403006]     Ответить | Цитировать Сообщить модератору
 Re: Защита от SQL-инъекций  [new]
если web-приложению
Guest
makar182,

примеры sql-инъекций есть даже в википедии
и объяснение что это такое
и как с этим бороться
и в каждом веб/не веб фреймворке или языке есть хелп и рекомендации в которых обязательно эти инъекции упоминаются и методы борьбы с ними, применимые конкретно к этому фреймворку или языку программирования
11 ноя 15, 22:15    [18403014]     Ответить | Цитировать Сообщить модератору
 Re: Защита от SQL-инъекций  [new]
Glory
Member

Откуда:
Сообщений: 104760
makar182
Мне не понятен сам механизм - если у пользователя права только на запуск процедуры, то как он может запустить произвольный запрос?

Еще раз. Он не будет ничего выполнять.
Он просто передаст вам произвольную текстовую строку, которую вы включите в текст своего запроса и выполните полученный текст.
11 ноя 15, 22:23    [18403057]     Ответить | Цитировать Сообщить модератору
 Re: Защита от SQL-инъекций  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31435
makar182
Мне не понятен сам механизм - если у пользователя права только на запуск процедуры, то как он может запустить произвольный запрос?
Да просто в процедуре конструируется запрос как строка, и выполняется, а параметр этого запроса передаётся тоже как строка, и конкатенируется с этим запросом.
makar182
Можете подсказать как защититься от инъекций хоть на каком-то уровне с учетом того, что текст передавать все же можно? И кстати - запрет ввода текста должен быть на стороне Web или, например, данные должны забиваться в переменную типа INT, а значит текст даст ошибку? Web написан на C# (может там что-то можно сделать?)
Да в общем всё просто - нужно использовать только параметризованные запросы.

Т.е.:

1. В процедурах - не использовать динамический SQL, а если использовать, то не делать строку выполнения конкатенированием с пользовательским вводом. Вместо этого использовать только вызов sp_executesql с параметрами.

2. В запросах от веб-сервера не делать строку выполнения конкатенированием с пользовательским вводом. Вместо этого использовать объекты вроде "команда с параметрами" (например, в C# это будет SqlCommand и SqlPaarmeter). Это относится в том числе и к вызовам хранимых процедур.

Как видите, правила всего два, они очень просты.

В принципе, системы на хранимых процедурах считаются более защищёнными, но только потому, что в этом случае выполнить и проконтролировать эти правила намного, намного проще.
11 ноя 15, 22:25    [18403067]     Ответить | Цитировать Сообщить модератору
 Re: Защита от SQL-инъекций  [new]
Гавриленко Сергей Алексеевич
Member

Откуда: Moscow
Сообщений: 37067
makar182
Glory
пропущено...

Причем здесь права на процедуру ?
SQL injection получается только тогда, когда введенные пользователем данные используются для _формирования текста запроса_.


Мне не понятен сам механизм - если у пользователя права только на запуск процедуры, то как он может запустить произвольный запрос?
Можно просто запустить
select * from sysobjects, sysobjects, ... , sysobjects
и вашему серверу сразу станет не очень хорошо.
11 ноя 15, 23:57    [18403436]     Ответить | Цитировать Сообщить модератору
 Re: Защита от SQL-инъекций  [new]
Владислав Колосов
Member

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

Откуда: Moscow
Сообщений: 31435
Владислав Колосов
Наилучший вариант, как мне кажется, это использование веб-сервисов. В этом случае исполняемый код будет полностью изолирован от клиентского кода.
Да-да. Пользователь вводит строку, строка передаётся веб-сервису, веб-сервис её выполняет от имени сисадмина на сервере :-)

От названия технологий и количества уровней защита не зависит. Это разводить тупых менеджеров не-технарей хорошо.
12 ноя 15, 18:38    [18408258]     Ответить | Цитировать Сообщить модератору
 Re: Защита от SQL-инъекций  [new]
Serg_77m
Member

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

Иногда параметры неудобны. Примеры:
  • В зависимости от пользовательского ввода добавлять или не добавлять условие во where
  • Сформировать условие вида: "where KEY in (123,124,134,342,333,...)" (список переменный)
  • 12 ноя 15, 19:38    [18408603]     Ответить | Цитировать Сообщить модератору
     Re: Защита от SQL-инъекций  [new]
    Glory
    Member

    Откуда:
    Сообщений: 104760
    Serg_77m
    А если так?
    string sql = "select SOME,THING from SOMETABLE where KEY=N'" + UserInput.Text.Replace("'","''") + "'";
    

    Это и есть SQL injection. Потому что это и есть строка выполнения конкатенированная с пользовательским вводом

    Serg_77m
    Иногда параметры неудобны. Примеры:
  • В зависимости от пользовательского ввода добавлять или не добавлять условие во where
  • Сформировать условие вида: "where KEY in (123,124,134,342,333,...)" (список переменный)

  • - что бы тогда пользователю не писать целиком весь запрос ? Раз уж ему разрешили задавать любые условия
    12 ноя 15, 20:05    [18408751]     Ответить | Цитировать Сообщить модератору
     Re: Защита от SQL-инъекций  [new]
    Serg_77m
    Member

    Откуда: Донецк
    Сообщений: 237
    Glory
    Serg_77m
    А если так?
    string sql = "select SOME,THING from SOMETABLE where KEY=N'" + UserInput.Text.Replace("'","''") + "'";
    

    Это и есть SQL injection. Потому что это и есть строка выполнения конкатенированная с пользовательским вводом
    Хорошо, а как этим можно воспользоваться? Что пользователь должен ввести в UserInput, чтобы после отправки на выполнение текста из переменной sql, на сервере выполнилось что-нибудь ещё, кроме select'а из SOMETABLE?
    12 ноя 15, 20:15    [18408825]     Ответить | Цитировать Сообщить модератору
     Re: Защита от SQL-инъекций  [new]
    Glory
    Member

    Откуда:
    Сообщений: 104760
    Serg_77m
    Хорошо, а как этим можно воспользоваться? Что пользователь должен ввести в UserInput, чтобы после отправки на выполнение текста из переменной sql, на сервере выполнилось что-нибудь ещё, кроме select'а из SOMETABLE?

    Да все, что угодно
    12 ноя 15, 20:22    [18408871]     Ответить | Цитировать Сообщить модератору
     Re: Защита от SQL-инъекций  [new]
    makar182
    Member

    Откуда:
    Сообщений: 36
    alexeyvg
    makar182
    Мне не понятен сам механизм - если у пользователя права только на запуск процедуры, то как он может запустить произвольный запрос?
    Да просто в процедуре конструируется запрос как строка, и выполняется, а параметр этого запроса передаётся тоже как строка, и конкатенируется с этим запросом.
    makar182
    Можете подсказать как защититься от инъекций хоть на каком-то уровне с учетом того, что текст передавать все же можно? И кстати - запрет ввода текста должен быть на стороне Web или, например, данные должны забиваться в переменную типа INT, а значит текст даст ошибку? Web написан на C# (может там что-то можно сделать?)
    Да в общем всё просто - нужно использовать только параметризованные запросы.

    Т.е.:

    1. В процедурах - не использовать динамический SQL, а если использовать, то не делать строку выполнения конкатенированием с пользовательским вводом. Вместо этого использовать только вызов sp_executesql с параметрами.

    2. В запросах от веб-сервера не делать строку выполнения конкатенированием с пользовательским вводом. Вместо этого использовать объекты вроде "команда с параметрами" (например, в C# это будет SqlCommand и SqlPaarmeter). Это относится в том числе и к вызовам хранимых процедур.

    Как видите, правила всего два, они очень просты.

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


    Про динамический запрос понял.

    По второму пункту - т.е. вариант типа EXEC PROC_CREATE_USER @NAME = 'Иван', @SURNAME = 'Иванов', где внутри процедуры происходит просто инсерт полученных переменных, считается достаточно безопасным?
    12 ноя 15, 21:39    [18409218]     Ответить | Цитировать Сообщить модератору
     Re: Защита от SQL-инъекций  [new]
    makar182
    Member

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

    Т.е.:

    1. В процедурах - не использовать динамический SQL, а если использовать, то не делать строку выполнения конкатенированием с пользовательским вводом. Вместо этого использовать только вызов sp_executesql с параметрами.

    2. В запросах от веб-сервера не делать строку выполнения конкатенированием с пользовательским вводом. Вместо этого использовать объекты вроде "команда с параметрами" (например, в C# это будет SqlCommand и SqlPaarmeter). Это относится в том числе и к вызовам хранимых процедур.

    Как видите, правила всего два, они очень просты.

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


    Про динамический запрос понял.

    По второму пункту - т.е. вариант типа EXEC PROC_CREATE_USER @NAME = 'Иван', @SURNAME = 'Иванов', где внутри процедуры происходит просто инсерт полученных переменных, считается достаточно безопасным?


    Дополню вопрос.

    По второму пункту - т.е. вариант типа EXEC PROC_CREATE_USER @NAME = 'Иван', @SURNAME = 'Иванов', где внутри процедуры происходит просто инсерт полученных переменных, считается достаточно безопасным?


    Отработает ли в таком случае инъекция, если её передать в одну из переменных или в обе переменные сразу?
    12 ноя 15, 21:43    [18409225]     Ответить | Цитировать Сообщить модератору
     Re: Защита от SQL-инъекций  [new]
    Glory
    Member

    Откуда:
    Сообщений: 104760
    makar182
    Отработает ли в таком случае инъекция, если её передать в одну из переменных или в обе переменные сразу?

    Вам все таки стоит найти и прочитать определение инъекции прежде, чем задавать такие вопросы
    12 ноя 15, 22:06    [18409313]     Ответить | Цитировать Сообщить модератору
     Re: Защита от SQL-инъекций  [new]
    alexeyvg
    Member

    Откуда: Moscow
    Сообщений: 31435
    makar182
    Дополню вопрос.
    По второму пункту - т.е. вариант типа EXEC PROC_CREATE_USER @NAME = 'Иван', @SURNAME = 'Иванов', где внутри процедуры происходит просто инсерт полученных переменных, считается достаточно безопасным?
    Отработает ли в таком случае инъекция, если её передать в одну из переменных или в обе переменные сразу?
    Нет, если в процедуре нет динамики, то это безопасно.

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

    Serg_77m
    Хорошо, а как этим можно воспользоваться? Что пользователь должен ввести в UserInput, чтобы после отправки на выполнение текста из переменной sql, на сервере выполнилось что-нибудь ещё, кроме select'а из SOMETABLE?
    Конечно, если правильно обрабатывать строки при конструировании запросов, то в общем можно защититься от SQL-injection

    Однако, в этом случае защита будет размазана по тысячам (миллионам?) строк проекта.
    Вот это и называется "уязвимостями", когда пишут всё правильно и безопасно, но вот один из сотен программистов несколько лет назад, после ора и брызнганья слюной начальника, поздно вечером в субботу добавляя поле в таблицу репорта, забыл обработать конкатенируемый новый параметр отчёта. А потом умный дядя лет через 5 нашёл эту дыру, и успешно использовал.

    Вот поэтому правильно - не размазывать код обращения к базе, а проработать какие то классы доступа, и пользоваться ими, а не стандартными.

    Далее, в этих классах, конечно, можно использовать правильную обработку строк и конкатенации.

    Однако, это ведь будет повторением уже имеющейся функциональности? Зачем вот этим заниматься?

    Хочу ещё заметить, что при не-использовании параметров придётся решать ещё немало задач, по приведению типов; например, правильно конвертить даты и байтовые массивы.
    Т.е. эти самодельные параметры будут не такие простые. Реально это получается библиотека на тысячи строк кода.

    Ещё передача параметров и RPC выгоднее, потому что серверу не нужно заниматься лишней компиляцией.

    В общем, да, защититься можно и без параметров, но я не вижу необходимости не пользоваться параметрами, не вижу каких то преимуществ в этом.
    13 ноя 15, 00:46    [18409772]     Ответить | Цитировать Сообщить модератору
     Re: Защита от SQL-инъекций  [new]
    alexeyvg
    Member

    Откуда: Moscow
    Сообщений: 31435
    Serg_77m
    Иногда параметры неудобны. Примеры:
  • В зависимости от пользовательского ввода добавлять или не добавлять условие во where
  • Сформировать условие вида: "where KEY in (123,124,134,342,333,...)" (список переменный)
  • Иногда да.
    Хотя в этих примерах можно обойтись и без конкатенации строк, особенно если есть хорошие наработки по доступу.

    Я, собственно, в том посте предложил один из вариантов, хороший не только для безопасности, но и для многого другого.

    Но понятно, могут быть случаи, когда можно работать и прямыми непараметризованными запросами.
    13 ноя 15, 00:50    [18409779]     Ответить | Цитировать Сообщить модератору
     Re: Защита от SQL-инъекций  [new]
    Mind
    Member

    Откуда: Лучший город на Земле
    Сообщений: 2322
    Serg_77m
    Иногда параметры неудобны. Примеры:
  • В зависимости от пользовательского ввода добавлять или не добавлять условие во where
  • А плохому танцору, как известно всегда что-то мешает

    if (userInput) 
    { 
      sql += "WHERE/AND KEY=@UserInput";
      comm.Parameters.Add("@UserInput", SqlDbType.VarChar, 128);
    }
    
    13 ноя 15, 03:09    [18409947]     Ответить | Цитировать Сообщить модератору
     Re: Защита от SQL-инъекций  [new]
    Владислав Колосов
    Member

    Откуда:
    Сообщений: 7868
    alexeyvg
    Владислав Колосов
    Наилучший вариант, как мне кажется, это использование веб-сервисов. В этом случае исполняемый код будет полностью изолирован от клиентского кода.
    Да-да. Пользователь вводит строку, строка передаётся веб-сервису, веб-сервис её выполняет от имени сисадмина на сервере :-)

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


    С какой стати, интересно, веб-метод должен выполнять прямые запросы, переданные в параметрах? Это уж очень бурное воображение должно быть, чтобы реализовать такой метод :)
    13 ноя 15, 11:47    [18411155]     Ответить | Цитировать Сообщить модератору
     Re: Защита от SQL-инъекций  [new]
    Glory
    Member

    Откуда:
    Сообщений: 104760
    Владислав Колосов
    С какой стати, интересно, веб-метод должен выполнять прямые запросы, переданные в параметрах?

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