Bezpieczestwo skryptów na przykładzie PHP

Transkrypt

1 Bezpieczestwo skryptów na przykładzie PHP Znaczna cz serwerów sieciowych ma obecnie zainstalowany moduł do obsługi PHP. Jest to spowodowane wielk popularnoci tego jzyka wród twórców serwisów internetowych. I cho PHP to nie tylko jzyk do generowania dynamicznych stron WWW, to jednak głównie do tego celu jest wykorzystywany. Niestety, wraz z rozpowszechnieniem si kadej technologii zwiksza si te liczba błdów popełnianych przez jej uytkowników - bardzo wiele witryn tworzonych jest z całkowitym pominiciem zagadnie bezpieczestwa danych oraz systemu. Co wicej - nawet serwisy, podczas tworzenia których pamitano o podstawowych zabezpieczeniach, nie s odporne na bardziej finezyjne ataki hakerów. W opracowaniu przedstawionych zostało kilka najbardziej powszechnych typów błdów majcych wpływ na bezpieczestwo. Przedstawione zostały metody ich wykrywania i usuwania. W tekcie załoono uycie najpopularniejszego chyba zestawu programów: Apache jako serwer WWW, PHP zainstalowany jako moduł i MySql jako serwer bazy danych. 1 Bezpieczestwo plików Jak kady jzyk programowania, PHP dostarcza moliwoci pełnego operowania na systemie plików. Wszystkie wykonywane operacje podlegaj zwykłym ograniczeniom systemu skrypty działaj jako ten sam uytkownik, co Apache (zwykle jest to nobody), wic teoretycznie pliki powinny by w miar bezpieczne. Niestety, uytkownik ten nie ma za duo moliwoci, wic wielu administratorów uruchamia Apache jako root dziki temu mona zapisywa dane do katalogów uytkowników i przeprowadza inne operacje na systemie (równie niepodane np. czyta plik /etc/shadow). Aby zademonstrowa jak szkodliwy moe by tak wysoki poziom zaufania do skryptów przeledmy prosty przykład programu majcego wywietla plik z katalogu uytkownika: <? // zmienne login i plik pobierane s z formularza // wysłanego za pomoc metody POST $login = $_POST['login']; $plik = $_POST['plik']; $dane = file('/home/'.$login. '/'.$plik); while(list($line_num, $line)=each($dane)) echo htmlspecialchars($line). <br>\n ; Niby wszystko jest w porzdku, prawda? (moe poza sprawdzaniem, czy dany plik i katalog istniej, ale nie o to w tym skrypcie chodzi). Jeeli podamy np. jako login lordtedi, a jako plik.signature to zostaje wywietlona sygnatura z pliku /home/lordtedi/.signature. Ale jeli złoliwy uytkownik poda jako login../etc, a jako plik shadow, to zaczyna by nieciekawie. cieka dostpu wyglda wtedy nastpujco: /home/../etc/shadow, czyli właciwie /etc/shadow. Aby zapobiega tego typu atakom naley dokładnie sprawdza wszelkie dane otrzymywane od uytkowników - w tym przypadku wystarczy zmieni lekko skrypt:

2 <? // załómy, e ju zalogowany z prawidłowym loginem Slogin = $_SESSION['login']; $plik = basename($_post['plik']); $dane = file('/home/'. $login. '/'. $plik); while (list ($line_num, $line) = each ($dane)) echo htmlspecialchars($line). "<br>\n"; Polecenie basename z parametru zawierajcego ciek dostpu do pliku zwraca tylko sam jego nazw - wic dokładnie to, o co nam chodzi. Tym razem jeli haker poda nazw pliku../../etc/shadow, to w rzeczywistoci bdzie próbował otworzy plik /home/lordtedi/shadow. Jednake nawet takie rozwizanie nie jest pozbawione wad. Jeli bowiem skrypt jest czci witryny, na której uytkownicy mog sami okrela swoje loginy, wówczas uytkownik moe wybra login..etc, a w takim wypadku, system ponownie zostanie naraony na atak. W takim wypadku moemy si zabezpieczy stosujc wyraenia regularne. Poniej przedstawiony został przykład zastosowania tych wyrae. $login = $_SESSION['login']; // using an authentication mechanisim $homedir = "/home/$login"; if(!ereg('^[^./][^/]*$', $plik)) die('nie prawidlowa nazwa pliku'); if(!ereg('^[^./][^/]*$', $login)) die('nie prawidlowy login'); W najgorszym wypadku pojawi si komunikat o błdzie, ale bezpieczestwo systemu nie bdzie powanie zagroone. Aby jeszcze lepiej si zabezpieczy, naley ustawi open_basedir w pliku konfiguracyjnym - w tym przypadku moe to by nastpujcy cig: /var/www/:/home/ Spowoduje to, e nie bdzie moliwe otwarcie pliku spoza podanych katalogów. Czasami zachodzi konieczno wywołania polecenia systemowego z poziomu PHP. Czsto te jako jeden z argumentów tego polecenia, podaje si dane od uytkownika. Aby zademonstrowa, e beztroskie podejcie moe by katastrofalne w skutkach rozwamy kolejny przykład: <? // czy kolega jest zalogowany? $kumpel - $_POST["login"]: $polecenie = "who ".$kumpel; echo nl2br("$polecenie"): Na pierwszy rzut oka skrypt napisany jest poprawnie. Ale jeli jako login podamy lordtedi rm rf /, to moemy mie kłopoty. W tym przypadku nie trzeba ucieka si do wyrae regularnych wystarcz funkcje escapeshellarg oraz escapeshellcmd. Pierwsza zamyka parametr w apostrofy oraz zabezpiecza istniejce ju wewntrz parametru apostrofy za pomoc znaku backslash - w ten sposób polecenia systemowe potraktuj wynik jako jeden parametr. Druga słuy do zabezpieczenia komend - zabezpieczone zostan znaki, które maj jakie znaczenie dla basha (np.,? czy *). W naszym przypadku poprawiony kod mógłby wyglda nastpujco: <?

3 // czy kolega jest zalogowany? $kumpel = escapeshellarg($_post["login"]); $polecenie - "who ".$kumpel; echo nl2br("$polecenie"); 2 Bazy danych Najczstszym zastosowaniem PHP jest tworzenie dynamicznych stron WWW, np. portali czy forów dyskusyjnych. Niezalenie od zastosowania ma to zwizek z obrabianiem i wywietlaniem duej iloci danych, które zapisane s w bazie danych. Jednym z podstawowych błdów przy współpracy z aplikacjami tego typu jest ustanawianie połczenia jako superuytkownik. Dostp powinien by realizowany przez uytkownika, który ma minimum praw do ingerowania w baz (najlepiej, by nie miał bezporedniego dostpu do tabel, a jedynie do perspektyw - w ten sposób mona całkowicie odseparowa skrypt od samej bazy, a haker nie bdzie mógł nawet pozna nazw tabel, których wartoci mógłby chcie zmodyfikowa. Niestety MySQL nie udostpnia jeszcze takiej funkcjonalnoci). Skoro nie mona uywa perspektyw, trzeba radzi sobie inaczej. Pierwszym stopniem ochrony jest wspomniane ju zrónicowanie uytkowników baz danych. W wikszoci przypadków dokonuje si bowiem jedynie odczytów z bazy (np. wywietlanie tekstu, komentarzy czy wyników wyszukiwania), do rzadk operacj jest zapis (nawet w przypadku aplikacji takich jak forum dyskusyjne, z dowiadcze wynika, e w takich programach jeden zapis przypada na około odczytów). Jest to zrozumiałe ze wzgldu na sam struktur jzyka SQL- najpierw trzeba znale informacj, a dopiero potem mona j zmienia. Mona wic przyj, e zdecydowana wikszo operacji przeprowadzanych na bazie to nic wicej ni tylko zwykły odczyt informacji - czyli dozwolone musi by jedynie polecenie SELECT. Duo rzadziej uywane s polecenia modyfikujce, dodajce czy te usuwajce informacje z bazy danych - mowa tu oczywicie o INSERT, UPDATE i DELETE. Najrzadziej modyfikuje si sam struktur bazy - polecenia CREATE, DROP, INDEX, ALTER. Jak wida dla kadej aplikacji powinno si utworzy co najmniej trzech uytkowników - do odczytu, zapisu i tworzenia bazy. Uprawnie typu reload, shutdown, process, file, grant, references nie powinno si dawa adnemu uytkownikowi - wystarczy, e ma je root. Oczywicie utworzeni uytkownicy nie mog mie uprawnie do czytania bd modyfikacji innych baz i tabel (w szczególnoci bazy mysql\ tabeli user). Jeeli skrypt ma łczy si z baz danych znajdujc si na innym serwerze (w zastosowaniach amatorskich bardzo rzadko spotykane - zwykle zarówno serwer WWW jak i baza danych działa na jednym komputerze) powinno si uywa bezpiecznych połcze szyfrowanych - choby metod SSL - utrudni to ewentualny podsłuch komunikacji aplikacji z baz. W przypadku, gdy intruz uzyska dostp do bazy danych, bdzie mógł przeglda jej zawarto. Dlatego, jeeli w bazie maj by przechowywane cenne informacje, to warto zastanowi si nad zapisywaniem ich w sposób zakodowany. Do tego celu mona uy funkcji PHP z pakietu Mcrypt czy Mhash, a nastpnie zakodowane dane umieci w bazie danych. W takim wypadku intruz majc dostp do bazy nie bdzie miał moliwoci odczytania zakodowanych danych. PHP udostpnia takie polecenia szyfrujce jak: crypt() i md5(). Dla niektórych danych ich posta jawna nie jest potrzebna - przykładem mog by hasła dostpu dla uytkowników. Mona zastosowa tu ten sam schemat postpowania co przy zapisie haseł w pliku /etc/shadow - przechowuje si jedynie zakodowan informacj o hale, która nie moe posłuy do odtworzenia go (tzw. hash):

4 <? // jak zawsze zakładamy istnienie jakiego formularza, // od którego otrzymujemy interesujce nas dane $haslo = $_POST['haslo']; $login = $_POST['login']; $sprawdzenie_t = sprintf("select * FROM uzytkownicy WHERE login='%s' AND haslo='%s'", addslashes($login), md5($haslo)); $sprawdzenie_q = mysql_query($sprawdzenie_t, $polaczenie_odczyt); if (mysql_num_rows($sprawdzenie_q)!= 1) { echo "Zły login/hasło!<br>\n"; show_login_form($login); die(): } echo "Zostałe zalogowany!<br>\n"; // dodawanie nowego uytkownika do bazy $query = sprintf("insert INTO users(name,pwd) VALUES('%s','%s');", addslashes($username), md5($password)); $result = pg_exec($connection, $query); } Kiedy ju wiemy, jak powinno si postpowa zobaczmy co moe si sta, gdy nie przykłada si naleytej ostronoci do spraw bezpieczestwa. Bardzo czsto twórca serwisu nie sprawdza danych otrzymanych od uytkowników, czsto te surowa forma danych zostaje wpisana do zapytania SQL. W takich przypadkach haker moe dosta si do informacji, do których nie powinien nigdy mie dostpu. W ekstremalnych przypadkach bdzie mógł nawet zmieni informacj zapisan w bazie. Poniszy przykład zakłada, e połczenie do bazy jest wykonane przez uytkownika, który ma wystarczajce uprawnienia do wykonania podanych czynnoci (zwykle jest nim root) <? // zakładamy, e uytkownik ju w jaki sposób // zidentyfikował si i znamy jego ID, które zostało // wysłane w formularzu jako ukryte pole o nazwie ID $ID = $_POST["ID"]; $haslol = $_POST["haslol"]; $haslo2 = $_POST["haslo2"]; if (strcmp($haslol, $haslo2)) { echo "Hasła si róni!!!<br>\n"; show_change_password_form($id); die; } $zmien_haslo_t = "UPDATE uzytkownicy SET haslo=".md5($haslol). " WHERE ID = ".$ID; $zmien_haslo_q = mysql_query($zmien_haslo_t);

5 Teoretycznie wszystko działa, zmienione zostaje jedynie hasło uytkownika o właciwym ID. Jeli jednak w pole ID zamiast wartoci liczbowej wpiszemy cig znaków 12 OR 1=1 to zmienimy hasła wszystkich uytkowników (bo suma logiczna naszego warunku i prawdy bdzie zawsze prawd). Teraz wystarczy domyle si jaki login ma administrator systemu - zwykle bdzie to root albo admin (bardzo czsto loginy pojawiaj si przy wpisach, np. na forach dyskusyjnych). W ten sposób nawet bez znajomoci struktury bazy (czyli nazw pól, które przechowuj nazwy uytkowników) mona w łatwy sposób przej kontrol nad systemem. Jak broni si przed tego typu atakami? Po prostu trzeba by całkowitym paranoikiem i sprawdza kad informacj od klienta. 3 Utajnianie danych dostpu do bazy Jeli korzystamy z bazy danych, to nasza aplikacja musi mie dostp do danych umoliwiajcych dostp do bazy, czyli do takich danych jak: adres serwera bazy danych, nazwa uytkownika, hasło uytkownika. Pojawia si tu problem bezpiecznego przechowywania tyche danych. Przechowywanie ich w postaci jawnej w kodzie PHP nie jest najbezpieczniejszym rozwizaniem. Oto przykładowe metody przekazania danych dostpu: 1. w pliku konfiguracyjnym w postaci jawnej 2. dane wprowadzane z formularza 3. dane szyfrowane tu pojawia si kolejny problem - bezpiecznego przechowywania klucza szyfrowania: 3.1 klucz zapisany w pliku konfiguracyjnym 3.2 klucz zapisany w httpd.conf, powizanie wartoci klucza z lokalizacj skryptu Poniej przedstawiony został przykład ustawienia klucza w pliku httpd.conf: <VirtualHost ServerName DocumentRoot /home/przyklad.com/public_html <Directory /home/przyklad.com/ > php_admin_value safe_mode 1 php_admin_value open_basedir /home/przyklad.com/ php_admin_value disable_functions KLUCZ_1234_SZYFRUJACY </Directory> (...) </VirtualHost> Wane jest, eby plik konfiguracyjny nie miał praw czytania dla innych osób ni administrator: /usr/local/apache/conf/httpd.conf root.root drwx /usr/local/apache/conf root.root drwx Do przekazania klucza wykorzystalimy opcj 'disable_functions'. W skrypcie PHP odczytujemy klucz poprzez wywołanie nastpujcego kodu: $key = ini_get( disable_functions ); // $key -> otrzymamy KLUCZ_1234_SZYFRUJACY $user='nazwazakodowana'; $pass='haslozakodowane'; $dbname='baza1'; $dbuser=dekoduj($user,$klucz);

6 $dbpass=dekoduj($pass,$klucz); Otrzymany klucz ma t własno, e jest dostpny tylko w danej lokalizacji na dysku. Jeli skrypt przeniesiemy do innego miejsca, to klucz nie bdzie dostpny. Dziki temu moemy go uy do zakodowania danych dostpu do bazy, a take do kodowania innych wanych informacji. Mona te uy uproszczonej wersji przekazania danych dostpu, wykorzystujc dodatkowo opcj disable_class (bez kodowania). W takim wypadku konfiguracja pliku httpd.conf (VirtualHost) moe wyglda nastpujco: php_admin_value disable_functions admin php_admin_value disable_class Jak widzimy w opcjach przechowywane s: - login dostpu do bazy w opcji disable_functions, - haslo dostpu do bazy w opcji disable_class. Uycie opcji moe wyglda nastpujco: $dbname='baza1'; $dbuser=ini_get('disable_functions'); $dbpass=ini_get('disable_class'); 4 Dane od uytkowników Jak ju zostało wspomniane wczeniej, wikszo błdów spowodowanych jest niewystarczajc kontrol danych otrzymywanych od klientów. Istnieje wiele serwisów, które po wpisaniu niestandardowych wartoci do formularzy potrafi w bardzo efektowny sposób sypn seri komunikatów o błdach. Przykładem niech bdzie prosty skrypt majcy wywietla utwory muzyczne danego typu, który otrzymuje informacje z pola wyboru o nazwie typ (moliwe opcje to metal, disco, blues, techno, rave i dance). <? $znajdz_mptrojki_t = "SELECT * FROM empetrzy WHERE typ = ". $_POST[ typ ]." ORDER BY autor, tytul"; $znajdz_mptrojki_q = mysql_query($znajdz_mptrojki_q); $ile = mysql_num_rows($znajdz_mptrojki_q); for ($i =0; $i < $ile; $i++) { $mptrzy = mysql_fetch_array($znajdz_mptrojki_q); echo $mptrzy["autor"]." - ".$mptrzy["tytul"]."<br>\n"; } Autor skryptu załoył, e uytkownik nie bdzie próbował przechytrzy skryptu -jeeli poda si jaki dziwny cig znaków na przykład 'cokolwiek, do wysypania bazy danych, to zobaczymy komunikat podobny do poniszego: Warning: mysql_num_rows(): supplied argument is not a valid MySql result resource in /index.php on lin 36

