Sekcje

Przejdź na skróty do treści. | Przejdź do nawigacji


Baza wiedzy Publikacje Wprowadzenie do SQL injection

Wprowadzenie do SQL injection

Czym jest SQL Injection ?

Chociaż  od odkrycia i spopularyzowania podatności SQL Injection minęło już prawie 15 lat, nie jest dziś wcale niecodzienną informacja o spenetrowaniu z jego wykorzystaniem jakiegoś istotnego systemu IT.

Jedną z oczywistych przyczyn tego faktu jest to, że programista nie zawsze jest świadomy, iż wrażliwy element aplikacji, który właśnie buduje, mimo wszystko łączy z użytkownikiem końcowym trwała linia: dane wejściowe.

Pomimo iż dany element systemu może wydawać się niezależnym i odseparowanym od „świata zewnętrznego” przez kilka warstw architektonicznych projektu IT, cały czas należy mieć na uwadze to, że użytkownik końcowy jest w stanie przy pomocy konkretnych akcji wywołać konkretną kontrolowaną przez niego reakcję danego elementu systemu.

Mówiąc w skrócie – istotą luk SQL Injection jest całkowity brak lub niepoprawna walidacja danych wejściowych, umożliwiająca zdalnemu użytkownikowi bezpośrednią „rozmowę” z silnikiem bazy SQL przy pomocy dowolnej postaci zapytań SQL.


Samo „wstrzykniecie” fragmentu zapytania SQL do bazy danych może odbyć się różnymi drogami. Za taki zdalny punkt styku użytkownik–baza, z którego może dojść do próby ataku, można uznać każde miejsce, w którym użytkownik jest w stanie wprowadzić ręcznie lub przy użyciu automatów jakiekolwiek dane biorące udział w późniejszej budowie stringów zapytań dla bazy, i to na jakimkolwiek etapie działania aplikacji.
Mogą to więc być np.:

  • dane formularzy HTML,
  • zmienne przekazywane w łańcuchu URL,
  • dane przekazywane w cookies użyte przez aplikację serwerową przy formowaniu zapytań SQL.

Nie należy również zawężać klasy podatności SQL Injection wyłącznie do aplikacji webowych. Podatna może być każda aplikacja, nie tylko ta, do której dane wejściowe wprowadzane zdalnie przez użytkownika transportowane są protokołem HTTP.  Jeśli zdalny użytkownik, używając pewnego interfejsu wprowadzania danych (nie koniecznie przeglądarki), dostarcza jakimś protokołem komunikacyjnym danych dla naszej aplikacji, połączonej łańcuchem zapytań SQL z wewnętrznym serwerem SQL, to można założyć, że potencjalnie możliwe jest przeprowadzenie na taki system ataku SQLi.

Potencjalne skutki ataku z wykorzystaniem luki SQLi mogą być zróżnicowane, głównie ze względu na poziom dostępu użytkownika bazy sprzężonego z web aplikacją oraz konfigurację silnika DB. Głównymi skutkami ataku mogą być:

  • obejście uwierzytelnienia użytkownika na poziomie web aplikacji,
  • nieuwierzytelniony odczyt danych z bazy,
  • nieuwierzytelniony zapis nowych danych do bazy, modyfikacja struktury bazy (tabele, widoki, procedury składowane), modyfikacja zawartości bazy,
  •  zdalne wykonanie kodu w systemie operacyjnym hosta bazy, w kontekście procesu silnika DB.

Zasada działania  podatności i podstawowe metody detekcji .

Rozważmy prosty kod aplikacji PHP używającej silnika MySQL, w którym chcemy sprawdzić czy użytkownik o danym nick'u już istnieje w bazie:

    <?php
    ...
    $nickName = $_POST['NickName'];
    $queryString = "SELECT * FROM users WHERE nickname = '$nickName'";

    $query = mysql_query($queryString);
    $results = mysql_fetch_array($query);
    ...
    ?>

 

Pierwszym sygnałem ew. podatności aplikacji jest jej reakcja na wprowadzenie apostrofu do argumentu, przesyłanego w tym przypadku w requeście POST.

Co prawda w wersjach PHP starszych niż 5.4.0 istnieje możliwość automatycznego odfiltrowania znaków specjalnych (‘ ” \ oraz NULL ) z parametrów od użytkownika, z użyciem przełącznika magic_quotes_gpc w pliku konfiguracji php.ini, jednak nie gwarantuje to w żadnym wypadku zabezpieczenia przed atakiem SQLi. W wersji PHP 5.4.0+ przełącznik ten został usunięty.

