PHP. Bezpieczne programowanie 83-246-0425-1 [PDF]

Zitiervorschau

---

Przedmowa ..................................................................................................................... 5 O książce ......................................................................................................................... 7 1. Wprowadzenie .............................................................................................................. 11 Funkcje języka PHP Strategie Dobre praktyki

12 14 17

2. Formularze i adresy URL ............................................................................................... 25 Formularze i dane Ataki semantyczne na adresy URL Ataki związane z ładowaniem plików Ataki typu cross-site scripting Ataki typu CSRF Podrabiane zatwierdzenia formularza Sfałszowane żądania HTTP

25 28 30 33 34 38 39

3. Bazy danych i SQL .........................................................................................................43 Ujawnienie uwierzytelnień dostępu Wstrzykiwanie kodu SQL Ujawnienie danych przechowywanych w bazie

44 45 50

4. Sesje i cookie ..................................................................................................................51 Kradzież cookie Ujawnienie danych sesji Zafiksowanie sesji Przechwytywanie sesji

53 54 54 58

3

5. Pliki dołączane do programów .................................................................................... 61 Ujawnienie kodu źródłowego Adresy URL otwierające tylne drzwi Manipulowanie nazwą pliku Wstrzykiwanie kodu

61 63 63 65

6. Pliki i polecenia ............................................................................................................. 67 Trawersowanie katalogów Zagrożenia związane z plikami zdalnymi Wstrzykiwanie poleceń

67 69 71

7. Uwierzytelnianie i autoryzacja .................................................................................... 73 Łamanie zabezpieczeń metodą brutalnej siły Podsłuchiwanie haseł Ataki metodą powtórzenia Trwały login

74 77 78 79

8. Na wspólnym hoście .....................................................................................................85 Ujawnienie kodu źródłowego Ujawnienie danych sesji Wstrzykiwanie sesji Przeglądanie systemu plików Bezpieczny tryb języka PHP

85 88 91 93 94

A Dyrektywy konfiguracyjne ........................................................................................... 97 B Funkcje ......................................................................................................................... 103 C Kryptografia ................................................................................................................ 109 Skorowidz .................................................................................................................... 115

4

|

Spis treści

ROZDZIAŁ 3.

Bardzo często kod PHP wykorzystywany jest jako połączenie między różnymi źródłami danych a użytkownikiem. Prawdę powiedziawszy, niektórzy twierdzą, że język PHP jest raczej platformą programową niż zwykłym językiem programowania. Jest on na przykład bardzo często wykorzystywany do komunikacji z bazą danych. Język PHP jest dobrze przystosowany do tej roli głównie z uwagi na to, że potrafi się kontaktować z długą listą różnych baz danych. Oto tylko kilka najbardziej popularnych systemów baz danych, które język PHP obsługuje: DB2 InterBase MySQL

ODBC Oracle PostgreSQL

SQLite Sybase DBM

Tak jak jest w przypadku każdego zewnętrznego miejsca składowania danych, tak i bazy danych niosą ze sobą pewne ryzyko. Mimo iż w niniejszej książce nie zajmujemy się bezpieczeństwem baz danych, powinniśmy pamiętać, że pisząc aplikacje WWW, należy mieć na względzie problemy związane z bezpieczeństwem baz danych, w szczególności w sytuacjach, kiedy należy traktować dane otrzymywane z bazy danych jako dane zewnętrzne (dane wejściowe). Tak jak wspomniałem w rozdziale 1., wszelkie dane wejściowe powinny być filtrowane, a wszelkie dane zwracane (dane wyjściowe) powinny być opatrywane odpowiednimi znakami ucieczki. W odniesieniu do komunikacji z bazami danych będzie to oznaczać, że wszystkie dane nadchodzące z bazy danych muszą być filtrowane, a wszelkie dane wysyłane do bazy muszą być opatrzone znakami ucieczki. Jeden z typowych błędów polega na zapominaniu, że zapytanie SELECT również wysyła dane do bazy danych. Mimo iż jego zadaniem jest pobieranie danych, samo jednak zawiera dane wyjściowe wysyłane przez aplikacje.

Wielu programistów PHP zapomina o konieczności filtrowania danych nadchodzących z bazy danych, ponieważ w bazie przechowywane są zazwyczaj wyłącznie dane już przefiltrowane. Mimo iż ryzyko związane z tym zaniedbaniem nie jest duże, ja jednak zalecałbym, aby nie ułatwiać sobie w ten sposób życia. Podejście to bowiem pokłada zbyt wielkie zaufanie w bezpieczeństwie bazy danych, a ponadto łamie zasadę tworzenia w miarę możliwości dodatkowych zabezpieczeń. Należy pamiętać, że wprowadzanie takich dodatkowych zabezpieczeń

43

wzmacnia ogólne bezpieczeństwo aplikacji i komunikacja z bazą danych jest znakomitym przykładem korzyści płynących z zaimplementowania dodatkowych mechanizmów ochronnych. Jeśli komuś uda się w jakiś sposób wprowadzić do bazy danych niebezpieczne dane, to odpowiedni mechanizm filtrowania danych w aplikacji je wyłapie, pod warunkiem oczywiście, że będzie istniał. W niniejszym rozdziale przyjrzymy się paru problemom związanym z bezpieczeństwem komunikacji z bazami danych, między innymi ujawnieniu uwierzytelnień dostępu czy wstrzykiwaniu kodu SQL. Szczególną uwagę należy zwrócić właśnie na wstrzykiwanie kodu SQL z uwagi na to, że często wykrywa się w popularnych aplikacjach PHP podatność na takie ataki.

Ujawnienie uwierzytelnień dostępu Jednym z ważnych problemów związanych z korzystaniem z baz danych jest niebezpieczeństwo ujawnienia uwierzytelnień umożliwiających dostęp do bazy danych — czyli nazwy użytkownika i hasła. Często są one dla wygody zachowywane w pliku takim jak db.inc:

Zarówno nazwa użytkownika myuser, jak i hasło mypass są szczególnie ważne dla bezpieczeństwa bazy danych i aplikacji, dlatego też należy zwrócić na nie szczególną uwagę. Umieszczanie ich w kodzie źródłowym wiąże się z pewnym ryzykiem, którego jednak raczej nie da się uniknąć. Bez nich nasza baza danych nie mogłaby być chroniona za pomocą nazwy użytkownika i hasła. Jeśli przyjrzymy się plikowi httpd.conf (standardowemu plikowi konfiguracyjnemu serwera WWW Apache), przekonamy się, że domyślny typ zawartości zdefiniowany został tam jako text/plain. Ustawienie takie jest szczególnie niebezpieczne, gdy plik z hasłami, taki jak db.inc, jest przechowywany w katalogu dokumentów WWW. Każdemu dokumentowi przechowywanemu w katalogu dokumentów WWW przypisany zostaje bowiem odpowiedni adres URL i ponieważ serwer Apache nie określa zazwyczaj specjalnego typu zawartości dla plików .inc, więc każde żądanie tego rodzaju zasobu zwróci plik z hasłami w postaci zwykłego pliku tekstowego (domyślny typ zawartości). W ten sposób żądający bez trudu uzyska dostęp do uwierzytelnień dostępu bazy danych. Aby lepiej wyjaśnić zagrożenia związane z taką sytuacją, załóżmy, że mamy serwer WWW, w którym dokumenty przechowywane są w katalogu /www. Jeśli plik db.inc będzie przechowywany w podkatalogu www/inc, to otrzyma własny adres URL — http://example.org/inc/dbinc (zakładając, że adres internetowy hosta serwera WWW to example.org). Zaglądając pod ten adres URL, użytkownik będzie mógł obejrzeć kod źródłowy pliku db.inc w postaci zwykłego tekstu (jak to określa domyślny typ zawartości). Dlatego też, jeśli plik db.inc przechowywany jest w którymkolwiek z podkatalogów katalogu dokumentów /www, zawsze istnieje ryzyko ujawnienia uwierzytelnień dostępu osobom niepowołanym.

44

|

Rozdział 3. Bazy danych i SQL

Najlepszym rozwiązaniem tego problemu jest przechowywanie plików załączanych (z rozszerzeniem .inc od ang. includes) poza katalogiem dokumentów WWW. Aby korzystać z nich za pomocą dyrektyw include czy require, nie trzeba ich umieszczać w żadnym ściśle określonym katalogu w systemie plików — można umieścić je w dowolnym miejscu, trzeba tylko zadbać, by serwer WWW miał uprawnienia do odczytywania plików przechowywanych w tym katalogu. Jak więc widać, umieszczanie ich w katalogu dokumentów WWW wiąże się jedynie z niepotrzebnym ryzykiem, a każda metoda, która będzie próbować zmniejszyć to ryzyko, nie przenosząc ich jednak poza katalog dokumentów WWW, będzie tylko półśrodkiem. Generalnie w katalogu dokumentów WWW należy umieszczać wyłącznie te pliki i zasoby, które koniecznie muszą być dostępne po podaniu odpowiedniego adresu URL. W końcu jest to katalog dostępny publicznie dla wszystkich użytkowników internetu. Rada ta odnosi się również do baz SQLite. Bardzo wygodnym rozwiązaniem jest umieszczenie bazy danych w bieżącym katalogu, dzięki czemu można się do niej odwoływać, podając tylko nazwę, a nie całą ścieżkę do katalogu bazy danych. Niemniej w ten sposób umieszczamy bazę danych w katalogu dokumentów WWW i narażamy na niepotrzebne ryzyko. Baza taka może zostać skompromitowana za pomocą prostego żądania HTTP, o ile nie przedsięweźmiemy odpowiednich kroków, aby ją dodatkowo zabezpieczyć przed możliwością bezpośredniego dostępu z zewnątrz. Najbardziej polecanym rozwiązaniem pozostaje jednak umieszczenie bazy danych poza drzewem dokumentów WWW.