7 Zauwamy, e w podanym tekcie jest apostrof, który zamyka tekst otwarty w zapytaniu. Tekst za nim jest traktowany jako polecenie SQL i dlatego pojawia si błd. Dziki komunikatowi o błdzie wiadomo, e aplikacja uywa MySQL, a wiedza ta znacznie ułatwia włamanie. Przypomnijmy sobie wczeniejszy przykład, w którym nie sprawdzano, czy skrypt otrzymuje prawidłow warto liczbow jako ID uytkownika. Aby zabezpieczy si wystarczy zmieni form zapytania na: $zmien_haslo t = sprintf("update uzytkownicy SET haslo = '%s' WHERE ID=%d", md5($haslol), $ID); Niestety, nie zapobiega to zmianie hasła innego uytkownika (a mona z duym prawdopodobiestwem załoy, e administrator bdzie miał ID równy O bd 1). Lepszym rozwizaniem jest wic przechowywanie tego typu danych po stronie serwera za pomoc sesji. Haker moe zmienia wszystko, co od uytkownika otrzymuje serwer. Najłatwiej zmieni dane przekazywane metod GET, druga w kolejnoci jest metoda POST, a teoretycznie najtrudniej zmienia si dane przekazywane przez ciasteczka (cho nowsze przegldarki udostpniaj słuce do tego narzdzia). Z tego powodu sprawdza trzeba wszystko - w poprzednim przykładzie wystarczyło rzutowa dane na typ integer, czasami jednak funkcjonalno dostarczana przez sprintf nie wystarcza. Gdy zapisujemy login do bazy danych zaley nam na tym, by nie zawierał w sobie spacji czy innych podejrzanych znaczków - wtedy naley uciec si do wyrae regularnych: <? if (!ereg("^[a-za-z_][a-za-zo-9_]*$", $login)) { echo "Nieprawidłowy login!!!<br>\n"; show_newuser_form(""); die; } W tym przypadku pole login musi zaczyna si od litery lub znaku podkrelenia, po której mog wystpi litery, cyfry i znak podkrelenia. Do zamiany cigu tekstowego na liczby nie powinno si stosowa funkcji intval oraz floatval - zwłaszcza tej drugiej, bo zezwala ona na napisy typu 1e14, a niestety baza danych niekoniecznie musi zrozumie informacje zapisane w taki sposób. Zamiast tego lepiej uy sprintf z parametrem %f. Czstym przypadkiem jest lepa wiara w dane sprawdzane po stronie klienta przez JavaScript. Jeeli znajdziemy witryn, na której dane sprawdzane s w przegldarce po stronie klienta mona z duym prawdopodobiestwem podejrzewa, e takiej kontroli nie ma na serwerze. Wystarczy wic wyłczy obsług JavaScriptu w przegldarce (lub rcznie napisa odpowiedni URL), by zobaczy reakcj programu na nieprawidłowe dane. Naley sprawdza poprawno wszystkich danych przekazywanych przez uytkownika. W szczególnoci zmienne, które s wykorzystywane do okrelania plików np. wykorzystywane w include, require, czy odczytania zawartoci pliku np. w fopen itp. W przypadku, gdy strona zawiera nastpujcy kod include_once($dir.'/lib/funkcja.php');

8 moliwe jest wywołanie strony z parametrem dir= przez co otrzymamy działanie identyczne do kodu include_once(' Spowoduje to wykonanie kodu znajdujcego si na serwerze a nie kodu, który miał by wykonany. Jak przetestowa swój własny program? Najpierw naley spróbowa wpisywania dziwnych danych do zmiennych przekazywanych na serwer. Szczególnie warto sprawdzi jak system zareaguje na zmienione wartoci ukrytych pól formularza - czsto zakłada si, e zawieraj one poprawne informacje, bo zostały ju sprawdzone w poprzednim kroku działania skryptu. Kolejnym krokiem jest zbadanie reakcji programu na brak pewnych informacji - np. usunicie pola wyboru lub ukrytego pola formularza (szczególnie dotyczy to pól, które maj jak warto domyln). Bardzo czsto zmiany takie spowoduj reakcj systemu - czasami komunikat bdzie zawierał cenne informacje, jak na przykład nazwa pola w bazie, do którego próbowano wpisa nieprawidłow informacj. Po kilku tego typu próbach bdziemy dysponowa wystarczajcymi informacjami o strukturze systemu, by spróbowa przemyci swoje polecenia. 5 Pliki konfiguracyjne Naley pamita, aby wane pliki konfiguracyjne, biblioteki itp. umieszcza poza głównym katalogiem strony (wskazywanym przez DocumentRoot). Przykładowo, jeli DocumentRoot dla domeny wskazuje na /home/przyklad.com/public_html to nasze biblioteki i pliki konfiguracyjne powinnimy umieci poza tym katalogiem np. w: /home/przyklad.com/lib /home/przyklad.com/config a nie w /home/przyklad.com/public_html/lib /home/przyklad.com/public_html/config Bardzo czsto pliki konfiguracyjne maj rozszerzenie '.inc'. W takim wypadku, jeli nasz plik z konfiguracj znajduje si w podkatalogu DocumentRoot to wystarczy wywoła adres: eby otrzyma na stronie WWW pełne dane konfiguracyjne np. dane dostpu do bazy danych: $dbname='baza1'; $dnuser='admin'; $dbpass='12345';...

9 Moesz uywa dowolnego rozszerzenia dla skryptów PHP. Wszystkie rozszerzenia jakich uywasz do skryptów PHP i plików dołczanych powinny zosta dołczone do konfiguracji serwera WWW. Na przykład, jeeli uywasz rozszerze php i inc do oznaczania skryptów PHP i plików dołczanych, powiniene si upewni, e serwer WWW został tak skonfigurowany, e bdzie traktował oba te rozszerzenia jako pliki PHP i przetwarzał je przed wysłaniem do przegldarki uytkownika. Jeeli nie zrobisz tego, uytkownik moe zapisa twoje skrypty. Rozwamy przykład, w którym do głównego pliku, securityhole.phtml, dołczany jest plik bogus.inc. Dołczany plik zawiera dane na temat połczenia z baz danych, w tym nazw uytkownika i hasło. Zawiera on równie błd syntaktyczny. Gdy otwarty zostanie plik securityhole.phtml, wywietlony zostanie błd: Parse error: parse error in bogus.inc on line 12. Dociekliwy uytkownik moe spróbowa obejrze plik bogus.inc wpisujc odpowiedni URL w pasku adresu. Jeeli serwer WWW jest skonfigurowany tak, aby traktowa pliki.inc jako tekst (tak jak mój), cały tekst pliku pojawi si w przegldarce. Jeeli serwer WWW jest tak skonfigurowany, aby traktowa pliki.inc jak kady inny skrypt PHP, uytkownik zobaczy jedynie wczeniej wspomniany komunikat błdu. Podsumowujc. W trakcie tworzenia aplikacji PHP moesz uy dowolnego rozszerzenia, ale aby unikn potencjalnego zagroenia bezpieczestwa naley tak skonfigurowa serwer WWW, aby analizował wszystkie pliki posiadajce uywane przez ciebie rozszerzenia. 6 Zmienne globalne Naley zrezygnowa z rejestrowania danych otrzymywanych od klienta jako zmiennych globalnych. W tym celu naley ustawi opcj register_globals=off. Mona tego dokona na kilka sposobów: a) globalnie dla wszystkich skryptów, poprzez plik php.ini dodajc lini register_globals=off b) dla danej domeny, modyfikujc plik httpd.conf np. w <VirtualHost...></VirtualHost> php_admin_value register_globals 0 c) dla poszczególnych katalogów/podkatalogów, poprzez zmian wpisu w.htaccess php_flag register_globals 0 Wyłczenie register_globals eliminuje wiele popularnych ataków na aplikacje napisane w PHP. Poniej przedstawiono przykład wykorzystania słaboci register_globals=on, w przypadku, gdy hasło od uytkownika sprawdzane jest za pomoc nastpujcego kodu: if ($password == '12345') $auth=1;... if ($auth==1) print 'tajny kod'; Wystarczy teraz wywoła skrypt z parametrem $auth=1, eby otrzyma 'tajny kod': Jeli nie jest moliwe ustawienie opcji register_globals=off (np. gdy program z t opcj przestaje działa), to powinnimy zawsze definiowa wartoci dla zmiennych nie

10 przekazywanych przez uytkownika. Dla poprzedniego przykładu moe to by zrealizowane poprzez nastpujc modyfikacj kod: $auth=0; if ($password == '12345') $auth=1;... if ($auth==1) print 'tajny kod'; 7 Sesje W poprzednim rozdziale mówilimy, e nigdy nie powinno si ufa informacjom od klienta. Niestety, powoduje to sytuacj, gdy wiksza cz kodu zajmuje si wielokrotnym badaniem otrzymywanych danych (bo s one zapisywane u klienta, czy to jako ciasteczka, czy te w postaci ukrytych pól formularza). Na szczcie od czwartej wersji PHP mamy inny sposób zapewnienia sobie bezpieczestwa - s to sesje, czyli moliwo zapisania pewnych informacji po stronie serwera. Dziki temu po jednorazowym sprawdzeniu poprawnoci informacji przechowujemy je u siebie, a do klienta wysyła si tylko unikalny identyfikator sesji. Rozwizanie to ma jeszcze inne plusy - na przykład znaczne zmniejszenie ruchu na łczach komunikacyjnych. Jak kada technologia, równie sesje nios ze sob kolejne zagroenia bezpieczestwa. Jeeli identyfikuje si klienta jedynie po numerze sesji, to haker moe próbowa generowa takie numery i na podstawie reakcji systemu sprawdza, czy trafił na aktywn sesj. Nie jest to wcale trudne na popularnych serwerach, gdzie jest naraz kilka tysicy otwartych sesji; tym bardziej, e sesje nie zostaj usuwane od razu po zamkniciu przegldarki - kasowaniem ich zajmuje si specjalny algorytm probablilistyczny. Innym sposobem na nieumylne włamanie si do czyjej sesji moe by dodanie do zakładek URL-a z dołczonym identyfikatorem sesji (moliwe przy propagacji tych numerków przez adresy). Wtedy po jakim czasie, po wejciu do sklepu internetowego mona zobaczy, e w koszyku mamy jakie dziwne zakupy, albo nawet dokona zamówienia na czyje konto. Jak zapobiega takim sytuacjom? Najłatwiej jest zapisa w sesji dodatkow informacj identyfikujc klienta np. numer jego IP. Wtedy mona sprawdzi, czy to on otworzył sesj o danym numerze i jeeli nie wystpuje zgodno wygenerowa now sesj do obsługi tego klienta. Czasami jednak i to nie wystarczy. Łatwo wyobrazi sobie sytuacj, gdy pewna gra stała si popularna wród osób z jednej sieci osiedlowej stojcej za maskarad. Dla serwera wszyscy ci gracze maj ten sam IP i niestety moe si zdarzy pomylenie sesji. Aby zapobiec takiej moliwoci mona doda do ciasteczka jeszcze jedn informacj -jak losowo wygenerowan liczb, któr zapisujemy równie w sesji. W tym wypadku sprawdzamy nie tylko zgodno IP, ale te czy oba numerki (z sesji i ciasteczka) s sobie równe. W ten sposób niemal całkowicie wykluczamy tego rodzaju błdy. Oczywicie metoda zawodzi, gdy kto ze wspomnianej sieci osiedlowej umylnie chce si poda za innego gracza - wystarczy wtedy podsłucha jaki numerek ma dana osoba i wysła odpowiednio spreparowane ciasteczko. 8 Upload plików Jedn z ciekawszych i bardziej niebezpiecznych cech PHP jest moliwo uploadu plików na serwer (np. własnych plików mp3, czy te zdj do opisujcych licytowany przedmiot na aukcji). Zadziwiajce jest to, e pomimo i niewiele serwisów korzysta z tej funkcji,

