Является ли этот параметр LINQ уязвимым для внедрения SQL?

Question

Является ли эта инструкция LINQ уязвимой для SQL-инъекций?

var result = from b in context.tests
    where b.id == inputTextBox.Text
    select b;

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

Также будет ли это рассматриваться как linq для sql или linq для сущностей?

Answer 1

Краткий ответ: LINQ не уязвим для внедрения SQL.

Длинный ответ:

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

Q.Как LINQ to SQL защищен от атак с использованием SQL-инъекций?

A.Внедрение SQL было значительным риском для традиционных запросов SQL, сформированных путем объединения пользовательских данных.LINQ to SQL позволяет избежать такого внедрения, используя SqlParameter в запросах.Пользовательский ввод превращается в значения параметров.Этот подход предотвращает использование вредоносных команд из пользовательского ввода.

Внутренне это означает, что когда LINQ to SQL запрашивает базу данных, вместо использования простых значений, они передают их как параметры SQL , что означает, что они не могут никогда рассматриваться базой данных как исполняемый код.Это также верно для большинства (если не всех) картографов ORM.

Сравните эти два подхода (полностью псевдокод):

string name = "' ; DROP DATABASE master  --"
run ("SELECT * FROM Authors WHERE Name = '" + name + "'") // oops!

// now we'd better use parameters
SqlParameter name = new SqlParameter ("@name", "' ; DROP DATABASE master  --")
run ("SELECT * FROM Authors WHERE Name = @name", name) // this is pretty safe

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

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

Answer 2

Поставщик LINQ to Entities использует параметризованные запросы и полностью защищен от внедрения SQL.

Answer 3

LINQ использует параметризованные запросы, поэтому он обычно не подвержен внедрению SQL.Ваш пример, например, не уязвим.

Answer 4

Нет. LINQ to Entities и LINQ to SQL обрабатывают генерацию SQL-запросов, чтобы избежать SQL-инъекций. Вы можете использовать LINQPad, если вам интересно посмотреть, какой оператор SQL генерируется при выполнении этого запроса с различными входными данными.

Является ли это LINQ to SQL или LINQ to Entities, зависит от того, что является вашим context объектом, и не может быть определено из этого фрагмента кода.

Единственное время, когда вам нужно беспокоиться о внедрении SQL в LINQ, - это если вы используете метод ExecuteQuery для запуска пользовательского запроса SQL ( см. Здесь ). Но в этот момент вы отошли от интегрированного в язык запроса и вернулись в мир создания собственных строк.

Answer 5

LINQ To SQL генерирует параметризованный запрос, поэтому он защищает от атак внедрения SQL

Answer 6

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