Czy mogę chronić się przed SQL Injection poprzez unikanie pojedynczych cudzysłowów i otaczających danych wejściowych użytkownika za pomocą pojedynczych cudzysłowów?

Dobra, ta odpowiedź będzie odnosić się do aktualizacji pytania:

"Jeśli ktoś zna jakiś konkretny sposób na zamontowanie ataku SQL injection przeciwko tej metodzie sanityzacji, chciałbym go zobaczyć."

Teraz, poza ucieczką odwrotnego ukośnika MySQL - i biorąc pod uwagę, że mówimy o MSSQL, są w rzeczywistości 3 możliwe sposoby wstrzykiwania kodu SQL

Ssanitized Input = "'" & Replace(sInput, "'", """) & "'"

Weź pod uwagę, że nie wszystkie będą ważne przez cały czas i są bardzo zależne od Twojego rzeczywistego kodu wokół niego:

1. second-order SQL Injection - jeśli zapytanie SQL zostanie przebudowane na podstawie danych pobranych z bazy danych Po ucieczce , dane są łączone bez sklejenia i mogą być pośrednio wstrzykiwane SQL. Zobacz
2. String truncation - (nieco bardziej skomplikowane) - scenariusz jest to, że masz dwa pola, powiedzmy nazwę użytkownika i hasło, a SQL łączy oba. I oba pola (lub tylko pierwsze) mają twardy limit długości. Na przykład nazwa użytkownika jest ograniczona do 20 znaków. Powiedz, że masz ten kod:

username = left(Replace(sInput, "'", "''"), 20)

Następnie otrzymujesz nazwę użytkownika, unikalny, a następnie przycięty do 20 znaków. Problem tutaj - wpiszę swój cytat w 20 znak (np. po 19 a), a twój cytat uciekający zostanie przycięty (w 21 znak). Następnie SQL

sSQL = "select * from USERS where username = '" + username + "'  and password = '" + password + "'"

W połączeniu z powyższa Nieprawidłowa nazwa użytkownika spowoduje, że hasło będzie już poza cudzysłowami i będzie zawierać bezpośrednio ładunek.
3. Przemyt Unicode - w pewnych sytuacjach można przekazać znak wysokiego poziomu unicode, który wygląda jak cytat, ale nie jest - dopóki nie dotrze do bazy danych, gdzie nagle jest . Ponieważ nie jest to cytat, gdy go walidujesz, przejdzie to łatwo... Zobacz moją poprzednią odpowiedź po więcej szczegóły i link do oryginalnych badań.

W skrócie: nigdy nie pytaj o siebie. Na pewno coś ci się stanie. Zamiast tego użyj parametryzowanych zapytań lub jeśli z jakiegoś powodu nie możesz tego zrobić, Użyj istniejącej biblioteki, która zrobi to za Ciebie. Nie ma powodu, żeby robić to samemu.

Zdaję sobie sprawę, że to było dawno po zadaniu pytania, ale ..

Jednym ze sposobów na rozpoczęcie ataku na procedurę 'Cytuj argument' jest obcinanie łańcuchów. Zgodnie z MSDN, w SQL Server 2000 SP4 (i SQL Server 2005 SP1) zbyt długi ciąg będzie po cichu ścięty.

Gdy zacytujesz ciąg znaków, ciąg zwiększa się w rozmiarze. Każdy apostrof jest powtarzany. To może być następnie wykorzystane do wypychania części SQL poza bufor. Dzięki czemu można skutecznie przycinać części klauzuli where.

Byłoby to prawdopodobnie najbardziej przydatne w scenariuszu strony "administrator użytkownika", w którym można nadużywać instrukcji "aktualizacja", aby nie wykonywać wszystkich kontroli, które miało to zrobić.

Więc jeśli zdecydujesz się cytować wszystkie argumenty, upewnij się, że wiesz, co dzieje się z rozmiarami łańcuchów i dopilnuj, aby nie doszło do okrojenia.

Polecam korzystanie z parametrów. Zawsze. Chciałbym to wyegzekwować w bazie danych. A jako efekt uboczny, jesteś bardziej prawdopodobnie uzyskamy lepsze trafienia pamięci podręcznej, ponieważ więcej poleceń wygląda tak samo. (To z pewnością prawda na Oracle 8)

Input sanitiation to nie jest coś, co chcesz pół-ass. Użyj całego tyłka. Używaj wyrażeń regularnych na polach tekstowych. Spróbuj ustawić cyfry na odpowiedni typ numeryczny i Zgłoś błąd walidacji, jeśli nie zadziała. Bardzo łatwo jest wyszukiwać wzorce ataków w danych wejściowych, takie jak'--. Załóżmy, że wszystkie dane wejściowe od użytkownika są wrogie.

Używałem tej techniki, gdy miałem do czynienia z funkcjonalnością 'advanced search', gdzie zbudowanie zapytania od zera było jedyną realną odpowiedzią. (Przykład: pozwala użytkownikowi wyszukiwać produkty w oparciu o nieograniczony zestaw ograniczeń atrybutów produktów, wyświetlając kolumny i ich dozwolone wartości jako kontrolki GUI, aby zmniejszyć próg uczenia się dla użytkowników.)

Sam w sobie jest bezpieczny AFAIK. Jak zauważył inny answer, być może będziesz musiał również poradzić sobie z ucieczką backspace (aczkolwiek nie przy przekazywaniu zapytania do SQL Server za pomocą ADO lub ADO.NET, przynajmniej-nie ręczę za wszystkie bazy danych czy technologie).

Problem polega na tym, że naprawdę musisz mieć pewność, które ciągi zawierają dane wejściowe użytkownika (zawsze potencjalnie złośliwe), a które są poprawnymi zapytaniami SQL. Jedną z pułapek jest użycie wartości z bazy danych - czy te wartości zostały pierwotnie dostarczone przez użytkownika? Jeśli tak, to i oni muszą uciec. Moją odpowiedzią jest próba odkażenia jak najdłużej (ale nie później!), podczas konstruowania zapytania SQL.

Jednak w większości przypadków Wiązanie parametrów jest drogą -- jest to po prostu prostsze.

To i tak zły pomysł, jak ci się wydaje.

A może coś w rodzaju ucieczki cytatu w łańcuchu, jak to: \ '

Twój zastąpienie spowoduje: \ "

Jeśli ukośnik odwrotny ucieka przed pierwszym cudzysłowem, to drugi cudzysłów kończy łańcuch.

Prosta odpowiedź: to będzie działać czasami, ale nie cały czas. Chcesz używać walidacji białej listy na wszystkim, ale zdaję sobie sprawę, że nie zawsze jest to możliwe, więc jesteś zmuszony wybrać najlepszą czarną listę. Podobnie, chcesz używać sparametryzowanych przechowywanych procków w wszystkim, ale po raz kolejny, nie zawsze jest to możliwe, więc jesteś zmuszony używać sp_execute z parametrami.

Istnieją sposoby obejścia każdej użytecznej czarnej listy, którą możesz wymyślić (i niektóre whitelistów też).

Przyzwoity writeup jest tutaj: http://www.owasp.org/index.php/Top_10_2007-A2

Jeśli chcesz to zrobić jako szybkie rozwiązanie, aby dać ci czas na stworzenie prawdziwego, zrób to. Ale nie myśl, że jesteś bezpieczna.

Są dwa sposoby, bez wyjątków, aby być bezpiecznym od SQL-Injection; przygotowane instrukcje lub prametryzowane procedury przechowywane.

Jeśli masz sparametryzowane zapytania, powinieneś używać ich przez cały czas. Wystarczy jedno zapytanie, aby prześlizgnąć się przez Sieć i twój DB jest zagrożony.

Tak, to powinno działać aż ktoś uruchomi Ustaw QUOTED_IDENTIFIER OFF i użyje podwójnego cudzysłowu na Tobie.

Edit: nie jest to takie proste, jak nie zezwalanie złośliwemu użytkownikowi na wyłączenie podanych identyfikatorów:

Natywny klient SQL Server ODBC driver i natywny klient SQL Server OLE DB Provider dla SQL Server automatycznie ustawiają QUOTED_IDENTIFIER na ON podczas łączenia. Można to skonfigurować w źródłach danych ODBC, w atrybutach połączeń ODBC lub OLE DB właściwości połączenia. domyślna wartość SET QUOTED_IDENTIFIER jest wyłączona dla połączeń z aplikacji DB-Library.

Podczas tworzenia procedury składowanej, Ustawienia SET QUOTED_IDENTIFIER I SET ANSI_NULLS są przechwytywane i używane do kolejnych wywołań tej procedury składowanej .

SET QUOTED_IDENTIFIER również odpowiada ustawieniu QUOTED_IDENTIFIER bazy danych ALTER.

SET QUOTED_IDENTIFIER to set at parse time . Ustawienie w czasie parse oznacza, że jeśli instrukcja SET jest obecna w procedurze wsadowej lub składowanej, staje się skuteczna, niezależnie od tego, czy wykonanie kodu rzeczywiście osiągnie ten punkt; a instrukcja SET staje się skuteczna przed wykonaniem jakichkolwiek instrukcji.

Jest wiele sposobów, w jaki QUOTED_IDENTIFIER może być wyłączony bez Twojej wiedzy. Co prawda-to nie jest exploit broni dymiącej, którego szukasz, ale to dość duża powierzchnia ataku. Oczywiście, jeśli również uciekł podwójne cytaty - wtedy wracamy do punktu wyjścia. ;)

Twoja obrona by się nie powiodła, gdyby:

• zapytanie oczekuje liczby, a nie ciągu
• istniały inne sposoby reprezentowania pojedynczego cudzysłowu, w tym:
  • sekwencja ucieczki, taka jak \039
  • znak unicode

(w tym drugim przypadku musiałoby to być coś, co zostało rozszerzone dopiero po wykonaniu wymiany)

Patrick, czy dodajesz pojedyncze cudzysłowy wokół wszystkich wejść, nawet liczbowych? Jeśli masz wejście numeryczne, ale nie umieszczasz wokół niego pojedynczych cudzysłowów, to masz ekspozycję.

Jaki brzydki kod to wszystko by było! Następnie clunky StringBuilder dla instrukcji SQL. Przygotowana metoda statement skutkuje znacznie czystszym kodem, a zalety SQL Injection są naprawdę miłym dodatkiem.

Również po co odkrywać koło?

Zamiast zmieniać pojedynczy cytat na (co wygląda jak) dwa pojedyncze cytaty, dlaczego po prostu nie zmienić go na apostrof, cytat, lub usunąć go całkowicie?

Tak czy inaczej, to trochę kludge... zwłaszcza, gdy legalnie masz rzeczy (takie jak nazwy), które mogą używać pojedynczych cudzysłowów...

Uwaga: Twoja metoda zakłada również, że wszyscy pracujący nad twoją aplikacją zawsze pamiętają o wyczyszczeniu danych wejściowych, zanim trafią do bazy danych, co prawdopodobnie nie jest realistyczne przez większość czasu.

To może zadziałać, ale wydaje mi się trochę niepewne. Zalecałbym sprawdzenie, czy każdy łańcuch jest poprawny, testując go zamiast wyrażenia regularnego.

Chociaż możesz znaleźć rozwiązanie, które działa dla ciągów znaków, dla predykatów numerycznych musisz również upewnić się, że są one przekazywane tylko w liczbach (proste sprawdzenie jest czy można je parsować jako int/double/decimal?).

To dużo dodatkowej pracy.

Tak, możesz, jeśli...

Po przestudiowaniu tematu, myślę, że wprowadzanie danych zgodnie z Twoją sugestią jest bezpieczne, ale tylko zgodnie z tymi zasadami:

1. Nigdy nie pozwalasz, aby wartości tekstowe pochodzące od użytkowników stały się czymś innym niż literały łańcuchowe (tzn. unikaj podawania opcji konfiguracji: "wprowadź dodatkowe nazwy kolumn/wyrażenia SQL tutaj:"). Typy wartości inne niż ciągi znaków (liczby, daty, ...): przekonwertować je na ich natywne typy danych i dostarczyć rutynę dla SQL z każdy typ danych.

   • wyrażenia SQL są problematyczne do walidacji

2. Albo używasz nvarchar/nchar kolumny (i przedrostek literał ciągu z N) lub wartości graniczne przechodzące do varchar/char kolumny tylko do znaków ASCII (np. wyjątek throw podczas tworzenia instrukcji SQL)

   W ten sposób unikniesz automatycznej konwersji apostrofów z CHAR(700) do CHAR (39) (i być może innych podobnych hacków Unicode)

3. Ty zawsze sprawdzaj długość wartości, aby pasowała do rzeczywistej długości kolumny (wyjątek throw jeśli jest dłuższy)

   W SQL serverze istnieje możliwość obejścia błędu SQL rzuconego przy obcinaniu (co prowadzi do cichego obcinania).]}

4. Zapewniasz, że SET QUOTED_IDENTIFIER jest zawsze ON

   • uwaga, jest on stosowany w czasie parse-time, tj. nawet w niedostępnych sekcjach kodu

Przestrzegając tych 4 punktów, powinieneś być bezpieczny. Jeśli naruszając którekolwiek z nich, otwiera się sposób na SQL injection.