11 to na wikszoci z nich nie jest ona wyłczona. Przy ładowaniu kadej ze stron mona podrzuci odpowiednio spreparowane nagłówki, by serwer zaczł przyjmowa dane od klienta. Na szczcie po zakoczeniu działania skryptu cignite pliki zostaj usunite i nie zajmuj miejsca na dysku. W standardowej konfiguracji serwera jest te załoone ograniczenie wielkoci pliku, który moe zosta załadowany - domylnie s to dwa megabajty. Pozostawienie moliwoci zapisywania plików moe zosta uyte do przeprowadzenia ataku typu Denial Of Service. Wielokrotne i bardzo czste odczyty strony powoduj, e serwer staje si mocno obciony, ale pozostawiaj te widoczne lady w logach. Jeeli za zaczniemy wysyła na serwer bardzo długie pliki (albo te, gdy bdziemy je powoli sczy), to kilkanacie takich procesów potrafi dokładnie zablokowa serwer, a lad bdzie trudniejszy do wytropienia-w logach wida tylko jedno połczenie typu POST. Najlepiej, gdy dana strona ma w sobie formularz - wtedy unika si wszelkich podejrze. Jeeli dopuszcza si dostarczanie jakichkolwiek danych do aplikacji, naley bra pod uwag kad ewentualno. Jeeli zezwala si na przesyłanie plików to trzeba mie pewno, e pliki te zostan właciwie obsłuone na serwerze. Na przykład, jeeli tworzymy witryn do której programici mog przesyła własne skrypty nie naley pozwala na wykonywanie tych skryptów na serwerze. Mona je jedynie odebra i wywietli w postaci czystego tekstu i nie mona zakłada, e mona je bezpiecznie uruchomi. Nawet pozwolenie na wywietlenie przesłanych plików niesie ze sob potencjalne zagroenie. 9 Ataki typu XSS Ataki typu cross site scripting polegaj na przemyceniu kodu JavaScript lub VBScript do przegldarki uytkownika, odwiedzajcego dana stron. Pozwala to na ujawnienie danych zapisanych w ciasteczkach, co w wielu przypadkach umoliwia podszywanie si pod zarejestrowanego i zalogowanego uytkownika. Kod złego skryptu moe by przekazany np. przez forum na stronie, czy w postaci URLa wysłanego do uytkownika. Zapobieganie polega na filtrowaniu zmiennych przekazywanych przez uytkownika do kadego skryptu, tak aby niemoliwe było przesłanie jakiegokolwiek kodu HTML.W PHP jest to moliwe za pomoc funkcji strip_tags(). Oto przykład podatnego skryptu PHP: echo $zmienna; oraz sposób wykorzystania: test );</script> Po wywołaniu powyszego odnonika, przegldarka uytkownika wykona załczony fragment kodu JavaScript, co spowoduje otwarcie okienka z napisem test. Poprawiony fragment kodu powinien wyglda nastpujco: echo strip_tags($zmienna); 10 Ataki typu SQL injection Dotycz one aplikacji korzystajcych z baz danych i przyjmujcych dane wejciowe od uytkownika. Polegaj na moliwoci przemycenia czci zapytania SQL jako argumentu do innego zapytania SQL. Pozwalaj na ujawnienie danych z bazy, nadpisanie danych, czasami take na ich usuniecie, lub nawet na wywołanie polece systemowych. Wielu twórców serwisów jest niewiadomych tego typu zagroenia uznajc komendy SQL za bezpieczne.

12 Ataki tego typu s niebezpieczne ze wzgldu na moliwo manipulacji zapytaniami SQL, a w konsekwencji nieautoryzowanym dostpem do bazy. Zapobieganie polega na filtrowaniu przekazywanych przez uytkownika zmiennych, w PHP słuy do tego funkcja addslashes(), wstawiajca ukonik przed kady potencjalnie niebezpieczny znak. Oto przykład podatnego skryptu PHP: mysql query("select * FROM tabela WHERE id= $zmienna "); W powyszym przykładzie $zmienna dostarczana jest przez uytkownika z zewntrz. Moe on zastosowa ponisze zapytanie, aby spowodowa wywietlenie wszystkich rekordów z bazy: 1 OR 1; Poprawnie napisany fragment kodu powinien wyglda nastpujco: $zmienna_ok = addslashes($zmienna); mysql_query("select * FROM tabela WHERE id= $zmienna_ok "); Moemy wyobrazi sobie inny przykład skryptu, który przekazuje za pomoc adresu URL offset (w postaci liczbowej) wywietlanych wyników na stronie. Kod obsługujcy wybieranie danych z bazy mógłby wyglda nastpujco $offset = argv[0]; // uwaga: brak sprawdzenia poprawnoci danej $query = "SELECT id, name FROM products ORDER BY name LIMIT 20 OFFSET $offset;"; $result = mysql_query($query); Skrypt działa poprawnie, gdy utworzony wczeniej adres URL zawiera poprawn warto zmiennej $offset. Mona jednak wyobrazi sobie sytuacje, w której do skryptu przekazywana jest zmienna $offset, która zawiera nastpujc warto: 0; UPDATE user SET Password=PASSWORD('crack') WHERE user='root'; FLUSH PRIVILEGES; PHP udostpnia funkcje ułatwiajce obron przed opisanymi powyej atakami zwizane z modyfikacj zapyta SQL. Za pomoc funkcji addslashes() przekształcamy łacuch wejciowy w taki sposób, aby wszystkie niebezpieczne znaki mogce mie wpływ na działanie zapytania SQL, wystpujce w łacuchu zostały poprzedzone znakiem backslash (\). Wspomniane niebezpieczne znaki to: pojedynczy cudzysłów ('), podwójny cudzysłów ("), backslash (\), znak NULL. Przykład działania funkcji addslashes(): $str = "Is your name O'reilly?"; // Outputs: Is your name O\'reilly? echo addslashes($str);

13 Ponadto mona tak skonfigurowa PHP, aby wszystkie dane pochodzce od uytkownika były automatycznie poddawane działaniu funkcji addslashes(). Aby skonfigurowa PHP w ten sposób naley przypisa w pliku konfiguracyjnym PHP zmiennej magic_quotes_gpc warto on (taka warto jest przypisana domylnie). Podsumowujc zagroenia zwizane z obsług bazy danych za pomoc PHP mona wymieni czynnoci, zwikszajce bezpieczestwo skryptów: - łczenie z baz danych powinno odbywa si przez uytkownika, który dysponuje ograniczonymi prawami dostpu do bazy; nigdy nie powinien to by uytkownik root; - kade dane wejciowe powinny by poddane weryfikacji; PHP udostpnia wielu funkcji słucych do okrelania formatu danych, takich jak: is_numeric(), is_long(), ctype_digit() itp. Dostpne s równie funkcje wyrae regularnych; - jeli skrypt oczekuje na warto numeryczn, to naley sprawdzi otrzyman warto pod wzgldem jej poprawnoci (nawet jeli pochodzi ona z ukrytego pola formularza, pola combo itp.). Mona tego dokona poprzez sprawdzenie za pomoc funkcji is_numeric(), poprzez zmian typu zmiennej settype(), bd te uy do tworzenia zapytania SQL funkcji sprintf(), tak jak to przedstawiono poniej settype($offset, 'integer'); $query = "SELECT id, name FROM products ORDER BY name LIMIT 20 OFFSET $offset;"; // uyto w formacie %d; uycie %s jest bezzasadne $query = sprintf("select id, name FROM products ORDER BY name LIMIT 20 OFFSET %d;", $offset); - uywanie funkcji addslashes() do zmiennych uyskanych od uytkownika; - nie wywietlania adnych informacji mogcych ujawni struktur bazy danych. 11 Niebezpieczne funkcje i znaki Stosowanie niektórych funkcji w PHP z argumentami pobranymi od uytkownika moe spowodowa due zagroenie bezpieczestwa skryptu. Przykładami takich funkcji s: - system() uytkownik moe wywoła dowolna komend systemowa uywajc metaznaków powłoki (rednik, cudzysłowy); przykład: system("/sbin/ping $host"); uytkownik moe podłoy łacuch ;rm -rf /var/www; nie naley przekazywa niefiltrowanych zmiennych uytkownika do wntrza funkcji system(). - open() uytkownik moe otworzy lub zapisa dowolny plik, a take wykona dowolna komend systemowa (przy pomocy znaku ); przykład: open(fh "/home/venglin/$plik"); - uytkownik moe podłoy łacuch../../etc/passwd; nie naley przekazywa niefiltrowanych zmiennych uytkownika do wntrza funkcji open(). - eval() uytkownik moe wykona dowolny fragment kodu w PHP; nie naley przekazywa niefiltrowanych zmiennych uytkownika do wntrza konstrukcji eval(). Moliwo obrony przed tego typu atakami jest ułatwiona ze wzgldu na obecno gotowych funkcji realizujcych typowe operacje na niebezpiecznych łacuchach: addslashes() dodaje odwrotny ukonik przed znakami cudzysłowów, odwrotnego ukonika i znaku NULL; escapeshellcmd() niweluje działanie wszystkich metaznaków powłoki.

14 12 SSL Pierwszorzdn kwesti przy tworzeniu aplikacji przeznaczonych do handlu elektronicznego jest zagadnienie bezpieczestwa. Ju w czasie projektowania aplikacji naley mie na uwadze ochron danych o klientach. Naley wykona kilka kroków w celu zapewnienia moliwie najwyszego poziomu bezpieczestwa. Nie naley tego traktowa jako propozycji, s to zazwyczaj wymagania wikszoci centrów rozliczajcych karty kredytowe. Pierwszym krokiem powinno by wyodrbnienie fragmentów witryny, które wymagaj zastosowania bezpiecznego połczenia za pomoc mechanizmu secure socket layer (SSL). Wikszo aplikacji posiada dwa obszary działania. Pierwszy jest obszarem zawierajcym opisy dostpnych produktów i usług oferowanych na witrynie. W czci tej zawieraj si zwykle strony zawierajce dane o firmie, regulaminy i inne dane nie zwizane bezporednio z handlem. Drugi fragment zawiera aplikacj handlow. W czci tej zbierane s prywatne dane, takie jak dane niezbdne do identyfikacji klienta lub numery kart kredytowych. Uycie PHP z SSL nie róni si niczym do uywania PHP na serwerze nie obsługujcym SSL. 13 Bezpieczny tryb pracy PHP Dua ilo zagroe wystpujcych w PHP moe zosta zniwelowana poprzez włczenie trybu safe mode. Korzystanie z bezpiecznego trybu pracy PHP (safe mode) jest zalecane zawsze, jeli jest to tylko moliwe. W szczególnoci w rodowisku multihostingowym. Najwaniejsz cech safe mode jest nie zezwalanie na dostp plików, których włacicielem jest inny uytkownik, ni właciciel wykonywanego skryptu. Zabezpiecza to nas przed odczytaniem np. pliku /etc/passwd z poziomu WWW naszego uytkownika/klienta. Poza tym safe mode posiada wiele mechanizmów zwikszajcych bezpieczestwo naszych skryptów. Tryb ten pozwala na nastpujce ograniczenia: - sprawdzanie właciciela pliku przy jego otwieraniu; - odmawianie wykonania funkcji z rodziny system(); - odmawianie zmian zmiennych rodowiskowych; - ograniczenie dostpu do plików tylko z wybranego katalogu; - wyłczenie wybranych funkcji. Poniej przedstawiono cz moliwych opcji safe_mode oraz inne wane opcje PHP zwizane z bezpieczestwem: Nazwa Domylna warto Przykładowa warto safe_mode safe_mode_gid safe_mode_include_dir safe_mode_exec_dir safe_mode_allowed_env_vars "0" "0" NULL "" PHP_ 1 1 /home/przyklad.com /home/przyklad.com/bin PHP_, SSL_ safe_mode_protected_env_vars LD_LIBRARY_PATH PATH, LD_LIBRARY_PATH open_basedir disable_functions disable_classes NULL "" "" /home/przyklad.com system, fopen DBClass Opcji safe_mode nie mona ustawi na poziomie katalogów w pliku.htaccess, ale mona je ustawi w pliku php.ini, lub, jeli chcemy ograniczy działanie do poszczególnych domen i katalogów, w httpd.conf.

