Chris Shiflett php. bezpieczne programowanie pełna wersja.pdf

Pliki dołączane do programów .................................................................................... 61

Ujawnienie kodu źródłowego

Adresy URL otwierające tylne drzwi

Manipulowanie nazwą pliku

Wstrzykiwanie kodu

Pliki i polecenia ............................................................................................................. 67

Trawersowanie katalogów

Zagrożenia związane z plikami zdalnymi

Wstrzykiwanie poleceń

Uwierzytelnianie i autoryzacja .................................................................................... 73

Łamanie zabezpieczeń metodą brutalnej siły

Podsłuchiwanie haseł

Ataki metodą powtórzenia

Trwały login

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

A Dyrektywy konfiguracyjne ........................................................................................... 97

B Funkcje ......................................................................................................................... 103

Kryptografia ................................................................................................................ 109

Skorowidz .................................................................................................................... 115

Spis treści

ROZDZIAŁ 3.

Bardzo często kod PHP wykorzystywany jest jako połączenie między różnymi źródłami da-

nych 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ę kon-

taktować 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

ODBC

SQLite

InterBase

Oracle

Sybase

MySQL

PostgreSQL

DBM

Tak jak jest w przypadku każdego zewnętrznego miejsca składowania danych, tak i bazy da-

nych 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 wszel-

kie 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 nad-

chodzą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 ba-

zy danych, ponieważ w bazie przechowywane są zazwyczaj wyłącznie dane już przefiltro-

wane. 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 do-

datkowych zabezpieczeń. Należy pamiętać, że wprowadzanie takich dodatkowych zabezpieczeń

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 ochron-

nych. 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 wstrzy-

kiwaniu 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:

<?php

$db_user = 'myuser';

$db_pass = 'mypass';

$db_host = '127.0.0.1';

$db = mysql_connect($db_host, $db_user, $db_pass);

Zarówno nazwa użytkownika myuser , jak i hasło mypass są szczególnie ważne dla bezpie-

czeństwa bazy danych i aplikacji, dlatego też należy zwrócić na nie szczególną uwagę. Umiesz-

czanie 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żyt-

kownika 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 prze-

chowywanemu w katalogu dokumentów WWW przypisany zostaje bowiem odpowiedni adres

URL i ponieważ serwer Apache nie określa zazwyczaj specjalnego typu zawartości dla pli-

kó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 do-

stę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 przecho-

wywany 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.

Rozdział 3. Bazy danych i SQL

Najlepszym rozwiązaniem tego problemu jest przechowywanie plików załączanych (z roz-

szerzeniem .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ółśrod-

kiem. Generalnie w katalogu dokumentów WWW należy umieszczać wyłącznie te pliki i za-

soby, 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ą pro-

stego żądania HTTP, o ile nie przedsięweźmiemy odpowiednich kroków, aby ją do-

datkowo zabezpieczyć przed możliwością bezpośredniego dostępu z zewnątrz. Naj-

bardziej 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 optymal-

nego rozwiązania polegającego na umieszczeniu wszystkich załączanych plików poza kata-

logiem dokumentów WWW, można zawsze skonfigurować serwer Apache, tak aby odrzucał

żądania HTTP o pliki .inc:

Order allow,deny

Deny from all

</Files>

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 jed-

ną 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 — za-

pomni 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 podsta-

wowych zabiegów, a tylko stosowanie obu technik jednocześnie daje gwarancję poważnego

ograniczenia błędów.

Wstrzykiwanie kodu SQL

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika: