Formy ataku SQL Injection Niedostateczne filtrowanie danych Ten typ ataków opiera się na nieodpowiednim filtrowaniu znaków ucieczki z danych wejściowych, co pozwala na przekazanie dodatkowych parametrów do zapytania. Poniższy kod prezentuje ten problem (PHP): $q = mysql_query("select * FROM uzytkownicy WHERE uzytkownik = '$uzytkownik'"); Gdy użytkownik przekaże jako $uzytkownik wartość "kowalski", całe zapytanie przyjmie postać: SELECT * FROM uzytkownicy WHERE uzytkownik = 'kowalski' i będzie spełniało swoją funkcję. Jednak gdy złośliwy użytkownik przekaże wartość "x' OR '1'='1" to całe zapytanie będzie wyglądało: SELECT * FROM uzytkownicy WHERE uzytkownik = 'x' OR '1'='1' przez co pobierze z bazy danych wszystkie rekordy zamiast jednego wybranego. Teoretycznie w ten sposób można przekazać każde zapytanie SQL, włącznie z wykonaniem kilku zapytań naraz. Jeżeli w powyższym przykładzie użytkownik przekaże x';drop TABLE uzytkownicy; SELECT * FROM data WHERE nazwa LIKE '% to całe zapytanie przybierze postać SELECT * FROM uzytkownicy WHERE uzytkownik = 'x';drop TABLE uzytkownicy; SELECT * FROM dane WHERE nazwa LIKE '%' co zaowocuje usunięciem tabeli "uzytkownicy" i pobraniem wszystkich danych z tabeli "dane". Korzystając z ataku typu SQL Injection można również przeprowadzić atak typu DoS (odmowy usługi): x' AND BENCHMARK(9999999,BENCHMARK(999999,BENCHMARK(999999,MD5(NOW()))))=0 OR '1'='1 W tym przypadku serwer spróbuje obliczyć skrót MD5 dla aktualnego czasu 999999 3 = 999997000002999999 (w zaokrągleniu trylion) razy. "Ślepy" atak O "ślepym" ataku (ang. Blind SQL Injection) mówi się w przypadku wykonywania ataku typu SQL Injection na stronie, która nie wyświetla komunikatów błędów. W tym przypadku badać można zmiany na stronie, przykładowo:
SELECT * FROM uzytkownicy WHERE uzytkownik='x' AND 1=2; Powyższe zapytanie powinno nic nie zwrócić. Inaczej w przypadku wykonania poniższego zapytania: SELECT * FROM uzytkownicy WHERE uzytkownik='x' OR 1=1; Powyższe zapytanie powinno zawsze zwrócić jakikolwiek wynik, bowiem 1 jest równe 1. Badając zmiany zachodzące na stronie można stwierdzić czy w danym miejscu można dokonać ataku. Błędy w serwerze SQL Czasami błędy umożliwiające atak występują w samym serwerze SQL, jak było w przypadku funkcji real_escape_chars() z MySQL. Zabezpieczanie przed atakiem Zabezpieczanie na poziomie aplikacji Podstawowym sposobem zabezpieczania przed SQL injection jest niedopuszczenie do nieuprawnionej zmiany wykonywanego zapytania. W PHP można to zrobić, poprzez wykonanie na każdym tekstowym parametrze wykorzystywanym do budowy zapytania wbudowanej funkcji addslashes(), która dodaje backslash przed znakami, takimi jak ', " czy \, dzięki czemu znaki te nie są traktowane jak znaki specjalne. Dostępne są również funkcje specyficzne dla poszczególnych silników, takie jak np. oferowana przez serwer MySQL mysql_real_escape_string(). Jeśli wczytując dane z formularza programista oczekuje wartości liczbowych, może korzystać z funkcji is_numeric(zmienna), która sprawdza czy zmienna jest wartością numeryczną. Po sprawdzeniu zmiennej i upewnieniu się, iż jest liczbą, można bezpiecznie użyć zmiennej w zapytaniu SQL. Analogicznie do addslashes(), w perlowym DBI istnieje metoda DBI::quote, która, podobnie jak addslashes() z PHP dodaje znaki backslash przed potencjalnie niebezpiecznymi znakami. Przykład (zakładając, że $sql jest referencją do obiektu DBI): $query = $sql->prepare("select * FROM uzytkownicy where name = ". $sql- >quote($uzytkownik)); Bezpieczniejszą techniką, niż wyżej wymienione odpowiednie przygotowanie parametrów jest użycie mechanizmu tzw. "zaślepek", gdzie zmienne nie są używane bezpośrednio do tworzenia zapytania, a odpowiednie dane dołączane są do zapytania w momencie jego wykonania (czy to poprzez wykorzystanie API danego silnika, czy też w ramach warstwy aplikacji poprzez odpowiednie zacytowanie wszystkich parametrów). Przykład w Perl DBI: $query = $sql->prepare("select * from users where name =?"); $query->execute($user_name);
Jeżeli parametr zapytania ma być wartością liczbową można go po prostu rzutować na typ liczbowy lub użyć funkcji konwertujących z ciągu znaków na wartość liczbową. Techniką utrudniającą wykorzystanie istniejących luk jest zastosowanie paradygmatu security through obscurity poprzez wyłączenie wyświetlania komunikatów o błędach. Nie uniemożliwi to ataku, lecz może spowodować, że trudniejsze będzie wykrycie i późniejsze wykorzystanie luki. Zabezpieczenie na poziomie bazy danych Istnieją również metody zabezpieczenia przed skutkami wykonania błędnych zapytań, które mimo wszystko dostaną się do bazy. Udostępnienie użytkownikowi bazy tylko niezbędnych uprawnień nie da całkowitej ochrony, jednak pozwoli na minimalizację szkód. Przykładowo niewiele aplikacji potrzebuje uprawnienia do kasowania tabel z bazy danych. Podobny efekt czyli zmniejszenie możliwości atakującego uzyskać można wyłączając niepotrzebną funkcjonalność na poziomie samego silnika. Pomocą mogą służyć również procedury składowane, dzięki którym zapytanie budowane jest po stronie bazy danych i aplikacja nie ma bezpośredniego wpływu na jego postać. Chociaż i w tym przypadku skonstruowanie ataku nie jest niemożliwe. Eliminację możliwości wstrzyknięcia kodu SQL, można uzyskać poprzez całkowite wyłączenie możliwości podawania parametrów jako części zapytania. Jest to działanie analogiczne do mechanizmu zaślepek po stronie aplikacji, jednak tym razem zastosowane w samym silniku. Nie jest to jednak ogólnie dostępna cecha systemów zarządzania bazami. W chwili obecnej, możliwość taką daje silnik H2. Przykłady ataków SQL Injection Atak SQL Injection wykorzystuje fakt że dane wpisane do formularza na stronie WWW (lub w inny sposób wysłane do serwera) nie są w żaden sposób walidowane pod kątem ich poprawności. Do tego dochodzi fakt że w zapytaniach SQL stringi należy zamknąć pomiędzy znakami apostrofu. Zatem jeżeli ktoś wpisze do formularza ciąg znaków zawierający m.in. apostrof, różne rzeczy mogą się przytrafić - od zwykłego błędu wykonania zapytania SQL, aż po wykasowanie wszystkich danych z bazy danych czy dysku serwera, albo włamania do innych maszyn w sieci! Najprostszy atak SQL Injection może wyglądać następująco: załóżmy że na stronie znajduje się następujący formularz: <form method="post" action="login.php"> Login: <input type="text" name="login"><br> Hasło: <input type="password" name="pass"><br> <input type="submit" value="zaloguj się"><br> </form> Po stronie serwera, w kodzie PHP tworzone i wykonywane jest następujące zapytanie: SELECT USER_ID FROM USERS WHERE (LOGIN='$login') AND (PASS='$pass')
Zmienne $login i $pass zawierają odpowiednio login i hasło wpisane w formularzu. Załóżmy że do systemu loguje się admin, posługując się swym bezpiecznym hasłem "jh*8!aac4". Zapytanie które zostanie wykonane wygląda następująco: SELECT USER_ID FROM USERS WHERE (LOGIN='admin') AND (PASS='jh*8!aaC4') Jak na razie wszystko wygląda w porządku. Załóżmy jednak że nasz Czarny Kapelusz (Black Hat) próbuje się włamać, i wpisał jako hasło: ' OR '1'='1 Wynikowe zapytanie które zostanie wykonane będzie następujące: SELECT USER_ID FROM USERS WHERE (LOGIN='admin') AND (PASS='' OR '1'='1') Jak widać, w zapytaniu zmienił się warunek który sprawdza hasło - obecnie składa się on z sumy logicznej dwóch warunków: pierwszego który jest fałszywy (no chyba że admin nie ma założonego hasła, co jest mało prawdopodobne), i drugiego który jest zawsze prawdziwy. Wynik: napastnik zalogował się na konto admina bez znajomości (!) jego hasła. Powyższy przykład ataku można zmodyfikować, wpisując następujący ciąg znaków jako nazwę użytkownika, i dowolne hasło (np. "a"): admin') -- Wynikowe zapytanie które zostanie wykonane będzie następujące: SELECT USER_ID FROM USERS WHERE (LOGIN='admin') --') AND (PASS='a') W języku SQL dwa myślniki umieszczone obok siebie oznaczają początek komentarza, zatem w rezultacie wykona się tylko pierwsza część warunku WHERE (sprawdzenie nazwy użytkownika). Napastnikowi może także nie zależeć na uzyskaniu nieautoryzowanego dostępu do serwera, ale na wyrządzeniu jak największych szkód. Może on tu skorzystać z faktu, że baza danych może wykonać kilka zapytań podanych po kolei (i ew. rozdzielonych średnikiem). Przykładowo może on wpisać coś takiego jako nazwę użytkownika: ') DELETE FROM USERS -- Wynik jest mało przyjemny - skasowana zostanie zawartość tabeli USERS. Napastnik może posunąć się jeszcze dalej, wpisując coś takiego: ') DROP DATABASE SKLEP -- Po wykonaniu tej komendy cała nasza baza danych przestaje istnieć! Jeżeli baza danych pozwala na wykonywanie poleceń systemowych, napastnik może także wykasować zawartość twardego dysku. Np. źle skonfigurowana baza danych MS SQL Server na Windows może pozwolić na wykonanie takiego ataku: '); exec master..xp_cmdshell 'iisreset /stop' --
Wpisane powyższego ciągu znaków jako nazwy użytkownika spowoduje zatrzymanie serwera IIS (Internet Infomation Server, czyli serwer WWW Microsoftu). Jakie to może mieć skutki np. dla sklepu internetowego chyba nie muszę tłumaczyć. Poza tym w systemie istnieje cały szereg innych komend które napastnik może wykorzystać do złych celów. Celem napastnika może nie być sianie zniszczenia, ale chęć kradzieży poufnych danych. Załóżmy że sklep internetowy pozwala na wyświetlenie listy produktów które zamówiło się w ostatnim czasie, za pomocą zapytania: SELECT PRODUKT_ID, NAZWA, OPIS, KWOTA FROM PRODUKTY, ZAMOWIENIA WHERE (PRODUKTY.PRODUKT_ID=ZAMOWIENIA.PRODUKT.ID) AND (KLIENT_ID=$id) ORDER BY NAZWA W tym przykładzie identyfikator klienta jest przekazywany z zewnątrz. W normalnej sytuacji jest to liczba; jeżeli jednak napastnik wpisze coś takiego: 0 OR 1=1 wtedy ostatnia linia warunku WHERE przybierze następującą postać: AND (KLIENT_ID=0 OR 1=1) Wynik: cała historia zamówień dokonanych przez wszystkich klientów sklepu wyświetli się na stronie. Napastnik może także dostać się do innych tabel, korzystając z instrukcji UNION. W tym celu może wpisać np. coś takiego jako id: -1) UNION SELECT KLIENT_ID, LOGIN, HASLO, 0 FROM KLIENCI -- Ostatnia linia warunku będzie wyglądać następująco: AND (KLIENT_ID=-1) UNION SELECT KLIENT_ID, LOGIN, HASLO, 0 FROM KLIENCI --) Zero w drugim zapytaniu SELECT po UNION jest konieczne aby liczba kolumn i ich typy się zgadzały. Całe zapytanie po wykonaniu zwróci napastnikowi listę loginów i haseł wszystkich klientów sklepu (być może także personelu, a przy odrobinie szczęścia nawet i hasło admina). Stąd już prosta droga do kradzieży np. danych osobowych. Na tym możliwości ataków się nie kończą - korzystając z SQL Injection oraz faktu że strona ASP nie sprawdza potencjalnych błędów bazy danych można szukać innych tabel w bazie danych, oraz próbować określić typy ich kolumn - więcej na ten temat jest w materiałach do których linki są podane na końcu. Zabezpieczenie przed atakiem SQL Injection Aby zapobiec tego typu atakom, należy traktować wszystkie dane otrzymane z zewnątrz jako niezaufane, i sprawdzać ich poprawność. W przypadku liczb doskonale nadają się do tego np.
wyrażenia regularne - w powyższym przykładzie parametr id można sprawdzić używając poniższego warunku (sprawdza on czy string składa się tylko z cyfr): if (!ereg('^\d+$', $id)) { // obsługa niepoprawnych danych } W przypadku danych tekstowych (jak np. login czy hasło) należy odpowiednio zakodować wszystkie pojedyncze apostrofy (zazwyczaj zamienić je na parę apostrofów), przez co ewentualny atak zostanie unieszkodliwiony. Dla każdej obsługiwanej bazy danych PHP dostarcza odpowiednią funkcję dedykowaną do tego celu, np. dla bazy MySQL jest to funkcja mysql_escape_string(). Można ją użyć następująco: $login = mysql_escape_string($login); W przypadku stringów można także rozważyć czy znak apostrofu może wystąpić w "legalnych" danych wejściowych - jeżeli nie, można dodać warunek który będzie odrzucał takie dane. W każdym przypadku warto także określić maksymalną długość danych wejściowych, i ją też kontrolować. Jeżeli dane tekstowe są przeznaczone do późniejszego wyświetlenia na stronie WWW (a tak jest w większości przypadków), należy pamiętać aby przed ich wyświetleniem zamienić wszystkie znaki specjalne HTML na ich zakodowane odpowiedniki (np. za pomocą funkcji htmlspecialchars), aby zapobiec wyświetleniu fragmentu kodu HTML (lub gorzej, skryptu JavaScript, co może być atakiem XSS - Cross Site Scripting). "Legalne" dane też mogą niekiedy powodować podobne problemy. Dane można zakodować już przed zapisem ich do bazy danych. Warto wybrać jedną z tych dwóch metod (kodowanie przed wyświetleniem, lub zapisem do bazy danych), i konsekwentnie się jej trzymać. Jeżeli używany interfejs dostępu do bazy danych obsługuje mechanizm parametrów, warto z niego skorzystać. Przedtem jednak należy się upewnić że on jest bezpieczny (tzn. parametry nie są wstawiane bezpośrednio do tekstu zapytania). mod_rewrite jako dodatkowe zabezpieczenie przed SQL Injection Dodatkowym metodą zabezpieczenia utrudniającą włamanie przez SQL Injection jest zastosowanie modułu Apache'a o nazwie mod_rewrite. Moduł ten pozwala m.in. na wykonanie przekierowania przychodzącego żądania pod zupełnie inny adres na serwerze. Sztuczka polega tutaj na tym że jest to wykonywane "wewnątrz" serwera, zatem nie jest to widoczne z zewnątrz. Z tego powodu moduł ten jest często stosowany jako jeden z elementów optymalizacji strony pod kątem wyszukiwarek internetowych. Nam jednak bardziej przyda się fakt że poprzez modyfikację adresu URL strony można ukryć oryginalną nazwę skryptu i wykorzystywane parametry przed wzrokiem ciekawskich. Przykład: strona wyświetlająca dane o produktach ma następujący adres: http://www.serwer.pl/produkty.php?kategoria=3&produkt=235 Aby to zmienić, należy dodać odpowiednie komendy do pliku.htaccess, np. takie:
RewriteEngine On RewriteBase / RewriteRule ^produkty,([0-9]+),([0-9]+)\.html$ produkty.php?kategoria=$1&produkt=$2 [L] Dzięki umieszczeniu powyższych reguł w pliki.htaccess do strony z produktami będzie się można odwołać na dwa sposoby: używając adresu podanego wcześniej, lub też nowego wykorzystującego reguły dla mod_rewrite: http://www.serwer.pl/produkty,3,235.html Taki adres ma tą zaletę z punktu widzenia bezpieczeństwa że ukryte są nazwa skryptu i jego parametry. Dodatkowo zastosowane wyrażenie regularne dokładnie określa zakres dopuszczalnych znaków będących identyfikatorami kategorii i produktu (mają to być liczby), więc próby wpisywania czegokolwiek innego gdzieś w środku adresu lub na jego końcu będą skutkować błędem 404 (nie znaleziono strony). Oczywiście przedstawione tutaj zabezpieczenie przed SQL Injection wykorzystujące mod_rewrite nie jest idealnym zabezpieczeniem przed SQL Injection - ciągle można się odwołać do skryptu używając jego oryginalnej nazwy i parametrów, zatem skrypt ten musi być również odporny na atak SQL Injection. Warto go jednak zastosować jako dodatkowe zabezpieczenie, chociażby z tego względu, że powstrzyma większość dzieciaków które przeczytały sobie w Internecie coś na temat hakingu i potem chcą zaszpanować przed znajomymi jaki to on czy ona jest wielki "H4k3R". Wielofazowy atak SQL Injection We wszystkich wcześniejszych przykładach atakujący korzystał z faktu że dane wejściowe nie były walidowane, przez co miał możliwość modyfikacji wykonywanego zapytania. Jeżeli jednak witryna stosuje zabezpieczenia podane powyżej, atakujący może poszukiwać drogi ataku wielofazowego. Polega on na tym, że w pierwszej fazie dane podane przez napastnika są zapisywane do bazy danych, z uwzględnieniem powyższych zaleceń - mogą to być np. kryteria wyszukiwania do raportów które użytkownik może wygenerować, czy sposób sortowania wyników. Użytkownik może wybrać sobie jedno z tak zapisanych np. kryteriów wyszukiwania poprzez wybór jego nazwy - wydaje się to bezpieczne, gdyż do serwera jest przesyłany wyłącznie identyfikator, który podlega sprawdzeniu czy jest poprawny. Następnie tworzone jest dynamicznie zapytanie, którego częścią jest to co zostało wcześniej zapisane w bazie danych. W tym momencie twórcy witryny WWW mogą popełnić błąd zakładając że dane pochodzące z bazy danych są "bezpieczne". Jest to błąd, gdyż apostrofy które zostały zamienione na pary apostrofów podczas zapisu do bazy, przy odczycie ich z bazy są zwracane ponownie jako pojedyncze apostrofy Aby się zabezpieczyć przed takimi niespodziankami, należy uważać w sytuacji gdy dane tekstowe pochodzące z bazy danych mają zostać użyte do konstrukcji kolejnych zapytań, i odpowiednio je zakodować. Alternatywnie można także rozważyć zamianę wszystkich apostrofów na cztery apostrofy podczas pierwszego zapisu do bazy (podczas odczytu zostanie tylko para apostrofów, czyli nadal to będzie bezpieczne) - jeżeli to rozwiązanie będzie stosowane konsekwentnie, powinno być także bezpieczne. Należy jednak w takim wypadku pilnować aby nie dopuścić do możliwości przeprowadzenia ataku 3- lub więcej fazowego.
Osobom zainteresowanym tym tematem polecam także przejrzenie następujących materiałów: SQL Injection: Modes of Attack, Defence, and Why It Matters - opis sposobu ustalenia danych o kolumnach używanych w zapytaniu; Advanced SQL Injection - zaawansowane techniki ataków SQL Injection na SQL Server; Advanced SQL Injection - do zrozumienia tej prezentacji co prawda wymagana jest pewna wiedza, ale i tak czytając nagłówki można się zorientować jakie zagrożenia niosą ze sobą ataki SQL Injection. Znajduje się tam porównanie różnych baz danych pod kątem podatności na ataki SQL Injection, oraz szereg różnych metod ataków.