15 Oprócz opcji safe_mode bardzo przydatna jest opcja open_basedir. Pozwala ona na ogranicznie dostpu do plików do okrelonego katalogu. Np. jeli wstawimy: open_basedir=/home/przyklad.com to nie bdziemy mogli odczyta plików lecych powyej tego katalogu np. /home/test/skrypt.php, /etc/passwd Jeli w systemie mamy włczon opcj open_basedir i safe_mode, to w pierwszej kolejnoci sprawdzane s zabezpieczenia open_basedir, a nastpnie safe_mode (dotyczy np. dostpu do plików). Jeli nie moemy stosowa safe_mode i open_basedir razem, to w pierwszej kolejnoci powinnimy próbowa ustawi safe_mode, w ostatecznoci uywamy samego open_basedir (jeli włczenie safe_mode nie jest moliwe). Poniej przedstawiony został przykład próby odczytania pliku /etc/passwd z poziomu skryptu działajcego w trybie safe_mode i open_basedir Pliki: -rw-rw-r-- 1 rasmus rasmus 33 Jul 1 19:20 scrypt.php -rw-r--r-- 1 root root 1116 May 26 18:01 /etc/passwd plik skrypt.php uruchomiony w trybie safe_mode i open_basedir <? readfile('/etc/passwd'); Komunikat na stronie (safe_mode=1): Warning: SAFE MODE Restriction in effect. The script whose uid is 500 is not allowed to access /etc/passwd owned by uid 0 in /docroot/scrypt.php... Komunikat na stronie (open_basedir=/home/www/test): Warning: readfile(): open_basedir restriction in effect. File(/etc/passwd) is not within the allowed path(s):(/home/www/test) Ukrywanie błdów Wspomniano wczeniej, e jedn z metod na rozgryzienie skryptu jest wpisywanie niecodziennych danych do formularzy. Wszystko to w nadziei na uzyskanie informacji o błdzie od PHP - na przykład o niezgodnoci typu danych. Majc takie informacje mona próbowa dalej łama kod programu. Aby zabezpieczy si przed tak technik naley wyłczy wywietlanie komunikatów o błdach. Mona to ustawi w php.ini, ale chyba łatwiej (i wygodniej) jest ustawi warto za pomoc funkcji error_reporting na samym pocztku skryptu. Jej jedynym parametrem jest dany poziom informowania o wykrytych błdach. Standardowo jest to (E_ALL ^ E_NOTICE) czyli wywietlone zostan wszystkie komunikaty, które nie maj statusu NOTICE. W domu, na bezpiecznym serwerze, na którym tworzymy nasze skrypty warto mie t warto ustawion na E_ALL. Na komputerze zdalnym lepiej włczy error_reporting(0) -czyli całkowicie wyłczy informacje o błdach. Nie chcemy przecie ułatwia ycia hakerom (szczególnie takim, którzy umiej bawi si formularzami i ich wartociami). Inn, czsto stosowan metod, jest uzalenienie pokazywania błdów od jakich zmiennych - np. $debug, czy podobnych. Hakerzy mog próbowa wykorzysta wbudowany kod do debugowania, np. za pomoc nastpujcego URL-a:

16 index.php?debug=l&show_errors=l&errors=l&at_home=l&show_source=l&zmienna=zl a_wartosc W ten sposób czsto udaje si otrzyma duo informacji o skrypcie (szczególnie, gdy autor zastosował jeszcze polecenia typu show_source() czy highlight_file()). Naley pamita, by usuwa wszelkie mechanizmy debugowania z działajcego kodu - zamiast tego powinno si logowa wszelkie informacje niezbdne do odtworzenia błdu na swoim serwerze. 15 Ukrywanie PHP PHP, jak kady program, zawiera róne błdy, z których cz moe zosta uyta w destruktywnych celach. Nie zawsze ukazuj si łaty na takie pomyłki programistów, a czsto przed poprawk s ju dostpne exploity, które potrafi je wykorzysta. Z tego powodu czsto próbuje si ukry fakt korzystania z PHP na serwerze. W tym celu naley wyłczy dołczanie informacji o PHP i jego wersji do sygnatury serwera. Odpowiada za to dyrektywa expose_php w pliku php.ini. Jeeli jest ona włczona (domylnie), to do strony doklejany jest nastpujcy nagłówek: X-Powered_By: PHP/4.2.3 Wystarczy teraz poszuka jakiego exploita na t wersj PHP i włamanie gotowe. Kolejnym krokiem jest pozbycie si rozszerze typu.php. W tym celu w konfiguracji Apache'a piszemy: AddType application/x-httpd-php.htm.html Od tej pory wszystkie pliki.htm i.html bd parsowane przez PHP. Powoduje to oczywicie spadek szybkoci działania i zwiksza obcienie serwera, ale nie jest to dua rónica (ostatnio i tak znaczca wikszo stron generowana jest dynamicznie). Oczywicie nikt nie da si nabra na tego typu proste działania - wiadomo, e dynamiczne strony musz by przygotowywane w jaki sposób. Jednym z ciekawszych sposobów jest zmylenie ladów jest udawanie innego jzyka programowania, a najlepiej od razu innego systemu, serwera i jzyka skryptowego. Mona skonfigurowa serwer, na którym Debian udaje Windows NT, Apache podaje si za IIS, a PHP oczywicie symuluje ASP. Nawet tak daleko posunita ostrono zda si psu na bud, jeli nasze strony ASP bdzie obsługiwał choby PHP-Nuke, albo jaki inny szeroko znany i rozpoznawany system. Aby takie zdarzenia nie miały miejsca, warto korzysta z informacji dostpnych na domowej stronie php i przygotowa si zawczasu na ewentualne problemy. 16 Podsumowanie W przypadku bezpieczestwa systemu naley pamita, e kady łacuch jest tak mocny, jak jego najsłabsze ogniwo. Na nic si nie zda totalnie zabezpieczony Apache z dokładnie skonfigurowanym PHP i bezpiecznym skryptem, gdy na tym samym systemie zainstalowany bdzie te dziurawy sendmail czy te mod_ssl z błdami. Bezpieczestwo skryptów zaley wic nie tylko od autora stron, ale te od administratora systemu, który pilnowa musi aktualnoci oprogramowania (oraz informowa uytkowników o zmianach).