Jeśli z powodu jakichś czynników zewnętrznych nie będziemy mogli skorzystać z optymalnego rozwiązania polegającego na umieszczeniu wszystkich załączanych plików poza katalogiem dokumentów WWW, można zawsze skonfigurować serwer Apache, tak aby odrzucał żądania HTTP o pliki .inc:

Order allow,deny Deny from all

W rozdziale 8. opisuję metodę chronienia uwierzytelnień dostępu bazy danych szczególnie efektywną w środowiskach, gdzie na tym samym hoście działają różne programy (w takim przypadku pliki znajdujące się poza katalogiem WWW nadal narażone są ryzyko ujawnienia).

Wstrzykiwanie kodu SQL Podatność na technikę ataku zwaną wstrzykiwaniem kodu SQL (ang. SQL injection) jest jedną z najczęstszych słabości aplikacji PHP. Jest to szczególnie zadziwiające, jako że ataki tego typu możliwe są tylko wtedy, gdy programista popełni od razu dwa poważne błędy — zapomni o filtrowaniu danych nadchodzących do aplikacji z zewnątrz (danych wejściowych) i jednocześnie zapomni o konieczności opatrywania znakami ucieczki danych wysyłanych do aplikacji (danych wyjściowych). Nie powinno się zapominać o żadnym z tych dwu podstawowych zabiegów, a tylko stosowanie obu technik jednocześnie daje gwarancję poważnego ograniczenia błędów.

Wstrzykiwanie kodu SQL

|

45

Wykorzystanie techniki wstrzykiwania kodu SQL zazwyczaj wymaga ze strony atakującego odrobiny zgadywania i pewnego eksperymentowania — musi odgadnąć, jak wygląda schemat naszej bazy danych (zakładając oczywiście, że nie udało mu się zdobyć dostępu do naszego kodu źródłowego lub schematu bazy danych). Rozważmy następujący prosty formularz logowania:

Nazwa użytkownika:

Hasło:

Rysunek 3.1 pokazuje, jak formularz ten będzie wyglądać w oknie przeglądarki.

Rysunek 3.1. Prosty formularz logowania wyświetlony w oknie przeglądarki

Haker, który zobaczy taki formularz, będzie mógł spróbować zgadnąć, za pomocą jakiego zapytania sprawdzamy wpisywaną nazwę użytkownika i hasło. Przeglądając kod źródłowy HTML, atakujący może spróbować zgadywać, jakie stosujemy konwencje nazewnicze. Typowe założenie hakera będzie takie, że nazwy używane w formularzu powinny odpowiadać nazwom kolumn w tabelach bazy danych. Oczywiście samo tylko stosowanie różnych nazw w obu przypadkach nie jest wystarczającym zabezpieczeniem. Na podstawie tego formularza można z dużym prawdopodobieństwem zgadywać, że zapytanie wysyłane przez aplikację do bazy danych będzie miało następującą postać (i tak jest w istocie w moim przykładzie):

Oczywiście atakujący nie musi poprawnie odgadnąć schematu bazy danych już za pierwszym razem. Prawie zawsze musi najpierw przeprowadzić parę eksperymentów. Dobrym przykładem takiego eksperymentu jest przesłanie aplikacji pojedynczego cudzysłowu jako nazwy użytkownika, ponieważ w ten sposób haker może zdobyć kilka istotnych informacji. Wielu programistów, obsługując błędy pojawiające się w trakcie wykonywania zapytań skierowanych do baz danych, korzysta z odpowiednich funkcji takich jak mysql_error(). Tutaj pokazuję przykład takiego podejścia:

Jednak rozwiązanie takie, choć bardzo pomocne podczas programowania, jeśli pozostawimy je w gotowej aplikacji, może zdradzić atakującemu bardzo istotne informacje. Jeśli haker prześle jako nazwę użytkownika pojedynczy cudzysłów, a jako hasło mypass, zapytanie wysłane przez aplikację przyjmie następującą postać: