Ответ 1
Ну, я не согласен с тем, что инъекция невозможна в Dynamic Linq.
То, что описано в , Ɖiamond ǤeezeƦ, корректно, но относится к стандартному Linq, построенному в заданный язык - С# или VB.Net или путем вызова методов расширения, таких как .Where
с лямбда-функциями.
Тогда, истинно, невозможно внедрить что-либо, поскольку переводчик .NET Linq в Sql, конечно, прилично написан. Таким образом, "SQL-инъекция" невозможна, это правда.
Однако, что возможно с Dynamic Linq - это атака Linq injection. В объяснении безопасности linq, цитируемого OP, говорится:
Запросы LINQ to Entities не составлены с помощью строковых манипуляций или конкатенаций, и они не подвержены традиционным атакам SQL-инъекций.
И в основном это суть. Если запросы состоят из манипуляций с строками, то они подвержены атакам с инъекциями. Динамический Linq фактически состоит из строк, поэтому он потенциально подвержен атаке путем инъекции.
Очевидно, злоумышленник должен знать о том, что вы используете DynamicLinq и можете атаковать только подготовку данных, чтобы он приводил к действительному вредоносному запросу Dynamic Linq.
Я хочу выделить этот факт - окончательный SQL состоит из безопасно, но независимо от того, является ли оригинальный динамический Linq безопасным вы.
Необходимость сделать ваш динамический запрос linq безопасным - использовать заполнители для всех пользовательских ввода. Никогда не связывайте свою строку!
Представьте следующий запрос:
dataset.Where("allowed == 1 and code == \"" + user_entered_data + "\"");
Если вход не дезинфицирован и не экранирован, злоумышленник может потенциально ввести:
200" or allowed == 0 and code == "200
что приведет к:
allowed == 1 and code == "200" or allowed == 0 and code == "200"
Чтобы избежать этого, вы должны использовать заполнители:
dataset.Where("allowed == 1 and code == @0", user_entered_data);
DynamicLinq сделает placeholder (в данном случае: введенные пользователем данные) аргументом лямбда (вместо того, чтобы объединить его в запрос) и будет зависеть от Linq-To-Entities (или любого другого) для безопасного преобразования в SQL.