Niech następujący kod będzie naszym przykładowym kodem HTML przesyłającym powyższemu fragmentowi aplikacji w PHP argumenty dynamiczne od użytkownika (żądany login):

    <form action="IsNicknameAvailable.php" method="post">        Nick Użytkownika:

        <input type="text" name="nickname" /> <br>        <input type="submit" name="submit" value="register" />     </form>

Spróbujmy teraz wprowadzić w którymś z pól formularza pojedynczy apostrof bądź łańcuch alfanumeryczny zawierający apostrof.

W efekcie, w oknie przeglądarki w pozycji strony za której zawartość odpowiada rezultat naszego skryptu PHP, otrzymamy komunikat:

    "Warning: mysql_fetch_array(): supplied argument is not a valid MySQL result resource

    in /home/...../public_html/RegisterNewUser.php on line ..."

Należy tutaj wspomnieć, że w razie wystąpienia błędu poprawnie skonfigurowana aplikacja PHP (w wersji produkcyjnej) może ich nie wyświetlać albo np. zwrócić jedynie kod 500 błędu serwera HTTP bez podawania szczegółów o specyfice błędu z punktu widzenia silnika DB.

Najpierw skupmy się jednak na prostszych  przykładach, w których komunikaty błędów nie zostały przechwycone ani przez programistę przy użyciu obsługi wyjątków, ani wyłączone przez konfigurację serwera.

„Dzięki” temu potencjalny atakujący ma możliwość oglądania ich „gołym okiem” w przeglądarce.

Nasz powyższy komunikat błędu, pochodzący z silnika bazy MySQL, oznacza spowodowanie przez nas wystąpienia błędu składni SQL. Dokładniej rzecz ujmując: jeśli naszą wartością wpisaną w polu "nick" był łańcuch "abc'def" to wynikiem podstawienia pod zmienną $queryString w polu '$nickName' naszej wartości, będzie dostarczenie do interpretera w silniku DB następującego stringu:

SELECT * FROM users WHERE nickname = 'abc'def'   

Jak widać, nasz apostrof w środku pola "nickname" powoduje domkniecie stringu po znaku 'c', a pozostała część stringa ("def") – niebędąca w tym miejscu poprawnym wyrażeniem języka SQL – plus nadmiarowy apostrof na końcu, generują błąd składni SQL.

To sugeruje możliwość zadawania (i wykonania) po stronie przeglądarki konkretnych zapytań do silnika bazy przez dowolną osobę. Oczywiście ”zadawania” ich w kontekście użytkownika DB, który do tego celu został utworzony przez administratora bazy, na potrzeby współpracy między aplikacją serwerową a silnikiem bazy. W związku z powyższym – jak łatwo przewidzieć – potencjalne skutki penetracji systemu przez atakującego są proporcjonalne do uprawnień tego konkretnego użytkownika  bazy (użytkownika na którym pracuje web aplikacja).

Oczywiście programista nie musi użyć apostrofu do domknięcia łańcucha tekstowego – może zastosować cudzysłów. W takim przypadku wprowadzenie przez nas znaku apostrofu nie spowoduje błędu składni – znak zostanie uznany za składnik pola tekstowego i nie spowoduje domknięcia stringu. Należy więc sprawdzać reakcję aplikacji na wprowadzenie obu znaków domknięcia.
Analogicznie w przypadku pola numerycznego (np.: Integer): wprowadzenie któregokolwiek znaku domknięcia stringu przy braku poprawnej walidacji zawartości tego pola przed uformowaniem i zadaniem zapytania do bazy spowoduje błąd składni SQL. Jednakże w takiej sytuacji błąd ten umożliwi również wprowadzenie jakiejkolwiek wartości nienumerycznej, np. wstawienie litery.

Jak może wyglądać najprostszy atak na uwierzytelnienie?


Przyjrzyjmy się bliżej pierwszemu z możliwych ataków na webowy system DB i spróbujmy przeanalizować krok po kroku, jak wygląda sposób działania  web aplikacji podczas takiego ataku.
Poniższy kod będzie naszym przykładowym skryptem aplikacji sprawdzającym poprawne logowanie użytkownika:

    <?php
    ....
    $userName = $_POST['UserName'];
    $password = $_POST['Password'];
    $queryString = "SELECT userId FROM users WHERE 
           username = '$userName' AND password = '$password' ";
    $query = mysql_query($queryString);
    $results = mysql_fetch_array($query);
    ...
    ?>

 

