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

Question

У меня есть отчет, и я хочу добавить текстовый параметр с одним значением (допускает пустые значения).Этот параметр будет передан в хранимую процедуру.Если этот параметр нулевой, SP игнорирует его.Однако, если параметр не равен NULL, я хочу, чтобы SP проанализировал его и использовал некоторые значения, содержащиеся в.

Пользователи будут передавать значения в форме whse=Blah&whse=Blah2&item=item1&lot=lotA&date:IsNull=True&um=&client=client2.Как вы можете догадаться, это имена параметров и значения для отчета.Моя идея состоит в том, чтобы позволить пользователю передавать некоторые значения параметров, которые они хотят в этой форме.

Однако я беспокоюсь, что кто-то может ввести какой-нибудь вредоносный текст, чтобы попытаться повредить мою базу данных.Нужно ли беспокоиться об этом, учитывая, что я использую SQL Server 2008 R2 и SyteLine 8?Или для этого уже есть защита, и мне не о чем беспокоиться?

Answer 1

Краткий ответ:

YES

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

Никакой язык, платформа или продукт RDBMS не могут предотвратить внедрение SQL. Или, если подумать, если по-другому, у вас всегда есть возможность писать небезопасный код, несмотря на существующие функции, позволяющие писать безопасный код.

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

Хранимые процедуры сами по себе не делают входные данные безопасными.

Если вы используете входные данные в динамических операторах SQL, вы должны использовать sp_executesql(), чтобы по возможности преобразовывать динамические части в параметры. Это безопасно.

Вот пример из https://docs.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/sp-executesql-transact-sql?view=sql-server-2017

EXECUTE sp_executesql   
          N'SELECT * FROM AdventureWorks2012.HumanResources.Employee   
          WHERE BusinessEntityID = @level',  
          N'@level tinyint',  
          @level = 109;  

Использовать параметры запроса. Не объединяйте переменные в строки SQL.

Например, следующее небезопасно , потому что @inBusEntityId может содержать контент, который заставляет ваш запрос делать то, чего вы не ожидаете:

EXECUTE sp_executesql   
          N'SELECT * FROM AdventureWorks2012.HumanResources.Employee   
          WHERE BusinessEntityID = ' + @inBusEntityId;

Answer 2

Как вы анализируете его и что вы делаете с результатами?

Если вы пишете код, который строит оператор SQL, вы уязвимы для внедрения SQL.

Как будто вы пишете:

set @myquery = 'select customer_name from customer where customer_id = ''' + @custid + ''''
execute (@myquery)

И предположим, что вы в конечном итоге получаете @custid из пользовательского ввода, скажем, текстовое поле в форме.

Если пользователь вводит

42

, тозапрос становится

select customer_name from customer where customer_id = '42'

Круто.Предположительно, это именно то, что вы и хотели.

Но предположим, что пользователь вводит

42'; update customer set balance_due = 0 where customer_id = '42

Теперь ваш запрос становится

select customer_name from customer where customer_id = '42'; update customer set balance_due = 0 where customer_id = '42'

, и клиент только что обнулил свой баланс из-за этого.Или он может удалить целые таблицы и т. Д.

Мораль этой истории в том, что НИКОГДА никогда не создавайте SQL-запрос динамически с использованием пользовательских данных.Это дает пользователям возможность делать с базой данных все, что они хотят.

Правильный способ сделать это:

select customer_name from customer where customer_id = @custid

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

Избегайте динамического построения операторов SQL,Когда это возможно, передавайте значения в качестве параметров.

Хорошо, иногда вам просто нужно динамически строить операторы.Наиболее распространенным случаем, о котором я могу думать, является экран критериев выбора, где пользователь может ввести значения для 10 различных критериев - дата в этом диапазоне, имя содержит это, сумма меньше этого и т. Д. - но каждое условие является необязательным,и если пользователь не вводит значение, то вы не хотите, чтобы этот тест был частью запроса.Таким образом, существуют миллионы возможных комбинаций, и вы хотите собрать запрос на лету.Это нормально, но НЕ вставляйте значения при построении запроса на лету.Вставьте параметры, а затем установите параметры.

Если значения генерируются в программе, а не из пользовательского ввода, и вы абсолютно уверены, что эти значения никогда не будут содержать текст SQL-инъекции, тогда безопасно встраивать значения вваш SQL.Единственный раз, когда я делаю это, это когда я фиксирую жестко закодированные значения.Например, если бы я мог создать код, который говорит «где тип = 1», или он мог бы сказать «где тип = 2», а цифры 1 и 2 жестко запрограммированы в программе, а не как ввод пользователя.Если сомневаетесь, создайте параметры.

Answer 3

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

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