Unikanie SQL injection bez parametrów

A potem ktoś idzie i używa " zamiast ". Parametry są, IMO, jedynym bezpiecznym sposobem.

Pozwala również uniknąć wielu problemów i18n z datami / numerami; jaka data to 01/02/03? Ile wynosi 123,456? Czy twoje serwery (app-server i db-server) zgadzają się ze sobą?

Jeśli czynnik ryzyka nie jest dla nich przekonujący, co powiesz na wydajność? RDBMS może ponownie użyć planu zapytań, jeśli używasz parametrów, co pomaga w wydajności. Nie może tego zrobić tylko sznurkiem.

Argument jest no-win. Jeśli uda ci się znaleźć lukę, twoi współpracownicy po prostu zmienią funkcję SafeDBString, aby ją uwzględnić, a następnie poproszą Cię o udowodnienie, że jest niebezpieczna.

Biorąc pod uwagę, że parametryzowane zapytania są niekwestionowaną najlepszą praktyką programowania, ciężar dowodu powinien spoczywać na nich, aby stwierdzić, dlaczego nie używają metody, która jest zarówno bezpieczniejsza, jak i skuteczniejsza.

Jeśli problem polega na przepisaniu całego kodu źródłowego, łatwy kompromis byłoby użycie sparametryzowanych zapytań w nowym kodzie i refaktorowanie starego kodu, aby użyć ich podczas pracy nad tym kodem.

Myślę, że faktycznym problemem jest duma i upór, i niewiele więcej możesz na to poradzić.

Po pierwsze, twoja próbka dla wersji "Replace" jest błędna. Musisz umieścić apostrofy wokół tekstu:

string sql = "SELECT * FROM Users WHERE Name='" + SafeDBString(name) & "'";
SqlCommand getUser = new SqlCommand(sql, connection);

To jest jeszcze jedna rzecz, którą parametry robią dla Ciebie: nie musisz się martwić o to, czy wartość musi być zamknięta w cudzysłowach. Oczywiście, możesz to wbudować w funkcję, ale potem musisz dodać wiele złożoności do funkcji: jak poznać różnicę między 'NULL' jako null i 'NULL' jako tylko łańcuch lub między liczbą a łańcuchem, który tak się składa, że zawiera wiele cyfr. To tylko kolejne źródło błędów.

Inna sprawa to wydajność: sparametryzowane plany zapytań są często buforowane lepiej niż plany konkatenowane, dlatego być może zapisanie serwera krok podczas uruchamiania zapytania.

Dodatkowo, unikanie pojedynczych cudzysłowów nie jest wystarczająco dobre. wiele produktów DB pozwala na alternatywne metody dla znaków uciekających, które atakujący mógłby wykorzystać. Na przykład w MySQL możesz także uciec od jednego cytat z ukośnikiem. I tak następująca wartość "name" wysadziłaby MySQL tylko za pomocą funkcji SafeDBString(), ponieważ po podwojeniu pojedynczego cudzysłowu pierwszy z nich jest nadal unikany przez odwrotny ukośnik, pozostawiając drugi "aktywny":

X\ ' OR 1=1;--

Również JulianR przywołuje dobry punkt poniżej: nigdy Postaraj się pracować w ochronie. Tak łatwo jest pomylić programowanie zabezpieczeń w subtelny sposób, że wydają się działać, nawet z dokładnymi testami. Potem czas mija, a rok później dowiadujesz się, że Twój system został złamany sześć miesięcy temu i nawet nie wiedziałeś o tym, aż do tego czasu.

Zawsze polegaj w jak największym stopniu na bibliotekach zabezpieczeń dostępnych dla Twojej platformy. Będą one pisane przez ludzi, którzy zarabiają na życie, o wiele lepiej Przetestowane niż to, czym można zarządzać, i serwisowane przez dostawcę, jeśli zostanie znaleziona Luka.

Tak bym powiedział:

1) Dlaczego próbujesz ponownie zaimplementować coś, co jest wbudowane? jest tam, łatwo dostępny, łatwy w użyciu i już debugowany w skali globalnej. Jeśli pojawią się w nim przyszłe błędy, zostaną one naprawione i dostępne dla wszystkich bardzo szybko, bez konieczności robienia czegokolwiek.

2) jakie procesy są stosowane, aby zagwarantować , że nigdy nie przegapisz połączenia z SafeDBString? Brak go w zaledwie 1 miejscu może otworzyć cały szereg problemów. Ile wynosi będziesz obserwował te rzeczy i zastanów się, jak bardzo zmarnowany jest ten wysiłek, gdy zaakceptowana poprawna odpowiedź jest tak łatwa do osiągnięcia.

3) na ile jesteś pewien, że Ukryłeś każdy wektor ataku, o którym Microsoft(Autor DB i biblioteki dostępu) wie w Twojej implementacji SafeDBString ...

4) Jak łatwo jest odczytać strukturę sql? Przykład używa konkatenacji+, parametry są bardzo podobne do string.Format, czyli więcej czytelne.

Istnieją również dwa sposoby ustalenia, co faktycznie zostało uruchomione - Uruchom własną funkcję LogCommand, prostą funkcję z bez obaw o bezpieczeństwo , lub nawet spójrz na ślad sql, aby dowiedzieć się, co naprawdę dzieje się w bazie danych.

Nasza funkcja LogCommand jest po prostu:

    string LogCommand(SqlCommand cmd)
    {
        StringBuilder sb = new StringBuilder();
        sb.AppendLine(cmd.CommandText);
        foreach (SqlParameter param in cmd.Parameters)
        {
            sb.Append(param.ToString());
            sb.Append(" = \"");
            sb.Append(param.Value.ToString());
            sb.AppendLine("\"");
        }
        return sb.ToString();
    }

Dobrze czy źle, daje nam informacje, których potrzebujemy, bez problemów z bezpieczeństwem.

Z parametryzowanymi zapytaniami otrzymujesz więcej niż ochronę przed SQL injection. Zyskujesz również lepszy potencjał buforowania planu realizacji. Jeśli używasz SQL server query profiler, nadal możesz zobaczyć "dokładny sql, który jest uruchamiany w bazie danych", więc tak naprawdę nie tracisz niczego pod względem debugowania instrukcji sql.

Użyłem obu podejść, aby uniknąć ataków SQL injection i zdecydowanie preferuję zapytania parametryzowane. Kiedy używałem skonkatenowanych zapytań, używałem funkcji bibliotecznej do ucieczki zmiennych (jak mysql_real_escape_string) i nie byłbym pewien, że omówiłem wszystko we własnej implementacji (jak się wydaje, ty też jesteś).

Nie jesteś w stanie łatwo zrobić dowolnego typu sprawdzania danych wejściowych użytkownika bez użycia parametrów.

Jeśli używasz klas SQLCommand i SqlParameter do wykonywania wywołań DB, nadal możesz zobaczyć wykonywane zapytanie SQL. Spójrz na właściwość CommandText SQLCommand.

Jestem zawsze trochę podejrzany o roll-your-own podejście do zapobiegania SQL injection, gdy parametryzowane zapytania są tak łatwe w użyciu. Po drugie, to, że "zawsze tak było" nie znaczy, że to właściwy sposób.

To jest bezpieczne tylko wtedy, gdy masz gwarancję, że zdasz w ciągu.

A co, jeśli w którymś momencie nie przejdziesz sznurkiem? A jeśli podasz tylko numer?

http://www.mywebsite.com/profile/?id=7;DROP DATABASE DB

Ostatecznie stałoby się:

SELECT * FROM DB WHERE Id = 7;DROP DATABASE DB

Użyłbym procedur składowanych lub funkcji do wszystkiego, więc pytanie nie powstałoby.

Gdzie muszę umieścić SQL w kodzie, używam parametrów, co jest jedyną rzeczą, która ma sens. Przypomnij dysydentom, że są hakerzy mądrzejsi od nich i z lepszą zachętą do łamania kodu, który próbuje ich przechytrzyć. Korzystanie z parametrów, to po prostu nie jest możliwe, i to nie jest tak, że jest to trudne.

Zgadzam się w kwestii bezpieczeństwa.
Innym powodem stosowania parametrów jest sprawność.

Bazy danych zawsze będą kompilować Twoje zapytanie i buforować je, a następnie ponownie używać buforowanego zapytania (co jest oczywiście szybsze dla kolejnych żądań). Jeśli używasz parametrów, to nawet jeśli używasz różnych parametrów, baza danych ponownie użyje twojego buforowanego zapytania, ponieważ pasuje ono na podstawie łańcucha SQL przed powiązaniem parametrów.

Jeśli jednak nie wiążesz parametrów to łańcuch SQL zmienia się przy każdym żądaniu (które ma inne parametry) i nigdy nie będzie pasować do tego, co jest w pamięci podręcznej.