Jeśli atakujący przekaże w formularzu logowania do skryptu PHP wartości pól odpowiednio:

    Password = "abcd"

    UserName = "aaa' or 1=1 #"

to zapytanie skierowane do silnika DB uzyska postać:

       SELECT userId FROM users WHERE username = 'aaa' or 1=1 #'

and password = 'abcd'

Ponieważ znak ‘#’ w języku SQL rozpoczyna komentarz, reszta warunku logicznego sekcji "WHERE" w tym wyrażeniu SQL nie będzie brana pod uwagę (część nakładająca restrykcje podania poprawnego hasła dla podanego użytkownika) i uformuje poprawne zapytanie SQL.

Jego efektem (przy niepustej tabeli użytkowników) będzie zalogowanie użytkownika,  którego identyfikator zostanie zwrócony jako pierwszy przez bazę. 

Co za tym idzie, jeśli dana web aplikacja  posiada mechanizmy ACL (specyfikuje poziom dostępu danego użytkownika do zasobów aplikacji), istnieje duża szansa, że pierwszym utworzonym kontem w aplikacji (a zatem i pierwszym zwróconym przez nasze zapytanie) będzie konto administratora.

Podobnie atakujący może postąpić z polem zawierającym hasło i, wykorzystując założenie, że aplikacja webowa posiada użytkownika o danej nazwie (albo wręcz znając jego nazwę), obejść uwierzytelnienie i zalogować się jako dowolny użytkownik bez podania poprawnego hasła.

Stosując identyczną metodologię, możemy dowolnie modyfikować warunek dający logiczną prawdę.

W ten sposób atakujący może unikać różnego rodzaju prostych filtrów, opartych na wyszukaniu w danych wejściowych łańcucha tekstowego charakterystycznego dla potencjalnego ataku SQLi (na przykład wyszukiwania statycznego łańcucha ‘or 1=1’).

Nasz warunek logiczny w łańcuchu tekstowym użytym do ataku możemy zapisać równie dobrze np.  jako:

    ' or '2'= '2

czy:

    ' OR 'abc' = 'abc

Stosując tę samą metodologię, możemy spróbować również użyć alternatywnych znaków komentujących kod SQL (specyficznych dla danego typu silnika SQL):

'  or 1=1--

 ' or 1=1/*

 

Nieuwierzytelniony odczyt danych z bazy i enumeracja struktury bazy.

Przy pomocy skończonej liczby kroków, np. używając wspomnianych powyżej nieodfiltrowanych szczegółowych komunikatów błędu bazy danych, atakujący jest w stanie odtworzyć zarówno strukturę samego zapytania SQL, jak i wykonującego go kodu serwera.
Co za tym idzie, stosując proste mechanizmy enumeracyjne, może on również odtworzyć krok po kroku strukturę poszczególnych tabel i innych baz danego serwera DB i z kolei odczytać dowolny rekord bazy znajdujący się w zasięgu uprawnień użytkownika użytego do połączenia z bazą.
Dla przykładu, stosując  poniższe zapytanie, atakujący otrzyma listę nazw wszystkich tabel znajdujących się w bazie MySql:

SELECT TABLE_NAME , TABLE_TYPE FROM information_schema.tables 
       WHERE TABLE_TYPE = 'BASE TABLE';

 
Atakujący może otrzymać rezultat takiego zapytania, stosując  np. sumę zwracanych wartości przy użyciu metody ‘UNION SELECT’. Wykorzystując powyższe zapytanie do naszego wcześniejszego podatnego na atak kodu PHP (z punktu 3), atakujący mógłby przekazać w polach ‘UserName’ oraz ‘Password’ następujące wartości:

UserName = "aaa’ UNION SELECT 0,TABLE_NAME from information_schema.tables 
           WHERE TABLE_TYPE='BASE TABLE' LIMIT 1#" 
Password = "abcd"


Idąc dalej, używając nazw z otrzymanej listy możemy analogicznie uzyskać listę wszystkich kolumn i typów pól danych w poszczególnych tabelach:

SELECT COLUMN_NAME, DATA_TYPE , CHARACTER_MAXIMUM_LENGTH FROM 
       information_schema.columns WHERE TABLE_NAME = 'MyTable01'; 


