Czy możliwe jest zastrzyki przez dynamiczny LINQ?

Question

Korzystanie z biblioteki Dynamic LINQ (link) jest podatne na wstrzyknięcie? i (jeśli tak), w jaki sposób można temu zabezpieczyć?

Niektóre tła z Security Considerations (Entity Framework):

LINQ podmiotach ataków wtrysku:

Chociaż kompozycja zapytanie jest możliwe LINQ jednostkach, to jest wykonywane przez model obiektu API. W przeciwieństwie do zapytań SQL Entity, zapytania LINQ do Entities nie są tworzone przy użyciu manipulacji łańcuchami znaków lub konkatenacji i nie są podatne na tradycyjne ataki przy użyciu wstrzykiwań SQL .

Skoro dynamiczny SQL składa się za pomocą ciągów znaków, oznacza to, że może on być podatny na wektory wstrzykiwania? Czy LINQ do SQL automatycznie zajmie się parametryzowaniem twoich wartości w oparciu o podstawowy typ danych w bibliotece Dynamic LINQ?

Czy jest to całkowicie bezpieczne, ponieważ dynamiczne kwerendy będą wykonywane w pamięci, a nie w stosunku do SQL (negując tym samym wszelkie korzyści z indeksów SQL)?

Przez cały czas pracowałem nad zrozumieniem kodu DynamicLibrary.cs, ale jestem pewien, że z łatwością mógłbym coś przeoczyć.

Ponieważ to pytanie dotyczy samej biblioteki Dynamic LINQ, to pytanie można uznać za odnoszące się zarówno do linq-to-sql i linq-to-entities (pomimo powyższego odniesienia do Entity Framework).

Answer 1

Cóż, nie zgadzam się, że wstrzyknięcie nie jest możliwe w Dynamic Linq.

Co opisane w answer przez Ɖiamond ǤeezeƦ jest poprawna, ale appies do standardowego Linq tak skonstruowana w danym języku - C# lub VB.Net lub poprzez wywołanie metody rozszerzenie jak .Where z funkcji lambda.

W takim razie nie można niczego wstrzyknąć, ponieważ translator .NET Linq to Sql jest oczywiście przyzwoicie napisany. W ten sposób "iniekcja SQL" nie jest możliwa, to prawda.

Jednak to, co jest możliwe w Dynamic Linq, to ​​atak "Linq injection". W wyjaśnieniu bezpieczeństwa LINQ cytowanych przez OP, jest powiedziane:

LINQ podmiotom zapytań nie składa się za pomocą sznurka lub manipulacji konkatenacji, a oni nie są podatne na tradycyjnych ataków SQL injection.

I w zasadzie to jest sedno. Jeśli zapytania są tworzone przez manipulowanie ciągami, wówczas są podatne na ataki typu "injection". Dynamiczny Linq jest w rzeczywistości złożony ze strun, dlatego jest potencjalnie podatny na atak przez zastrzyk.

Oczywiście, osoba atakująca będzie musiała zdawać sobie sprawę z tego, że używasz DynamicLinq i może atakować tylko przygotowywanie danych, aby uzyskać prawidłowe złośliwe zapytanie Dynamic Linq.

Chcę podkreślić ten fakt - ostateczna SQL składa bezpiecznie, ale czy oryginalnego dynamicznym Linq jest bezpieczny zależy od ciebie.

Moszcz aby twój dynamiczny zapytań LINQ bezpieczne jest stosowanie zastępcze dla wszystkich wejścia użytkownika. Nigdy nie łącz konkjekcję!

Wyobraźmy sobie następującą kwerendę:

dataset.Where("allowed == 1 and code == \"" + user_entered_data + "\""); 

Jeśli wejście nie jest oczyszczone i nie uciekł, atakujący może potencjalnie wejściowe:

200" or allowed == 0 and code == "200 

co spowoduje:

allowed == 1 and code == "200" or allowed == 0 and code == "200" 

Aby tego uniknąć, należy użyć symboli zastępczych:

dataset.Where("allowed == 1 and code == @0", user_entered_data); 

DynamicLinq spowoduje, że symbol zastępczy (w tym przypadku: dane wprowadzane przez użytkownika) będzie argumentem lambda (zamiast łączenia go w zapytanie) i zależy od Linq-To-Entities (lub dowolnego zaplecza), aby bezpiecznie przekonwertować SQL.

Answer 2

Z mojego doświadczenia wynikającego z badania przestrzeni nazw System.Data.Linq wynika, że ​​drzewo obiektów SQL zbudowane jest z kwerendy LINQ i jako część tego procesu jest wywoływana klasa SqlParameterizer w celu zastąpienia wszystkich wartości śródliniowych parametrami. Wartości są następnie przypisywane do parametrów. Więc ataki typu SQL injection nie powinny być możliwe.