Od bardzo krótkiego czasu musiałem zbadać problemy SQL injection, widzę, że tworzenie wartości "bezpieczne" oznacza również, że zamykasz drzwi do sytuacji, w których możesz rzeczywiście chcieć apostrofów w swoich danych - co z czyjegoś imienia, np O ' Reilly.

To pozostawia parametry i procedury składowane.

I tak, zawsze powinieneś próbować implementować kod w najlepszy sposób, jaki znasz teraz - nie tylko tak, jak zawsze był robiony.

Oto kilka artykułów, które mogą okazać się pomocne w przekonaniu współpracowników.

Http://www.sommarskog.se/dynamic_sql.html

Http://unixwiz.net/techtips/sql-injection.html

Osobiście wolę nigdy nie pozwalać, aby jakikolwiek dynamiczny kod dotykał mojej bazy danych, wymagając, aby każdy kontakt był przez sps (a nie ten, który używa dynamicznego SQl). Oznacza to, że nic z tego, co dałem użytkownikom uprawnienia do zrobienia, można zrobić i że użytkownicy wewnętrzni (z wyjątkiem bardzo niewielu z dostępem do produkcji dla celów administracyjnych) nie może bezpośrednio uzyskać dostępu do moich tabel i tworzyć spustoszenia, kraść dane lub popełniać oszustwa. Jeśli prowadzisz aplikację finansową, jest to najbezpieczniejszy sposób.

Można go złamać, jednak środki zależą od dokładnych wersji / łatek itp.

Już wspomniano o błędzie przepełnienia/obcinania, który można wykorzystać.

Innym sposobem w przyszłości będzie znalezienie błędów podobnych do innych baz danych - na przykład stos MySQL / PHP cierpiał na problem ucieczki, ponieważ niektóre sekwencje UTF8 mogą być używane do manipulowania funkcją replace - funkcja replace zostałaby oszukana w wprowadzając zastrzyk postaci.

Pod koniec dnia, mechanizm bezpieczeństwa zastępczego opiera się na oczekiwanej , ale nie zamierzonej funkcjonalności. Ponieważ funkcjonalność nie była zamierzonym celem kodu, istnieje duże prawdopodobieństwo, że niektóre odkryte dziwactwa zepsują oczekiwaną funkcjonalność.

Jeśli masz dużo starszego kodu, metoda replace może być używana jako stopgap, aby uniknąć długotrwałego przepisywania i testowania. Jeśli piszesz nowy kod, nie ma usprawiedliwienia.

Z podanych powodów parametry są bardzo dobrym pomysłem. Ale nie lubimy ich używać, ponieważ tworzenie param i przypisywanie jej nazwy do zmiennej do późniejszego wykorzystania w zapytaniu jest potrójnym błędem.

Następująca Klasa zawija stringbuilder, który będzie powszechnie używany do budowania zapytań SQL. Pozwala Ci pisać sparamaterializowane zapytania bez konieczności tworzenia parametru , dzięki czemu możesz skoncentrować się na SQL. Twój kod będzie wyglądał jak to...

var bldr = new SqlBuilder( myCommand );
bldr.Append("SELECT * FROM CUSTOMERS WHERE ID = ").Value(myId, SqlDbType.Int);
//or
bldr.Append("SELECT * FROM CUSTOMERS WHERE NAME LIKE ").FuzzyValue(myName, SqlDbType.NVarChar);
myCommand.CommandText = bldr.ToString();

Czytelność kodu, mam nadzieję, że się zgodzisz, została znacznie poprawiona, a wyjście jest odpowiednim parametryzowanym zapytaniem.

using System;
using System.Collections.Generic;
using System.Text;
using System.Data;
using System.Data.SqlClient;

