PHP -> Wstrzykiwanie kodu SQL (SQL injection)

---

Dodał / zmodyfikował: pkania, w dniu:2016-03-30

---

W tym artykule przyjrzymy się zagadnieniom związanym z atakami SQL injection (wstrzykiwanie kodu SQL). Na początku przeanalizujemy konkretne przypadki, aby zrozumieć mechanizm działania tego zagrożenia. Następnie zastanowimy się jak temu zapobiegać wg zasady "lepiej zapobiegać niż leczyć".

Załóżmy, że mamy pewien system logowania (oparty na dwóch kontrolkach formularza o nazwach login oraz password). Takie same pola znajdują się w tabeli users w naszej bazie danych np. MySQL. Tabela może się składać z następujących kolumn: id | login | password | mail

Osoba chcąca się zalogować do naszego serwisu musi więc podać swój login oraz hasło wcześniej zapisane w w/w tabeli np. podczas zakładania konta. Teraz my (mówiąc w skrócie) musimy przyjąć pewne dane od użytkownika i porównać je z tymi zapisanymi w bazie. Zazwyczaj więc odbieramy te dane, przypisujemy do zmiennych i "osadzamy" w odpowiednich miejscach konstruowanego zapytania SQL. Fragment kodu PHP może więc wyglądać następująco:

$login=$_POST['login'];

$password=sha1($_POST['password']);

$query="select * from `users` where `login`='$login' and `password`='$password'";

Załóżmy, że ktoś podał w polu login wartość "jarek", a w polu password "tajne1234". Zapytanie SQL (przechowywane w zmiennej $query) będzie miało zatem następującą postać:

select * from `users` where `login`='jarek' and `password`='zahashowany_ciag_podanych_znakow';

I wszystko OK, zapytanie się wykona. W dalszej części skryptu sprawdzimy, czy wynik dał pozytywny rezultat (tzn. czy w bazie istnieje użytkownik o danym loginie i haśle) i na tej podstawie podejmiemy decyzję o pomyślnym zalogowaniu, czy też nie...

Ale ... jeżeli ktoś zna choćby podstawy języka SQL, to wie, że np. dwa znaki myślnika (--) w tym języku oznaczają komentarz. Może to zatem wykorzystać w naszym skrypcie logowania ! Ale jak ! Przecież kod PHP wykonuje się po stronie serwera, a nam zwraca tylko to, co otrzyma od parsera. Tu nic się nie zmieniło, dalej zasada wykonywania skryptów pozostanie niezmienna. Natomiast "sprytny" użytkownik może próbować wpisać następujący ciąg znaków do pola formularza o nazwie login: cos' OR 1=1 -- czyli: napis_cos apostrof spacja OR 1=1 spacja -- spacja. W tym momencie nasze zapytanie wewnąt skryptu (zmienna $query) przyjmie następującą postać:

select * from `users` where `login`='cos' OR 1=1 -- `password`='zahashowany_ciag_podanych_znakow';

Co się zatem stało ? Zalogowaliśmy się na pierwszego użytkownika z naszej tabeli nie znając nawet jego loginu, nie mówiąc już o haśle... Tak zmodyfikowaliśmy zapytanie SQL (to co wstrzyknięto w zapytanie celowo zaznaczyłem na zielono), że jedna jego część dała rezultat true (OR 1=1). Dalsza część zapytania nie jest brana pod uwagę, ponieważ zostanie potraktowana jako komentarz. To jeszcze nie wszystko. Tym sposobem uda nam się zalogować tylko na pierwszego użytkownika z tabeli users.

A co jeśli znamy login któregokolwiek z użytkowników ? Czy zalogowanie na jego konto bez podania hasła będzie możliwe ? Spróbujmy tym razem w polu formularza login wpisać następującą frazę: jarek' -- , czyli: znany_login_uzytkownika apostrof spacja -- spacja

I jak ? udało się zalogować na konto Jarka ? Pewnie, że tak. Tym razem zapytanie przedstawia się następująco:

select * from `users` where `login`='jarek' -- `password`='zahashowany_ciag_podanych_znakow';

Jak już zapewne zauważyłeś i tym razem druga część zapytania nie jest brana pod uwagę, a jego pierwsza część zwróci wynik true... (oczywiści jeżeli takie konto w bazie danych istnieje).

I jeszcze jeden przykład. Zakładam, że dowiedziałeś się jaką nazwę posiada jedna z kolumn tabeli users. Powiedzmy, że jest to kolumna o nazwie id. W tym momencie można spróbować wpisać w polu login następujący ciąg znaków: cos' OR id=3 -- ,czyli: napis_cos apostrof spacja OR spacja id=3 spacja -- spacja. Teraz nasze zapytanie wygląda tak:

select * from `users` where `login`='cos' OR id=3 -- `password`='zahashowany_ciag_podanych_znakow';

Jeżeli chodzi o wytłumaczenie tego zapytania odsyłam Cię do pierwszego przykładu z tego artykułu. Finał tego zapytania będzie taki, że zalogujemy się na użytkownika o id=3.

Jak widzisz przeprowadzenie ataków tego typu nie jest zbyt skomplikowane. We wspomnianych przykładach nawet nie starałem się użyć jakiś wysublimowanych sposobów, a mimo to nasz skrypt okazał się dziurawy jak druszlak :) Strach pomyśleć, co by się stało, gdybym próbował użyć innych sposobów "oszukania" zapytania (podmiany znaków itd...). Lepiej może się nad tym już nie zastanawiać :)

Zajmijmy się teraz obroną przed tego typu atakami !

Najważniejsza zasada brzmi: nigdy nie ufaj temu, co otrzymujesz (pobierasz) od użytkownika !

W tej sytuacji z pomocą przychodzą funkcje wbudowane, które walidują (sprawdzają) poprawność otrzymanych danych oraz / lub funkcje sanityzujące (oczyszczające, odkażające) otrzymane dane. Oczywiście nikt Ci nie każe korzystać z funkcji wbudowanych. Możesz napisać własną funkcję sprawdzającą, czy np. w przekazywanych danych istnieją jakiekolwiek niedozwolone znaki itp. Niemniej jednak w PHP już istnieje wachlarz funkcji gotowych do ew. wykorzystania we własnych projektach. Opis wspomnianych funkcji odnajdziesz na stronie: http://php.net/manual/en/filter.filters.php

Ponadto przy budowaniu zapytań możemy skorzystać z połączenia dwóch funkcji sprintf oraz mysqli_real_escape_string

W tym przypadku składnia zapytania może wyglądać następująco:

$zapytanie=sprintf("select * from `user` where `login`='%s' and `password`='%s' LIMIT 1;", mysqli_real_escape_string($db,$uzytkownik), mysqli_real_escape_string($db,$pass)));

gdzie $db jest "uchwytem" do połaczenia z bazą danych (za pomocą mysqli). W wypadku używania obiektów zapis może się przedstawiać następująco:

$user=new sqlQuery;
$user->myQuery(sprintf("select * from `user` where `login`='%s' and `password`='%s' LIMIT 1;", mysqli_real_escape_string($user->db,$uzytkownik), mysqli_real_escape_string($user->db,$pass)));

---