Aby rozpocząć, dobrze zdaję sobie sprawę, że sparametryzowane zapytania są najlepszą opcją, ale pytam, co sprawia, że ​​strategia, którą przedstawiam poniżej, jest podatna na zagrożenia. Ludzie twierdzą, że poniższe rozwiązanie nie działa, więc szukam przykładu, dlaczego nie.

Jeśli dynamiczny SQL jest wbudowany w kod wykorzystujący następujące ucieczki przed wysłaniem do SQL Server, jaki rodzaj zastrzyku może to pokonać?

string userInput= "N'" + userInput.Replace("'", "''") + "'"

Odpowiedzi na podobne pytanie udzielonotutaj, ale nie wierzę, że któraś z odpowiedzi ma tu zastosowanie.

Uciekanie pojedynczego cytatu za pomocą „” nie jest możliwe w SQL Server.

wierzęSQL Smuggling z Unicode (opisanetutaj) byłoby udaremnione przez fakt, że tworzony ciąg jest oznaczony jako Unicode przez N poprzedzający pojedynczy cytat. O ile wiem, nie ma innych zestawów znaków, które SQL Server automatycznie przetłumaczyłby na pojedynczy cytat. Bez jednoznacznego cytatu nie wierzę, że zastrzyk jest możliwy.

Nie wierzęObcinanie ciągu jest również opłacalnym wektorem. SQL Server z pewnością nie będzie obcinał, ponieważ maksymalny rozmiar dlanvarchar to 2 GBwedług microsoft. Ciąg 2 GB jest niewykonalny w większości sytuacji i niemożliwy w moim.

Wtrysk drugiego rzędu może być możliwe, ale czy to możliwe, jeśli:

Wszystkie dane przechodzące do bazy danych są oczyszczane przy użyciu powyższej metodyWartości z bazy danych nigdy nie są dołączane do dynamicznego SQL (dlaczego i tak byś to zrobił, kiedy możesz po prostu odwołać się do wartości tabeli w statycznej części dowolnego dynamicznego ciągu SQL?).

Nie sugeruję, że jest to lepsze niż lub alternatywne dla używania sparametryzowanych zapytań, ale chcę wiedzieć, jak to, co opisałem, jest podatne na ataki. Jakieś pomysły?