2015-10-01 2 views
7

Я знаю, что если я использую linq для sql, все будет параметризоваться и SQL-инъекция безопасна. Но как насчет IQueryable?Является ли IQueryable SQL-инъекцией доказательством с использованием Entity Framework?

Например, я могу бросить некоторый объект в IQueryable:

var myquery = mytesttable.AsQueryable(); 
var qText = "name="+ "\""+DynamicSearchCondition+ "\""; 
myquery = myquery.Where(qText); 

Затем, когда запрос выполняется, от трассы я могу видеть, что DynamicSearchCondition Передаваемый не параметрирован.

Первоначально я думал, что это не sql-инжекционное доказательство, но затем я попробовал несколько примеров и просто не могу сломать этот. Означает ли это, что это инъекция sql бесплатно (я думаю, что это сейчас)?

Если это так, означает ли это, что все IQueryable являются безопасными для SQL-инъекций?

+0

Я не думаю, что его безопасное увидеть этот блог 'Http: //blogs.msdn.com/b/publicsector/archive/2008/08/21/prevent-sql-injection-with-the-entity-framework-and-data-services.aspx' –

+0

Исправить ссылку: http://blogs.msdn.com /b/publicsector/archive/2008/08/21/preventing-sql-injection-with-the-entity-framework-and-data-services.aspx –

+0

где вы получаете 'Where' с аргументом _string_? – Grundy

ответ

0

Нет, IQueryable сам по себе не является доказательством впрыска, поскольку это всего лишь интерфейс для построения запроса Expression. Он не определяет, как принять это Expression и превратить его во что-то исполняемое, такое как SQL. Что делает выполнить это запрос Provider (многие существуют. Linq to Objects, Linq to Entities, Linq to Excel, чтобы назвать несколько).

Таким образом, ваш пример, который, как представляется, использует DynamicLinq (на основе использования расширения .Where(string)), должен иметь аналогичные защиты параметров, как обычные Linq to Entities IQueryable. DynamicLinq не вводит никаких дополнительных проблем, связанных с впрыском SQL , потому что это просто утилита, которая работает на IQueryable. Все, что он делает, просто переведено в дерево выражений, которое снова зависит от Provider, чтобы фактически перевести на SQL. Это не означает, что синтаксис DynamicLinq сам по себе безопасен от собственного потенциала впрыска (см. here для некоторых примеров, но это не SQL-инъекция).

Microsoft имеет это сказать о LINQ для лиц и инъекции SQL:

Security Considerations (Entity Framework)

Хотя состав запроса возможно в LINQ для лиц, она выполняется через API объектной модели. В отличие от запросов Entity SQL запросы LINQ to Entities не составлены с помощью манипуляций строк или конкатенации, и они не подвержены традиционным атакам SQL-инъекций.

Это означает, что построенный вами DynamicLinq IQueryable (при использовании LINQ to Entities в качестве поставщика) должен по-прежнему параметризовать входы. Если ваш вопрос действительно «Является ли LINQ to Entities инъекционным доказательством?», Тогда лучший ответ, который я мог бы дать, «Вероятно, они приложили все разумные усилия для защиты от него».

+0

DynamicLinq ** DOES ** представляет дополнительные проблемы SQL-инъекций , потому что он составлен с использованием манипуляций строк и/или конкатенации, поэтому ** IS ** восприимчив к традиционным атакам SQL-инъекций. –

+0

Нет, это не так, и я даже включил примеры разницы между SQL-инъекцией и инъекцией DynamicLinq. Можете ли вы дать мне пример, чтобы поддержать ваше требование? – Ocelot20

+0

См. Ответ выше, или см. Дублированный ответ, который я указал. –

2

Абсолютно он уязвим для инъекционных атак.

Для вашего конкретного примера:

var myquery = mytesttable.AsQueryable(); 
var qText = "name="+ "\""+DynamicSearchCondition+ "\""; 
myquery = myquery.Where(qText); 

потерпит неудачу с этим:

var DynamicSearchCondition= "\" or \"\"=\""; 
+0

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

+0

В любом случае он восприимчив к более общей атаке на инъекции независимо от того, как вы ее просматриваете. –

+0

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

Смежные вопросы