Czy parametry naprawdę wystarczą, aby zapobiec zastrzykom Sql?

Nie, nadal istnieje ryzyko wtrysku SQL za każdym razem, gdy interpolujesz niezaliczone dane do zapytania SQL.

Parametry zapytań pomagają uniknąć tego ryzyka, oddzielając wartości dosłowne od składni SQL.

'SELECT * FROM mytable WHERE colname = ?'

W porządku, ale istnieją inne cele interpolacji danych do dynamicznego zapytania SQL, które nie mogą używać parametrów zapytania, ponieważ nie jest to wartość SQL, ale zamiast tego Nazwa tabeli, nazwa kolumny, wyrażenie lub inna składnia.

'SELECT * FROM ' + @tablename + ' WHERE colname IN (' + @comma_list + ')'
' ORDER BY ' + @colname'

Nie ma znaczenia, czy używasz procedur przechowywanych lub wykonujesz dynamiczne zapytania SQL bezpośrednio z kodu aplikacji. Ryzyko nadal istnieje.

Remedium w tych przypadkach jest zastosowanie FIEO W razie potrzeby:

• Wejście filtra: sprawdź, czy dane wyglądają jak prawdziwe liczby całkowite, nazwy tabel, nazwy kolumn itp. zanim je interpolujesz.

• Wyjście awaryjne: w tym przypadku "wyjście" oznacza umieszczenie danych w zapytaniu SQL. Używamy funkcji do przekształca zmienne używane jako literały łańcuchowe w wyrażeniu SQL, tak aby znaki cudzysłowu i inne znaki specjalne wewnątrz łańcucha były unikane. Powinniśmy również używać funkcji do przekształcania zmiennych, które będą używane jako nazwy tabel, kolumn itp. Podobnie jak w przypadku innych składni, takich jak dynamiczne pisanie całych wyrażeń SQL, jest to bardziej złożony problem.

W tym wątku wydaje się być pewne zamieszanie co do definicji "parametryzowanego zapytania".

• SQL, taki jak zapisany proc, który akceptuje parametry.
• SQL, który jest wywoływany przy użyciu kolekcji parametrów DBMS.

Biorąc pod uwagę poprzednią definicję, wiele linków pokazuje działające ataki.

Ale "normalną" definicją jest ta druga. Biorąc pod uwagę tę definicję, Nie wiem o żadnym ataku SQL injection, który zadziała. To nie znaczy, że nie ma jeden, ale jeszcze go nie widziałem.

Z komentarzy nie wyrażam się wystarczająco jasno, więc oto przykład, który miejmy nadzieję będzie jaśniejszy:

To podejście jest otwarte na SQL injection

exec dbo.MyStoredProc 'DodgyText'

To podejście nie jest otwarte na SQL injection

using (SqlCommand cmd = new SqlCommand("dbo.MyStoredProc", testConnection))
{
    cmd.CommandType = CommandType.StoredProcedure;
    SqlParameter newParam = new SqlParameter(paramName, SqlDbType.Varchar);
    newParam.Value = "DodgyText";
    .....
    cmd.Parameters.Add(newParam);
    .....
    cmd.ExecuteNonQuery();
}

Każdy parametr SQL typu string (varchar, nvarchar, itp.), który jest używany do budowy dynamicznego zapytania, jest nadal podatny na ataki

W Przeciwnym Razie konwersja typu parametru (np. na int, decimal, date, itd.) powinno wyeliminować wszelkie próby wprowadzania sql poprzez parametr

EDIT: przykład, w którym parametr @p1 ma być nazwą tabeli

create procedure dbo.uspBeAfraidBeVeryAfraid ( @p1 varchar(64) ) 
AS
    SET NOCOUNT ON
    declare @sql varchar(512)
    set @sql = 'select * from ' + @p1
    exec(@sql)
GO

Jeśli @p1 jest wybrany z rozwijanej listy, jest to potencjalny wektor ataku sql-injection;

Jeśli @ p1 jest sformułowany programowo w / out zdolność Użytkownika do interwencji, to nie jest potencjalny wektor ataku SQL-injection

Przepełnienie bufora nie jest SQL injection.

Parametryzowane zapytania gwarantują bezpieczeństwo przed SQL injection. Nie gwarantują, że w Twoim serwerze SQL nie ma możliwych exploitów w postaci błędów, ale nic tego nie zagwarantuje.

Twoje dane nie są bezpieczne, jeśli używasz dynamicznego sql w jakikolwiek sposób, ponieważ uprawnienia muszą być na poziomie tabeli. Tak, ograniczyłeś rodzaj i ilość ataku wtrysku z tego konkretnego zapytania, ale nie ograniczyłeś dostępu, który użytkownik może uzyskać, jeśli znajdzie drogę do systemu i jesteś całkowicie wolny od użytkowników wewnętrznych, którzy uzyskują dostęp do tego, czego nie powinni, aby popełnić oszustwo lub ukraść dane osobowe, aby sprzedać. Dynamiczny SQL dowolnego typu jest niebezpieczną praktyką. Jeśli uĺźywasz nie dynamicznych przechowywanych procăłw, moĹźesz ustawiaÄ ‡ uprawnienia na poziomie procesĂłw i ĺźaden uĺźytkownik nie moĹźe nic zrobiÄ ‡ poza tym co jest zdefiniowane przez procăłw (z wyjÄ ... tkiem administratăłw systemowych oczywiĹ"cie).

Możliwe jest, że przechowywany proc może być podatny na specjalne typy SQL injection poprzez overflow / truncation, zobacz: Injection Enabled by Data Truncation tutaj:

Http://msdn.microsoft.com/en-us/library/ms161953.aspx

Pamiętaj, że z parametrami możesz łatwo zapisać ciąg znaków, lub powiedzieć nazwa użytkownika, jeśli nie masz żadnych zasad,"); drop TABLE users; -- "

To samo w sobie nie spowoduje żadnej szkody, ale lepiej wiedzieć, gdzie i w jaki sposób data ta jest używana dalej w Twojej aplikacji (np. przechowywana w pliku cookie, pobierana później do innych rzeczy.

Możesz uruchomić dynamiczny sql jako przykład

DECLARE @SQL NVARCHAR(4000);
DECLARE @ParameterDefinition NVARCHAR(4000);

SELECT  @ParameterDefinition = '@date varchar(10)'

SET @SQL='Select CAST(@date AS DATETIME) Date'

EXEC sp_executeSQL @SQL,@ParameterDefinition,@date='04/15/2011'