Kolejnym krokiem atakującego może być już odczyt rekordów konkretnej, wybranej przez niego tabeli sprzężonej z aplikacją webową (zawierającej np.: dane osobowe klientów, dane autoryzacyjne kont użytkowników portalu itd.)
Należy też tutaj wspomnieć, że chociaż mechanizm monitowania o wystąpieniu błędu na poziomie bazy nie jest wcale konieczny do ataku na bazę, może on ułatwić atakującemu pozytywną identyfikację luki SQLi w danej aplikacji webowej.
Z punktu widzenia twórcy aplikacji webowej, mechanizm monitowania o wystąpieniu błędu jest narzędziem przeznaczonym przede wszystkim dla programisty budującego daną aplikacje – a nie dla użytkownika aplikacji – stąd, na ile to możliwe, powinniśmy ograniczyć „chwalenie się” szczegółami błędu aplikacji w wersji produkcyjnej systemu i ograniczyć się wyłącznie do ich logowania.

Ponieważ domyślną konfiguracją silników skryptowych jest właśnie konfiguracja deweloperska a nie produkcyjna, od zmiany tej konfiguracji powinniśmy zacząć przygotowania do zabezpieczenia naszej aplikacji.
Dla przykładu, w przypadku silnika PHP, konfiguracja ta znajduje się w pliku php.ini:

    display_errors = On 
    log_errors = Off
    error_log = /var/logs/php/errlog.txt

Z punktu widzenia bezpieczeństwa istotnym dla nas jest tylko ten pierwszy parametr.

Jego zmiana na “Off” spowoduje wyłączenie monitowania błędów przez bazę generowanych podczas wykonania kodu PHP.

Drugi parametr jest natomiast istotny z punktu widzenia projektanta systemu i (np. po uprzednim wyłączeniu monitowania błędów bazy) umożliwia zalogowanie informacji o generowanych błędach do pliku, którego ścieżkę określa trzeci parametr.

Należy tutaj dodać, że pod żadnym pozorem mechanizmy filtrowania komunikatów błędu przez aplikacje nie mogą być użyte jako jedyne i wystarczające zabezpieczenie przed atakiem SQL Injection.

Bez zadbania po stronie serwera o poprawną walidację każdej ze zmiennych nadchodzącej ze strony klienta www – udany atak jest cały czas możliwy.

W poniższym linku znaleźć można więcej informacji na temat tego w jaki sposób potencjalny atakujący może próbować znaleźć drogę do naszej bazy, omijając przy tym różne typy filtrów i stosując bardziej zaawansowane techniki ataku (jak np. Blind SQL Injection) oraz techniki specyficzne dla konkretnych baz danych (MySQL, SQL Server, ORACLE, PostgreSQL):

http://ferruh.mavituna.com/sql-injection-cheatsheet-oku/

Podstawowe metody ochrony przed SQLi.

Do głównych sposobów obrony przed atakiem SQLi zaliczyć możemy:

  •  walidację poprawności typu wprowadzonych danych,
  •  użycie funkcji filtrujących wybrane  znaki pól tekstowych,
  •  zastosowanie zapytań parametryzowanych (Prepared Statements),
  •  ograniczenie uprawnień użytkowników DB danej aplikacji webowej.


Na początku przyjrzyjmy się metodzie filtrowania niedozwolonych znaków z przekazanej wartości pola tekstowego na przykładzie bazy MySQL. Służącą do tego wbudowaną  w PHP funkcją jest mysql_real_escape_string().  Funkcja ta usuwa z argumentu każde wystąpienie jednego ze znaków:
\x00, \n, \r, \, ', " oraz \x1a
zastępując go odpowiadającym mu kodem  specjalnym poprzedzonym znakiem formatującym ‘\’. Uniemożliwia to domknięcie przez atakującego stringu  pola danych.

Dla przykładu, zastosujmy funkcję na łańcuchach, które mogłyby posłużyć atakującemu do odczytania nazw tabeli w bazie (przykład z poprzedniego punktu):

UserName = "aaa’ UNION SELECT 0, TABLE_NAME from information_schema.tables 
            WHERE TABLE_TYPE='BASE TABLE' LIMIT 1#" 
Password = "abcd"

 

Kod filtrujący dane wejściowe mógłby wyglądać następująco:

<?php 
    …
    $userName = mysql_real_escape_string($_POST['UserName']);
    $password = mysql_real_escape_string($_POST['Password']);
    $queryString = "SELECT userId FROM users WHERE username = 
                    '$userName' AND password = '$password' ";
    ...
    ?>

 