namespace myNamespace
{
    /// <summary>
    /// Pour le confort et le bonheur, cette classe remplace StringBuilder pour la construction
    /// des requêtes SQL, avec l'avantage qu'elle gère la création des paramètres via la méthode
    /// Value().
    /// </summary>
    public class SqlBuilder
    {
        private StringBuilder _rq;
        private SqlCommand _cmd;
        private int _seq;
        public SqlBuilder(SqlCommand cmd)
        {
            _rq = new StringBuilder();
            _cmd = cmd;
            _seq = 0;
        }
        //Les autres surcharges de StringBuilder peuvent être implémenté ici de la même façon, au besoin.
        public SqlBuilder Append(String str)
        {
            _rq.Append(str);
            return this;
        }
        /// <summary>
        /// Ajoute une valeur runtime à la requête, via un paramètre.
        /// </summary>
        /// <param name="value">La valeur à renseigner dans la requête</param>
        /// <param name="type">Le DBType à utiliser pour la création du paramètre. Se référer au type de la colonne cible.</param>
        public SqlBuilder Value(Object value, SqlDbType type)
        {
            //get param name
            string paramName = "@SqlBuilderParam" + _seq++;
            //append condition to query
            _rq.Append(paramName);
            _cmd.Parameters.Add(paramName, type).Value = value;
            return this;
        }
        public SqlBuilder FuzzyValue(Object value, SqlDbType type)
        {
            //get param name
            string paramName = "@SqlBuilderParam" + _seq++;
            //append condition to query
            _rq.Append("'%' + " + paramName + " + '%'");
            _cmd.Parameters.Add(paramName, type).Value = value;
            return this; 
        }

        public override string ToString()
        {
            return _rq.ToString();
        }
    }
}

Nie widziałem żadnych innych odpowiedzi na tę stronę "dlaczego robienie tego samemu jest złe" , ale rozważ Atak obcinania SQL.

Istnieje również funkcja QUOTENAME T-SQL, która może być pomocna, jeśli nie możesz przekonać ich do użycia params. Łapie dużo (wszystko?) uciekinierów z qoute.

2 lata później, recydywę... Każdy, kto stwierdzi ból parametrów, może wypróbować moje rozszerzenie VS, QueryFirst. Edytujesz swoje żądanie w rzeczywistości .plik sql (Walidacja, Intellisense). Aby dodać parametr, wystarczy wpisać go bezpośrednio do SQL, zaczynając od'@'. Podczas zapisywania pliku, QueryFirst wygeneruje klasy opakowujące, które pozwolą Ci uruchomić zapytanie i uzyskać dostęp do wyników. Wyszukuje Typ DB twojego parametru i mapuje go na typ. NET, który znajdziesz je jako dane wejściowe do wygenerowanych metod Execute (). nie może być prostsze . Robienie tego we właściwy sposób jest radykalnie szybsze i łatwiejsze niż robienie tego w jakikolwiek inny sposób, a tworzenie luki w SQL injection staje się niemożliwe, a przynajmniej przewrotnie trudne. Istnieją inne zalety killer, jak możliwość usuwania kolumn w DB i natychmiast zobaczyć błędy kompilacji w aplikacji.

Zastrzeżenia prawne: napisałem QueryFirst

Oto kilka powodów, dla których warto używać parametryzowanych zapytań:

1. bezpieczeństwo - warstwa dostępu do bazy danych wie, jak usunąć lub uciec elementy, które nie są dozwolone w danych.
2. separacja obaw-Mój kod nie jest odpowiedzialny za przekształcenie danych w format, który lubi baza danych.
3. Brak redundancji - nie muszę dołączać asemblera ani klasy do każdego projektu, który formatuje/ucieka bazę danych; jest on wbudowany w bibliotekę klas.

Było kilka luk (nie pamiętam, która to była baza danych), które są związane z przepełnieniem bufora instrukcji SQL.

Chcę powiedzieć, że SQL-Injection to coś więcej niż tylko "ucieczka od cytatu" i nie masz pojęcia, co będzie dalej.

Innym ważnym aspektem jest śledzenie danych uciekających i niezaklejonych. Istnieje mnóstwo aplikacji, internetowych i innych, które nie wydają się prawidłowo śledzić, kiedy dane są surowe-Unicode, & - zakodowane, sformatowany HTML, itp. Jest oczywiste, że trudno będzie śledzić, które łańcuchy są zakodowane '', a które nie.

Jest to również problem, gdy kończy się zmiana typu jakiejś zmiennej - być może kiedyś była to liczba całkowita, ale teraz jest to sznurek. Teraz masz problem.

Zawsze używaj parametryzowanych zapytań tam, gdzie to możliwe. Czasami nawet proste wejście bez użycia dziwnych znaków może już utworzyć SQL-injection, jeśli nie jest zidentyfikowane jako Wejście dla pola w bazie danych.

Niech więc baza danych wykona swoją pracę nad identyfikacją samego wejścia, nie wspominając o tym, że oszczędza również mnóstwo kłopotów, gdy trzeba rzeczywiście wstawić dziwne znaki, które w przeciwnym razie zostałyby usunięte lub zmienione. Może nawet zapisać kilka cennych runtime w końcu za brak konieczności obliczania danych wejściowych.