W efekcie jego działania, wartości pól  ‘UserName’ oraz ‘Password’ użyte do budowy łańcucha $queryString wyniosą:

UserName = "aaa\’ UNION SELECT 0,TABLE_NAME FROM

information_schema.tables WHERE  TABLE_TYPE=\'BASE TABLE\' LIMIT 1#"

 

    Password = "abcd"

W rezultacie, wartością łańcucha $queryString będzie:

queryString  = “SELECT userId FROM users WHERE username = ' aaa\’ UNION SELECT 0,TABLE_NAME FROM information_schema.tables WHERE TABLE_TYPE=\'BASE TABLE\' LIMIT 1# ' AND password = 'abcd'“

 

Czyli jak widać znaki apostrofu wprowadzone w polu UserName zostaną zamienione na element tekstowy pola i w rezultacie atakujący nie zdoła domknąć stringu.

Metoda ta jest skuteczna pod warunkiem, że stosujemy ją do danych o typach nienumerycznych (mówiąc ściślej: gdy filtrowane pole zostało ograniczone apostrofem bądź cudzysłowem w łańcuchu zapytania SQL).

W wypadku pól numerycznych samo zastosowanie tej metody może nie wystarczyć – zamiast niej do walidacji poprawności danych pola możemy zastosować funkcję is_numeric().

Spójrzmy na następujący przykład:

<?php

...

    $userName = mysql_real_escape_string($_POST['UserName']);

    $pin = mysql_real_escape_string($_POST['Pin']);

    $queryString = "SELECT userId FROM users WHERE username = '$userName' AND pin = $pin";     ...

    ?>

Jak widać jest on analogiczny do poprzedniego, również użyto w nim funkcji mysql_real_escape_string() do odfiltrowania znaków specjalnych z wejścia użytkownika. Zmienił się jednak typ naszego pola zawierającego hasło, teraz jest on numeryczny (pole ‘pin’). Prześledźmy co się stanie, gdy atakujący spróbuje obejść uwierzytelnienie, stosując podobnie jak wcześniej modyfikację warunku logicznego wyrażenia SQL. Po dostarczeniu danych:

UserName = "aaa"

    Pin = 1 or 1=1

wyrażenie zapytania SQL przyjmie postać:

queryString   = “SELECT userId FROM users WHERE username=’aaa’ AND pin=1 or 1=1“

Ponieważ parametr wejściowy ‘Pin’ nie zawiera żadnych znaków specjalnych (jedynie tekstowy operator ‘or ’ formujący wraz z wyrażeniem ‘1=1’ warunek logicznej prawdy w sekcji ‘WHERE’ zapytania), efekt wykonania tego kodu będzie identyczny z wcześniej przedstawionym atakiem na uwierzytelnienie – nastąpi zwrócenie listy wszystkich rekordów tabeli ‘users’ i poprawne zalogowanie pierwszego użytkownika z listy.

Główna różnica pomiędzy obu przykładami (pole tekstowe i pole liczbowe) jest taka, że w przypadku pola liczbowego atakujący nie musi domykać łańcucha pola tekstowego, by rozpocząć swoją sekwencję rozkazów SQL, pole to jest automatycznie domykane po napotkaniu pierwszej spacji.

Zatem by poprawnie zabezpieczyć się przed atakiem SQLi na pola numeryczne, najlepiej stosować weryfikację poprawności typu pola liczbowego. Można to zrobić, np. używając funkcji is_numeric() w PHP. Jeśli zawartością pola nie będzie poprawna wartość liczbowa (gdy zawierać będzie litery bądź inne znaki nienumeryczne),  funkcja ta zwróci błąd, na który możemy zareagować w naszym kodzie odpowiednim komunikatem błędu (już na poziomie aplikacji) i nie dopuścić do przekazania takiego zapytania do silnika bazy.

Alternatywną metodą obrony do zastosowania funkcji mysql_real_escape_string(), jest użycie tzw. zapytań parametryzowanych. Bezpieczeństwo tej metody opiera się na oddzieleniu fazy formowania zapytania  od fazy przekazania zmiennych pochodzących od użytkownika i otrzymania rezultatu zapytania.

Rozważmy nasz standardowy podatny kod:

<?php ...

    $userName = $_POST['UserName'];    $password = $_POST['Password'];

    $queryString = "SELECT userId FROM users WHERE username = '$userName' AND password = '$password' ";

    ...

    ?>

Stosując np. bibliotekę PDO (PHP Data Objects,) możemy w następujący sposób sparametryzować zapytanie:

<?php

    …

$db = new PDO(“mysql:dbname=mojabaza; host=localhost”, 'dbuser', 'pwd');

$query = $db->prepare(“SELECT userId FROM users WHERE username =:value1 AND password =:value2”);

$query->bindValue(“:value1”, $_POST['UserName']);

$query->bindValue(“:value2”, $_POST['Password']);

$query->execute();

?>

W przykładzie tym pierwszą fazę przygotowania zapytania stanowi wywołanie metody prepare()

Jest to pierwszy i jedyny moment, w którym następuje sprecyzowanie składni zapytania SQL, po jego wywołaniu zapytanie jest parsowane, kompilowane, optymalizowane i zapisywane przed późniejszym wywołaniem. Jak widać jest to zapytanie parametryczne, a identyfikatorami parametrów (parametry formalne) są tutaj łańcuchy ‘:value1’ oraz ‘:value2’, parametry aktualne (otrzymane od użytkownika) nie są na tym etapie uwzględniane przy budowie wyrażenia zapytania SQL.

Parametry aktualne użytkownika uwzględnione są dopiero w drugiej fazie formowania zapytania, poprzez metodę bindValue().

Na końcu należałoby wspomnieć jeszcze o dobrej polityce bezpieczeństwa, zawężającej pole manewru atakującego, jaką jest ograniczanie poziomu dostępu danego użytkownika bazy.

Błędną metodologią jest używanie w web aplikacji startowego konta administratora bazy. Poprawnym podejściem powinno być utworzenie i skonfigurowanie osobnego użytkownika dla każdej aplikacji webowej. Użytkownik taki powinien otrzymać minimalistyczny zestaw uprawnień, jaki potrzebny będzie do poprawnego funkcjonowania aplikacji (czyli dostęp zawężony do tych tabel/widoków/procedur, których wymaga architektura aplikacji, uprawnienia tylko-do-odczytu tam gdzie to możliwe).

Potencjalny atakujący może wyrządzić tylko tyle szkód, na ile pozwala mu konto użytkownika bazy.

Kolejnym sposobem na zawężenie pola działania atakującego jest zastosowanie mechanizmu procedur składowanych.

https://www.owasp.org/index.php/Avoiding_SQL_Injection#Parameterized_Stored_Procedures

Podobnie jak zapytania parametryzowane umożliwia on separację danych otrzymanych od użytkownika i przekazanie ich w postaci parametrów do wnętrza procedury. Ponieważ także i na wywołanie procedur można nakładać restrykcje w kontekście danego użytkownika, można umieścić zapytania bazodanowe webowej wewnątrz procedur składowanych,  a następnie tak skonfigurować uprawnienia użytkownika aplikacji, by posiadał on możliwość jedynie wykonania (EXEC) danej procedury lub zestawu procedur składowanych i nie posiadał uprawnień do wykonania pozostałych operacji na reszcie bazy.

6. Podsumowanie.

Metody detekcji podatności:

  • wymuszenie błędów składni SQL przez wprowadzenie znaków specjalnych w dane wejściowe (apostrof, podwójny apostrof, znak komentarza SQL),
  •  modyfikacja pól liczbowych poza zakresy graniczne (powyżej MAX, poniżej zera, losowe wartości),
  •  reakcja na wprowadzenie warunków logicznych w pola wejściowe (liczbowe i tekstowe),

Metody obrony:

  •  walidacja poprawności typu danych wejściowych (np. w PHP is_numeric() dla typu Integer, wielkość danych wejściowych, poprawność składniowa danych),
  •  użycie funkcji filtrującej wybrane znaki pól tekstowych,
  •  użycie zapytań parametryzowanych,
  •  ograniczenie uprawnień użytkowników DB danej aplikacji webowej,
  •  użycie procedur składowanych

Więcej informacji

W poniższych linkach można znaleźć więcej informacji na temat technik obrony przed atakiem SQLi:

https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet

http://www.governmentsecurity.org/articles/sql-injection-attack-prevention.html

http://www.greensql.com/articles/backdoor-webserver-using-mysql-sql-injection

 

--Jarosław Sporysz
jaroslaw.sporysz@securitum.pl

 

Przydatne informacje? Polub nas na facebooku.

Nawigacja
 
Darmowy magazyn o ITsec

zine
Subskrybuj RSS:
RSS