PHP5. Bezpieczne programowanie. Leksykon kieszonkowy

PHP5. Bezpieczne
programowanie.
Leksykon kieszonkowy
Autor: Jacek Ross
ISBN: 83-246-0635-1
Format: 115x170, stron: 160

Twórz bezpieczny kod w PHP!
• Jakie rodzaje ataków mog¹ Ci zagroziæ?
• Jak siê przed nimi broniæ?
• Jak produkowaæ bezpieczne oprogramowanie?
PHP jest z pewnoœci¹ jednym z najbardziej popularnych jêzyków programowania,
pozwalaj¹cych na tworzenie dynamicznych aplikacji WWW. Swoj¹ popularnoœæ zdoby³
dziêki prostej sk³adni, ³atwej konfiguracji oraz przejrzystym zasadom dzia³ania.
PHP jest œwietnym przyk³adem na to, ¿e prostota i elegancja bywaj¹ lepsze ni¿
nadmierne zaawansowanie i niepotrzebna komplikacja. Pomimo swej prostoty jêzyk
PHP jest bardzo wymagaj¹cy w sprawach zwi¹zanych z bezpieczeñstwem. Zmusza on
programistê do poœwiêcenia niezwyk³ej uwagi kwestii wyboru bezpiecznych rozwi¹zañ.
Z pewnoœci¹ brakowa³o Ci ksi¹¿ki, która w jednym miejscu gromadzi³aby wszelkie
informacje zwi¹zane z bezpieczeñstwem w PHP. Dziêki pozycji „PHP5. Bezpieczne
programowanie. Leksykon kieszonkowy ” poznasz podstawy bezpiecznego
programowania, sposoby obs³ugi danych pobranych z zewn¹trz oraz przekazywania
ich pomiêdzy skryptami. Autor przedstawi Ci rodzaje ataków na aplikacje PHP
oraz najlepsze metody obrony przed nimi. Ponadto nauczysz siê we w³aœciwy sposób
konfigurowaæ PHP oraz zdobêdziesz wiedzê na temat zasad bezpiecznej produkcji
oprogramowania. Je¿eli chcesz tworzyæ bezpieczne rozwi¹zania w PHP, koniecznie
zapoznaj siê z t¹ ksi¹¿k¹!
• Obs³uga danych zewnêtrznych
• Wstrzykiwanie kodu
• Dobór odpowiednich uprawnieñ
• Sposoby uwierzytelniania u¿ytkownika
• Bezpieczne obs³ugiwanie b³êdów
• Rodzaje ataków na aplikacje napisane w PHP
• Obrona przed atakami XSS
• Zagro¿enie wstrzykniêciem kodu SQL
• Ataki DOS i DDOS
• Bezpieczna konfiguracja PHP
• Sposoby tworzenia bezpiecznego oprogramowania
Wykorzystaj mo¿liwoœci PHP w pe³ni i bezpiecznie!

Spis tre ci

1. Wstýp ............................................................................................5

2. Podstawy bezpiecznego programowania ....................................7
2.1. Obsäuga danych z zewnñtrz 7
2.2. Wstrzykiwanie kodu 9
2.3. Nadmiar uprawnieþ 10
2.4. Przekazywanie danych miödzy skryptami 12
2.5. Nieuprawnione u ycie skryptu 13
2.6. Uwierzytelnianie u ytkownika 18
2.7. U ycie niebezpiecznych instrukcji 23
2.8. Bezpieczna obsäuga bäödów 27
2.9. Bezpieczeþstwo systemu plików 30

3. Rodzaje ataków na aplikacje PHP ..............................................32
3.1. Atak siäowy na hasäo 32
3.2. Przechwycenie hasäa przez nieuprawnionñ osobö 34
3.3. Wäamanie na serwer bazy danych 34
3.4. Wäamanie na serwer PHP 38
3.5. Cross site scripting (XSS) 40
3.6. Wstrzykiwanie kodu SQL (SQL injection) 42
3.7. Wstrzykiwanie poleceþ systemowych (shell injection) 54
3.8. Wstrzykiwanie nagäówków HTTP
do wiadomo ci e-mail (e-mail injection) 56
3.9. Cross site request forgery (XSRF) 57
3.10. Przeglñdanie systemu plików (directory traversal) 61

3

3.11. Przejöcie kontroli nad sesjñ (session fixation) 62
3.12. Zatruwanie sesji (session poisoning) 68
3.13. HTTP response splitting 84
3.14. Wykrywanie robotów 84
3.15. Ataki typu DOS i DDOS 97
3.16. Cross site tracing 101
3.17. Bezpieczeþstwo plików cookie 101
3.18. Dziura w preg_match 102

4. Konfiguracja serwera PHP ........................................................ 105
4.1. Dyrektywa register_globals 105
4.2. Tryb bezpieczny (safe mode) 106
4.3. Ukrywanie PHP, dyrektywa expose_php 107

5. Metody produkcji bezpiecznego oprogramowania ................ 109
5.1. Architektura programu a bezpieczeþstwo 109
5.2. Ochrona przez ukrycie informacji
(security by obscurity) 111
5.3. Pozostawianie „tylnych wej è” i kodu tymczasowego 113
5.4. Aktualizowanie wersji PHP i u ywanych bibliotek 114
5.5. U ycie gotowych bibliotek i frameworków 115
5.6. Zaciemnianie kodu PHP 120
5.7. Kodowanie ródeä PHP 126
5.8. Psychologiczne aspekty
bezpieczeþstwa aplikacji sieciowych 127

6. Rozwój jýzyka PHP ................................................................... 138
6.1. Porównanie zmian wpäywajñcych na bezpieczeþstwo
w PHP5 w stosunku do wydania 4. 138
6.2. Kierunki rozwoju jözyka PHP w wersji 6. 139

S owniczek pojýë ...................................................................... 141

Skorowidz ..................................................................................151

4 _ Spis tre ci

5. Metody produkcji
bezpiecznego oprogramowania

5.1. Architektura programu a bezpiecze stwo
Architektura programu mo e mieè istotny wpäyw na poziom jego
bezpieczeþstwa. Nie ma zbyt wielu ogólnych reguä dotyczñcych
tego, jak prawidäowo powinna byè zaprojektowana aplikacja sie-
ciowa, wiele zale y bowiem od: u ytych technologii, przyjötej
metodologii projektowej, rozmiaru projektu i zespoäu, oprogra-
mowania u ywanego podczas tworzenia aplikacji, a tak e od
samego jej rodzaju i wszystkich szczegóäów jej dziaäania. Istnieje
jednak kilka zasad, o których powinien pamiötaè programista
i projektant:
x Prostota. Trawestujñc Einsteina, mo na by powiedzieè, e
kod powinien byè tak prosty, jak to mo liwe, ale nie bardziej.
W prostym, eleganckim i przejrzystym kodzie znajdzie siö
prawdopodobnie znacznie mniej bäödów ni w zawiäym,
peänym nadmiarowo ci i tricków programistycznych. Kod
krótszy nie zawsze jest prostszy i bardziej przejrzysty. Warto
czasem napisaè go wiöcej, lecz czytelniej — w sposób bar-
dziej zrozumiaäy. Mo e on zostaè potem äatwiej przeanali-
zowany przez innego programistö, który, je li znajdzie w nim
bäödy, bödzie mógä zasugerowaè poprawki. Jest to szczegól-
nie istotne przy programach typu open source.
x Kontrola jako ci. W przypadku adnej wiökszej aplikacji nie
jest dobrym rozwiñzaniem przerzucanie kontroli jako ci
na programistów czy u ytkowników. Bäödy wykryte przez
tych ostatnich sñ kosztowne w naprawie, pogarszajñ wize-
runek programu, a w przypadku gdy dotyczñ zabezpieczeþ,
mogñ stanowiè przyczynö du ej liczby udanych ataków na

5. Metody produkcji bezpiecznego oprogramowania _ 109

aplikacjö (nie ka dy u ytkownik zgäosi bäñd producentowi —
niektórzy mogñ postanowiè wykorzystaè go do wäasnych
celów). Programi ci z kolei nie sñ zazwyczaj w stanie wykryè
wielu nieprawidäowo ci ze wzglödu na brak obiektywizmu
wzglödem wäasnego kodu i problem z dostrze eniem tych
bäödów, które umknöäy ich uwadze na etapie implementacji.
Warto wiöc podzieliè testowanie na etapy, u ci liè jego pro-
cedury i scenariusze oraz skorzystaè z takich technik, jak
testy jednostkowe (tworzone przez programistów), automa-
tyczne, funkcjonalne (röczne), bezpieczeþstwa czy te testy
obciñ enia (które mogñ tak e mieè wpäyw na bezpieczeþstwo,
minimalizujñc ryzyko ataków typu DOS i DDOS).
x Skupienie kluczowych elementów aplikacji. Je li nasz pro-
gram mo e mieè nastöpujñce wywoäania: login.php?user
´=54, basket.php?what=add&pid=10, product.php?cat=17&
´prod=12 i details.php?uid=3&mode=1, to poprawne chro-
nienie go mo e staè siö sporym wyzwaniem. Dlaczego?
Poniewa istnieje wiele punktów wej cia do niego i ka dy
z nich musi zostaè niezale nie zabezpieczony. Wprawdzie
mo emy procedury zabezpieczeþ wydzieliè do osobnego
pliku czy klasy i wywoäywaè je w skryptach, lecz bödziemy
wtedy musieli pamiötaè o tym, aby robiè to prawidäowo
w ka dym z tych miejsc, a gdy dodamy nowy plik, jego
tak e bödziemy musieli zabezpieczyè. W dodatku ka dy
ze skryptów przyjmuje zupeänie inne parametry. W takim
gñszczu äatwo o bäñd, a jeden le zabezpieczony skrypt mo e
wystarczyè do tego, aby caäa aplikacja przestaäa byè bez-
pieczna. Lepiej zrobiè jeden punkt wej cia do aplikacji, ste-
rujñc jej przebiegiem poprzez parametr, i zminimalizowaè
liczbö pozostaäych parametrów. Powy sze odwoäania mogñ
przyjñè postaè: index.php?what=login&uid=54, index.php?
´what=basket_add&pid=10, index.php?what=product&cat=
´17&prod=12 i index.php?what=details&uid=3&mode=1.

110 _ PHP5. Bezpieczne programowanie. Leksykon kieszonkowy

x Zaprojektowanie rozmieszczenia elementów skäadowych
aplikacji, takich jak baza danych, system prezentacji itp.
Zastanówmy siö, na jakich maszynach bödñ one umiesz-
czone oraz jakie bödñ tego konsekwencje. Zaplanujmy te
rozmieszczenie plików na serwerze. Rozdzielmy koniecznie
ró ne warstwy i podsystemy aplikacji. Niech prezentacja
nie bödzie zmieszana z warstwñ logiki czy z danymi. Pla-
nujñc takie rzeczy, nie tylko unikniemy chaosu i uzyskamy
przejrzyste wewnötrznie oprogramowanie, ale te zwiök-
szymy poziom jego bezpieczeþstwa. Dla przykäadu, umiesz-
czenie skryptów w tym samym katalogu, w którym znajdujñ
siö dane przesyäane na serwer w wyniku akcji u ytkownika,
niesie ze sobñ potencjalne zagro enie.

5.2. Ochrona przez ukrycie informacji
(security by obscurity)
Nie mo emy liczyè na to, e u ytkownik nie wie, jak dziaäa nasz
skrypt, nie zna parametrów wywoäania, nazw pól formularzy
(w tym pól ukrytych), warto ci identyfikatorów itp. Tego typu
informacje sñ bardzo äatwe do odkrycia. Czösto wystarczy kilka-
na cie minut eksperymentów z dziaäajñcñ aplikacjñ, aby dowie-
dzieè siö wszystkiego, co jest potrzebne do ataku. W ostateczno ci
majñcy cierpliwo è wäamywacz dokona na te informacje ataku
siäowego, czyli zgadnie je metodñ prób i bäödów. Podobno pierw-
sze prawo Murphy’ego dotyczñce ochrony programów gäosi, e
ilo è czasu, jakñ wäamywacz mo e po wiöciè na äamanie zabez-
pieczeþ, jest zawsze dostatecznie du a i w razie potrzeby dñ y do
nieskoþczono ci. Stñd te wywoäanie typu index.php?o=sjka&
´i=8271&t=981&a=aabf1a, nawet je li trudno w to uwierzyè, nie
musi byè wynikiem pracy aplikacji, lecz mo e zostaè wprowa-
dzone do przeglñdarki celowo i niewykluczone, e w zäych inten-
cjach. Nawet je li ródäa programu sñ dobrze ukryte, to wäamywacz


mo e zgadnñè czy te w inny sposób odkryè, e przez wywoäanie
o=sjka przeprowadzamy zmianö hasäa administratora lub wyko-
nujemy innñ istotnñ funkcjö, a wtedy grozi nam katastrofa.
Nie chciaäbym zostaè le zrozumiany. Ukrywanie przed u ytkow-
nikiem informacji, które go nie dotyczñ, jest dobrñ praktykñ. Je li
algorytmy, bäödy wewnötrzne, parametry, u yte funkcje syste-
mowe itp. bödñ niedostöpne dla niepowoäanych oczu, to zmniej-
szy siö nieco ryzyko odkrycia przez wäamywacza dziur w zabez-
pieczeniach. W koþcu ka da dodatkowa ochrona jest dobra —
nawet taka. Jest to jednak zabezpieczenie säabe i lepiej, eby tych
dziur w kodzie nie byäo, ni eby my musieli polegaè na ich
dobrym maskowaniu. Szczególnie je li tworzymy oprogramowa-
nie typu open source, musimy byè pewni na 100%, e ten punkt
nas nie dotyczy. W otwartych ródäach nie ma sensu niczego ukry-
waè, kodowaè czy zaciemniaè. Bäödy takiego oprogramowania
prödzej czy pó niej i tak wyjdñ na jaw. Ka dy mo e swobodnie
analizowaè jego kod, a gdy jeden u ytkownik po wykryciu w nim
dziury wykorzysta tö wiedzö by nam zaszkodziè, to drugi prze le
nam informacjö o znalezionych nieprawidäowo ciach, aby my
mogli je naprawiè (a mo e nawet od razu dostarczy nam gotowñ
poprawkö). Przy otwartych ródäach rozsñdna jest wiöc strategia
zupeänie przeciwna ni security by obscurity: nale y pisaè pro-
gram jak najbardziej przejrzysty, czytelny i udokumentowany, tak
aby kod ródäowy byä doskonale zrozumiaäy nawet dla poczñt-
kujñcego programisty. Dziöki takiemu podej ciu wiöcej osób ma
szansö zapoznaè siö z nim i, co za tym idzie, istnieje wiöksza szansa
na to, e kto odkryje bäñd i podzieli siö tym z autorem. Warto
jednak pamiötaè, e nawet w przypadku publikacji ródeä jako
open source jawno è nie dotyczy konfiguracji serwera. Ukrycie
informacji o nim, o wersji zainstalowanego na nim oprogramo-
wania, komunikatów o bäödach czy innych tego typu istotnych
danych jest zawsze korzystne. Swobodny dostöp do nich prowo-
kuje bowiem wäamywaczy i zwiöksza szansö na udany atak.


5.3. Pozostawianie „tylnych wej ë”
i kodu tymczasowego
Programi ci do è czösto zostawiajñ w swoim kodzie rozmaite
„tylne wej cia”: funkcje diagnostyczne, narzödziowe, testowe, tym-
czasowe (te w informatyce majñ nieraz zaskakujñco däugie ycie)
i wiele innych fragmentów oprogramowania, które nie powinny
byè u ywane i udostöpniane publicznie. Najczö ciej liczñ na to,
e nikt nie zgadnie, gdzie znajduje siö takie „tylne wej cie” i jak
nale y go u yè. Wäamywacze dysponujñ jednak zazwyczaj du ñ
ilo ciñ czasu, a coraz czö ciej tak e du ymi zasobami finanso-
wymi (szczególnie ci dziaäajñcy na zlecenie grup przestöpczych)
i majñ wiele sposobów na odkrycie säabych punktów kodu:
x metody siäowe, czyli odgadniöcie dogodnego sposobu wäa-
mania lub wäamanie poprzez odgadniöcie hasäa czy innej
tajnej informacji;
x przekupienie pracowników firmy i zdobycie tñ drogñ in-
formacji;
x wäamanie do sieci firmowej lub na prywatne bñd säu bowe
komputery pracowników i odszukanie istotnych, a le zabez-
pieczonych informacji (wewnñtrz intranetów firmowych sñ
one zazwyczaj säabo chronione);
x wykorzystanie robotów do automatyzacji prób wäamaþ;
x wykorzystanie znanych dziur w bibliotekach u ywanych
przez oprogramowanie;
x rozpoznanie metod dziaäania programu poprzez analizö jego
zachowania.
Programi ci czösto dodajñ tylne wej cia do aplikacji po to, aby
uäatwiè sobie ich testowanie i nastöpujñce po nim usuwanie
bäödów. Tego typu dziaäanie wiadczy jednak o zäej organizacji


procesu produkcji oprogramowania, o braku przemy lanych pro-
cedur czy te o niewäa ciwym lub nieistniejñcym przepäywie zgäo-
szeþ nieprawidäowo ci. Warto przemy leè, czy opäaca siö i è na
skróty i zostawiaè otwartñ tylnñ furtkö, gdy po wiöca siö däugie
godziny na zabezpieczenie gäównych drzwi.

5.4. Aktualizowanie wersji PHP
i u ywanych bibliotek
Jednñ z czöstszych metod wäamaþ do aplikacji sieciowych jest
wykorzystanie istniejñcych dziur bñd to w oprogramowaniu ser-
wera lub interpretera, bñd to w samej konstrukcji jözyka. Wiele
starszych wersji PHP miaäo istotne luki, w tym zarówno takie,
które umo liwiaäy programi cie stworzenie zäego, niebezpiecznego
kodu, jak i takie, które same w sobie mogäy zostaè wykorzystane
przez wäamywacza. Kolejne wydania zawierajñ wiele poprawek
eliminujñcych mo liwo ci wykonywania takich ataków, dlatego
bardzo wa ne jest u ywanie jak najnowszej wersji jözyka. Je li
sam go nie aktualizujesz — sprawdzaj co pewien czas, czy robi to
administrator. Co prawda nie ma nigdy pewno ci, e aktualizacje
te nie wprowadzajñ nowych dziur (có , nikt nie jest doskonaäy,
twórcy PHP równie ), jednak korzystanie z najnowszej, stabilnej
wersji jözyka PHP zazwyczaj per saldo i tak siö opäaca.
x Dziury istniejñce w starszych wersjach sñ zazwyczaj dobrze
znane, a im wiöcej osób zna säabe punkty Twojego oprogra-
mowania, tym wiöksza jest szansa na skuteczny atak. Co
wiöcej: istniejñ specjalne programy, które aktywnie przeszu-
kujñ Internet pod kñtem stron dziaäajñcych na przestarza-
äych wersjach oprogramowania serwerowego i tym samym
podatnych na atak. Po znalezieniu takiej strony przesyäajñ
one raport do swojego wäa ciciela, który mo e tö informacjö
wykorzystaè do najró niejszych zäych celów. Dlatego mo na
uznaè za prawdziwe stwierdzenie, e im dziura w oprogra-


mowaniu jest starsza, tym gro niejsza (jej istnienie przynosi
te wiökszy wstyd wäa cicielowi oprogramowania, który
przez tak däugi okres czasu nie zdoäaä jej usunñè).
x Nowsze wersje PHP czösto eliminujñ niebezpieczne kon-
strukcje samego jözyka, które mogñ bardzo äatwo skutkowaè
wäamaniem. Co prawda ma to swoje wady: starsze programy
mogñ wymagaè, i czösto wymagajñ, zmian, lecz podjöty
wysiäek opäaca siö — otrzymamy w wyniku bezpieczniejszñ
aplikacjö. Niektóre funkcje sñ w nowych wydaniach ozna-
czane jako wycofywane (ang. deprecated). Rozumie siö przez
to, e mogñ one zostaè usuniöte w kolejnych wersjach opro-
gramowania. Warto wcze niej pomy leè o pozbyciu siö ich,
bo pó niej mo e byè na to mniej czasu, co zmusi nas do
niepotrzebnego po piechu i w efekcie do popeänienia bäö-
dów. Status deprecated posiada obecnie np. opcja konfigu-
racyjna register_global. Twórcy PHP planujñ usuniöcie jej
w wersji 6. Je li z niej korzystasz, wyeliminuj jñ ju teraz!
Pamiötaj, e od wie anie oprogramowania dotyczy tak e biblio-
tek i gotowego kodu, z którego korzystasz. Sprawdzaj regular-
nie, czy ich autor wykonaä aktualizacjö. Je li projekt jest martwy,
a autor (autorzy) nie poprawiajñ kodu, to nie masz wyj cia: albo
bödziesz regularnie przeglñdaä ródäa i wprowadzaä samodzielnie
poprawki, albo powiniene poszukaè innej biblioteki. Pozostawia-
nie w swoim programie przestarzaäego kodu jest zbyt niebez-
pieczne i grozi powa nymi konsekwencjami.

5.5. U ycie gotowych bibliotek i frameworków
U ywanie gotowych frameworków i bibliotek ma zarówno wady,
jak i zalety, w tym takie, które w znaczñcy sposób wpäywajñ na
bezpieczeþstwo aplikacji sieciowej. Programista powinien sam
rozwa yè, co jest dla niego bardziej opäacalne. Oto krótkie zesta-
wienie plusów i minusów korzystania z gotowego kodu z punktu


widzenia ochrony programu (pomijam wiöc kwestie takie jak
oszczödno è czasu, u ycie sprawdzonych standardów kodowa-
nia itp.).
ZA:
x Najpopularniejsze biblioteki zostaäy stworzone przez najlep-
szych programistów, majñcych du e do wiadczenie w pro-
gramowaniu w jözyku PHP, dziöki czemu prawdopodobieþ-
stwo, e zawierajñ istotne, grube bäödy, jest znacznie mniejsze
ni w przypadku wäasnoröcznie napisanego kodu. Nawet
je li jeste my geniuszami, to nie mamy pewno ci, e posia-
damy wszystkie informacje, które byäy znane autorom pod-
czas pisania bibliotek (np. zgäoszone przez u ytkowników
bäödy w starszych wersjach czy specjalistyczna dokumenta-
cja). Bez takiej wiedzy nawet najlepszy programista mo e
popeäniè bäñd.
x Popularny kod najczö ciej jest testowany przez tysiñce u yt-
kowników, wiöc istnieje spora szansa, e wiele bäödów,
które my mo emy dopiero popeäniè, zostaäo ju popeänio-
nych, zauwa onych i poprawionych. Szczególnie znaczñca
powinna byè informacja o istnieniu silnej i licznej spoäecz-
no ci skupionej wokóä oprogramowania. Je li wiele osób
u ywa biblioteki, dyskutuje o niej, zgäasza nieprawidäowo-
ci i przesyäa autorom poprawki lub modyfikacje, jest to
znak, e pojawienie siö ewentualnej dziury mo e zostaè
szybko zauwa one i natychmiast powstanie äatka za egnu-
jñca niebezpieczeþstwo. Bogata i aktywna spoäeczno è to
najczö ciej gwarancja czöstych aktualizacji i wysokiego
standardu.
x Wiele z bibliotek zostaäo sprawdzonych przez twórców PHP
i zaakceptowanych jako pewna podstawa. Niektóre z nich
w kolejnych wersjach jözyka stanowiñ standardowy moduä,


a ich stosowanie jest zalecane przez podröcznik u ytkownika
(http://php.net). Do takich bibliotek nale y mieè wiöksze zau-
fanie ni do kodu zewnötrznego i raczej nie powinni my
mieè oporów przed korzystaniem z nich. Przykäadem mo e
byè tu np. biblioteka PDO.
PRZECIW:
x Im popularniejsza biblioteka, tym wiöksza liczba potencjal-
nych wäamywaczy bödzie zaznajomiona z niñ i z jej dziu-
rami. W pierwszej kolejno ci próbujñ oni znale è metody
wäamaþ do typowego kodu, korzystajñcego z typowych
bibliotek, poniewa majñ najwiökszñ szansö na znalezienie
takich aplikacji w sieci. Oryginalny, napisany po raz pierw-
szy kod mo e ich zaskoczyè. Nie bödñ mogli zastosowaè
wyèwiczonych technik, lecz zostanñ zmuszeni do po wiö-
cenia sporej ilo ci czasu na jego badanie, co utrudni atak lub
nawet zniechöci ich.
x Programi ci to te ludzie i popeäniajñ oni bäödy. Przed u y-
ciem zewnötrznego frameworka czy biblioteki sprawd my,
kim sñ jej autorzy, jaka jest opinia rodowiska o nich, a tak e
o samej bibliotece. Zobaczmy, co twórcy piszñ o swoim
kodzie, czy majñ sprawny system obsäugi bäödów, czy wspie-
rajñ spoäeczno è u ytkowników swojego oprogramowania
(i czy taka spoäeczno è w ogóle istnieje), a tak e czy reagujñ
odpowiednio na doniesienia o bäödach i regularnie wypusz-
czajñ aktualizacje (a przynajmniej po zgäoszeniu nieprawi-
däowo ci). W miarö mo liwo ci przejrzyjmy chocia z grub-
sza kod i stosowane w nim konstrukcje. Sprawd my, czy
nie ma w nim najbardziej podejrzanych i alarmujñcych bäö-
dów oraz niebezpiecznych technik, takich jak np. korzysta-
nie z dyrektywy register_globals. Dowiedzmy siö te , na
jakiej wersji PHP siö on opiera. Je li biblioteka ma zostaè
u yta w jakim istotnym miejscu naszej aplikacji, nie bójmy


siö zadawaè pytaþ, gdy cokolwiek jest niejasne. Je li w ra ñcy
sposób nie przejdzie ona którego z powy szych testów —
odrzuèmy jñ.
x To, e kod jest dostöpny publicznie, mo e spowodowaè, e
wszystkie bäödy bödñ dla potencjalnego wäamywacza wi-
doczne jak na däoni. Wprawdzie dobry program powinien
byè napisany tak, aby jawno è ródeä nie byäa osäabieniem
jego bezpieczeþstwa, jednak w praktyce do è czösto tak nie
jest. Najpopularniejsze aplikacje PHP, takie jak: phpMyAdmin,
PHP-Nuke, phpBB, jPortal, myPHPCalendar, PHP-Ticket czy
PHP-Fusion, zawieraäy w przeszäo ci (a byè mo e zawierajñ
nadal i bödñ miaäy w przyszäo ci) istotne dziury. Niektóre
z nich nie otrzymaäy äat i poprawek przez do è däugi okres
czasu po opublikowaniu problemów, co niestety daäo szansö
wäamywaczom na przeprowadzenie wielu udanych wäamaþ,
a nawet na stworzenie wirusów, robaków i automatów prze-
czesujñcych sieè w ich poszukiwaniu.
Kiedy lepiej stosowaè gotowe biblioteki:
x Do wszelkich funkcji niskopoziomowych, bliskich systemowi,
a tak e takich jak komunikacja z bazñ danych i przez FTP
czy wysyäanie e-maili.
x Gdy biblioteki te zostaäy wäñczone do PHP jako oficjalne roz-
szerzenia (nale y u ywaè wszystkich takich bibliotek).
x Do implementacji skomplikowanych algorytmów wymaga-
jñcych du ej wiedzy algorytmicznej, matematycznej i (lub)
specjalistycznej z innej dziedziny nauki. Po co wywa aè
otwarte drzwi, ryzykujñc popeänienie bäödów, gdy kto ju
wcze niej po wiöciä mnóstwo pracy na odkrycie najlepszych
rozwiñzaþ? Przykäadem mogñ byè algorytmy szyfrowania
czy kompresji danych — je li nie jeste geniuszem mate-
matycznym, lepiej skorzystaj w tym zakresie z gotowej
biblioteki.


x Gdy istnieje bardzo maäe prawdopodobieþstwo, e bödziemy
chcieli modyfikowaè kod biblioteki.
Kiedy lepiej jednak napisaè wäasny kod, a przynajmniej powa nie
zastanowiè siö przed u yciem gotowych bibliotek:
x Dobrze jest samemu zaimplementowaè kod zwiñzany z pod-
stawowñ logikñ dziaäania aplikacji (logikñ biznesowñ), nawet
je li istniejñ gotowe komponenty. Gdy tworzymy np. sklep
internetowy dla klienta, to albo zdecydujmy siö na zapropo-
nowanie mu gotowego, istniejñcego kodu (ewentualnie po
niewielkich modyfikacjach), albo napiszmy wäasny, korzy-
stajñc jedynie z najbardziej bazowych rozwiñzaþ. Zdecydowa-
nie odradzaäbym jednak tworzenie go w oparciu o wykrojone
kawaäki kodu (komponenty, klasy lub wröcz jego fragmenty)
z jednego lub kilku gotowych sklepów i sklejanie ich wäasnymi
wstawkami. Jest maäo prawdopodobne, e w przyszäo ci uda
siö zapanowaè nad dalszym rozwojem i aktualizacjñ takiego
programu, jak równie e powstaäy kod-zombie bödzie bez-
pieczny. Zgodnie z reguäñ, aby samemu implementowaè lo-
gikö biznesowñ, natomiast do niskopoziomowych funkcji
korzystaè z bibliotek, dobrñ praktykñ jest na przykäad u y-
cie jednej z nich do komunikacji z bazñ danych, wysyäania
poczty elektronicznej czy uwierzytelniania i autoryzacji u yt-
kowników. Mo na te skorzystaè z jakiego prostego fra-
meworka panelu administracyjnego. Natomiast ju , dajmy
na to, koszyk sklepowy powinien byè raczej samodzielnie
napisanym fragmentem kodu.
x Zawsze, gdy wa na jest inwencja i nieszablonowo è, a jed-
nocze nie napisanie dobrego kodu nie jest trudne (nie trzeba
byè geniuszem matematycznym). Przykäadem mo e byè
opisana w rozdziale 3.14 weryfikacja, czy u ytkownik jest
czäowiekiem, czy programem. Walczñc z automatem, warto
byè twórczym i stworzyè wäasny, niebanalny kod. Roboty
zdecydowanie wolñ kod standardowych, dostöpnych w sieci


bibliotek (a raczej preferujñ go ich twórcy, bo mogñ wtedy
äatwiej nauczyè swoje programy odpowiednich reakcji). Byè
mo e nikt nigdy nie napisze automatu oszukujñcego Twój
wäasny kod, natomiast gdy u yjesz gotowego komponentu,
mo e siö okazaè, e taki robot ju istnieje.
x Bezpieczeþstwa nigdy za wiele. Mo emy korzystaè z goto-
wych systemów zabezpieczeþ, dobrze jest jednak nawet
wtedy wple è w kod od czasu do czasu pewnñ wäasnñ, nie-
standardowñ procedurö.
x Gdy zamierzamy czösto modyfikowaè kod. U ycie gotowego,
zwäaszcza czösto aktualizowanego, mo e w takim przypadku
zmusiè nas do po wiöcania du ej ilo ci czasu na äñczenie
zmian czy eliminowanie konfliktów.
Warto pamiötaè, e jözyk PHP jest bardzo rozbudowany i czasem
to, co chcieliby my sami zaimplementowaè, jest ju dostöpne
w jego podstawowej wersji. Dlatego gdy stajemy przed nowym
problemem, warto jest rozpoczñè pracö od przejrzenia pod-
röcznika u ytkownika PHP — mo e to zaoszczödziè nam sporo
czasu i zmniejszyè liczbö potencjalnych bäödów.

5.6. Zaciemnianie kodu PHP
Zaciemnianie kodu programu nigdy nie powinno byè traktowane
jako podstawowy sposób jego ochrony. Zabezpieczenie przez
zaciemnienie (ang. security by obscurity) nie daje adnej gwarancji
bezpieczeþstwa. Mo e byè ono traktowane jedynie jako dodatek
zmniejszajñcy liczbö ataków wykonywanych przez „niedzielnych”
wäamywaczy bñd napastników uzbrojonych w ogólnodostöpne
narzödzia säu ñce do automatycznych wäamaþ (w jözyku angiel-
skim funkcjonuje trudne do przeäo enia, lecz dobrze okre lajñce
ten typ wäamywaczy okre lenie script kiddies). Zaciemnianie kodu
mo e tak e mieè na celu jego ochronö przed konkurencjñ. Je li


chcemy uzyskaè taki efekt i jest on dla nas wa ny, najlepiej bödzie
jednak zrezygnowaè z otwarto ci aplikacji i u yè jednego z profe-
sjonalnych narzödzi kodujñcych. Tworzñ one pliki binarne zawie-
rajñce kod po redni, dekompilowany przed wäa ciwñ interpretacjñ
przez specjalny program (wiöcej na ten temat w rozdziale 5.7).
Je li z ró nych przyczyn nie jeste my w stanie z nich skorzystaè,
to zaciemnienie kodu mo e okazaè siö dobrym, kompromisowym
wyj ciem.
Security by obscurity mo e mieè jeszcze jeden pozytywny efekt
uboczny. Jawny i dostöpny kod mo e prowokowaè klienta, który
go zakupiä, lub innego niedo wiadczonego u ytkownika do „grze-
bania” w nim. Osoba znajñca jedynie podstawy PHP mo e próbo-
waè modyfikowaè go na wäasnñ rökö, najczö ciej psujñc go. Zaciem-
nienie utrudnia takie zabawy. Trzeba jednak pamiötaè, e nie jest
to rozwiñzanie do koþca uczciwe wobec klienta czy u ytkownika
i nie ka dy z nich jest w stanie je zaakceptowaè. Warto wiöc, zanim
zdecydujemy siö dokonaè zaciemnienia naszego kodu, zawsze
indywidualnie rozwa yè wszystkie za i przeciw.
Decydujñc siö na zaciemnienie kodu PHP, powinni my pamiötaè
o nastöpujñcych kwestiach:
x Kod staje siö wtedy nieczytelny i niedebugowalny (usuwa-
nie bäödów i ledzenie wykonania takiego programu jest
ekstremalnie trudne), dlatego nigdy nie zaciemniajmy go
przed wypuszczeniem ostatecznej, stabilnej wersji.
x Zaciemnienie kodu mo e zmieniè sposób jego dziaäania.
Nawet je li ono samo wykonane zostanie poprawnie, to mogñ
wystñpiè takie problemy, jak zmiana czasu dziaäania po-
szczególnych elementów programu czy wy cig. Je li kod jest
wra liwy na zmiany zale no ci czasowych, mo e nawet
przestaè dziaäaè. Z tej cechy zaciemniania wynika postulat
ponownego testowania caäej aplikacji po jego wykonaniu.


x Najlepiej jest napisaè program, który bödzie w stanie zaciem-
niaè kod w sposób zautomatyzowany. Dziöki temu na ser-
werze deweloperskim bödziemy mogli pracowaè z otwar-
tymi ródäami, a przed publikacjñ dokonywaè szybkiego
zaciemnienia ich. Jako e proces ten bödzie wykonywany
automatycznie, bödziemy mogli powtarzaè go wielokrotnie
(np. po wykryciu i poprawieniu kolejnych bäödów).
Istnieje wiele sposobów zmniejszania czytelno ci kodu i czynienia
go niezrozumiaäym dla czäowieka, na przykäad:
x Zamiana identyfikatorów z czytelnych dla niego na nic
nieznaczñce. Nazwa zmiennej 'lNumerSeryjny' mo e sporo
powiedzieè potencjalnemu wäamywaczowi, ale je li zmie-
nimy jñ na 'ab45hc98a_9skj', nie bödzie on wiedziaä, o co
chodzi. Dla komputera jest to natomiast bez znaczenia — nie
interpretuje on nazw zmiennych, funkcji itp. pod kñtem
znaczenia. Dla niego ka da nazwa jest równie dobra.
x Usuniöcie znaków koþca linii oraz spacji. Odczyt tre ci pro-
gramu bödzie do è trudny dla czäowieka, gdy caäo è kodu
zapiszemy w jednym wierszu, podczas gdy komputerowi
nie zrobi to oczywi cie adnej ró nicy.
x Staäych wystöpujñcych w programie nie mo na zamieniè tak
äatwo jak identyfikatorów — je li to zrobimy, przestanie
on dziaäaè prawidäowo. Mo emy jednak zapisaè je w innej
formie. Ju podziaä tekstu na poszczególne znaki i napisa-
nie: 'Q' + 'W' + 'E' + 'R' + 'T' + 'Y' zamiast 'QWERTY'
utrudni ycie wäamywaczowi. Nie bödzie on mógä wyszukaè
tego ciñgu przy pomocy automatu i podmieniè go. Jednak
przeglñdajñc kod samodzielnie, nadal bödzie w stanie go
zauwa yè. Je li ciñg ten jest kluczowy z punktu widzenia
bezpieczeþstwa, warto pój è dalej. Mo na zamieniè znaki
na odpowiadajñce im kody ASCII, a je z kolei zapisywaè nie
wprost, lecz np. jako dziaäanie matematyczne. Mo na te


u yè mniej czytelnego systemu liczbowego, jak np. ósemkowy
(aczkolwiek warto pamiötaè, e dla wäamywacza system
szesnastkowy mo e byè czytelniejszy ni dziesiötny).
x Usuniöcie komentarzy. Jest to banalna metoda, ale äatwo
o niej zapomnieè. Niektórzy programi ci modyfikujñ jñ
i zamiast usuwaè komentarze, zmieniajñ je na mylñce, tj.
sugerujñce, e dany fragment kodu säu y czemu innemu ni
w rzeczywisto ci. Osobi cie nie polecam tego sposobu —
äatwo mo e siö on obróciè przeciwko nam.
Dla osób pragnñcych zaciemniè swój kod stworzyäem narzödzie
wykonujñce tö pracö. Jest to rozwiñzanie bardzo proste, które nie
stosuje skomplikowanych i wymy lnych technik. Daleko mu
tak e do wielu dostöpnych na rynku, darmowych czy komercyj-
nych programów tego typu, jest ono jednak interesujñce z kilku
powodów:
x Jego kod jest niedäugi i prosty w zrozumieniu, tak wiöc czy-
telnik mo e go äatwo przeanalizowaè, aby zobaczyè, jak
wyglñda korzystanie z ró nych technik zaciemniajñcych ró-
däa PHP w praktyce. Mo na go równie u yè jako bazy dla
wäasnego rozwiñzania.
x To proste narzödzie jest bardzo u yteczne i sprawdza siö co
najmniej w 90% sytuacji, w których mo e zaj è potrzeba
zaciemnienia kodu.
x Nie uniemo liwi ono zdolnemu wäamywaczowi modyfikacji
kodu, ale z pewno ciñ uäatwi ochronö wäasno ci intelektu-
alnej przed osobami nieznajñcymi dobrze jözyka PHP. Dziöki
niemu z wiökszym zaufaniem mo na np. umie ciè swój kod
na serwerze PHP wynajötym od maäo znanej firmy hostin-
gowej, do której nie mamy peänego zaufania (byè mo e jed-
nak nie powinni my nigdy go tam zamieszczaè).


Caäy kod znajduje siö pod adresem: ftp://ftp.helion.pl/przyklady/
php5lk.zip — poni ej omówiö jedynie kilka jego najciekawszych
fragmentów i zastosowanych w nim technik.
x Podmiana nazw zmiennych. Zmienna o nazwie 'identi
´fier' zostaje zamieniona na ciñg: '_' . $los . md5($iden
´tifier . $license_number), gdzie $los ma warto è
losowñ z zakresu od 0 do 10000, $identifier to stara nazwa,
a $license_number to staäa warto è zadana jako parametr.
Nazwa zmiennej podmieniana jest na nowñ we wszystkich
plikach we wskazanej lokalizacji (äñcznie z podfolderami).
Ze wzglödu na zastosowanie do è prostego algorytmu iden-
tyfikacji zmiennych w kodzie nie wolno stosowaè technik
takich jak:
x u ycie podwójnego operatora $$,
x dostöp do prywatnych pól klasy spoza niej, np. $zmien
´na->moje_pole. Zamiast tego nale y skorzystaè z funkcji
dostöpowej $zmienna->GetMojePole() i w niej u yè do-
zwolonej konstrukcji $this->moje_pole. Inaczej mówiñc,
wszystkie pola klasy traktujmy jak prywatne. Publiczne
powinny byè jedynie metody.
x Narzödzie ma zdefiniowane dwie tablice: DONT_TOUCH —
nale y w niej umie ciè nazwy zmiennych, które majñ zostaè
pominiöte (nie zostanñ one zmienione), oraz CONST_TOKEN.
Zmienne o identyfikatorach z tej drugiej nie bödñ posiadaäy
czö ci losowej — ich nowe nazwy bödñ zawsze takie same.
x Narzödzie nie modyfikuje nazw zmiennych rozpoczynajñ-
cych siö od znaku _.
x Usuwanie znaków przej cia do nowej linii. Po ich wyeli-
minowaniu kod programu zostanie zapisany w jednym
wierszu.


x Usuwanie komentarzy. Dotyczy to zarówno tych zaczyna-
jñcych siö od //, jak równie zawartych pomiödzy znakami
/* i */.

U ycie narzödzia polega na wywoäaniu jednej z dwóch funkcji:
x ExecuteAllDirectory($license_number, $dir, $ver
´bose) — dokonuje ona zaciemnienia wszystkich plików
znajdujñcych siö w folderze $dir oraz w jego podfolderach.
$license_number to parametr, który zostanie zakodowany
w nazwie zmiennej. $verbose przyjmuje warto ci 0 lub 1,
gdzie 1 oznacza wypisanie na wyj ciu informacji o przebiegu
zaciemniania, m.in. o ka dej modyfikowanej zmiennej, a 0 —
cichy tryb pracy.
x ExecuteAllFile($license_number, $file, $verbose) —
dziaäa ona tak samo jak ExecuteAllDirectory, lecz tylko dla
pliku $file.
Gäównñ funkcjñ, która zamienia identyfikatory zmiennych, jest
GetVarsFromFile. Zostaje ona wywoäana raz dla ka dego pliku,
a jej dziaäanie skäada siö z dwóch etapów:
x Wyszukania ciñgu znaków alfanumerycznych, rozpoczy-
najñcego siö symbolem dolara (identyfikuje on w jözyku
PHP zmienne) i, je li nazwa zmiennej byäa ju modyfikowana,
podmienienia jej, a je li nie miaäo to jeszcze miejsca — wyge-
nerowania nowej, zapamiötania jej i dokonania zamiany.
x W drugim etapie robimy dokäadnie to samo, lecz zamiast
znaku $ szukamy $this->.
Kod jest bardzo prosty i z pewno ciñ mo na go usprawniè i zop-
tymalizowaè. Jest napisany w taki sposób, aby byä przejrzysty
nawet dla osób säabiej znajñcych jözyk PHP. Warto jeszcze wspo-
mnieè o parametrze $license_number. Jego warto è jest zakodo-
wana w nowej nazwie zmiennej. Nie jest tam u yta wprost, lecz


razem ze starñ nazwñ poddana zostaje dziaäaniu funkcji md5. Dziöki
temu prostemu zabiegowi uzyskujemy nastöpujñce cechy:
x Nowa nazwa zmiennej wyglñda na losowñ, lecz jej fragment
(zawsze ten sam) zawiera ciñg, który mo emy interpretowaè.
Inaczej mówiñc, jedna jej czö è jest losowa, a druga staäa
i w dodatku zawiera zakodowanñ przez nas tajnñ informacjö.
x Powy szñ cechö mo na wykorzystaè w celu zabezpieczenia
programu. Wszystkie nazwy zmiennych zawierajñ klucz
seryjny, dziöki czemu kod uzyskuje jakby indywidualny
„stempel” — mo na zweryfikowaè, czy dany jego egzem-
plarz jest u ywany przez wäa ciwego klienta. Daje to tak e
mo liwo è stosowania ró nych technik ochronnych (kod
programu mo e na przykäad weryfikowaè, czy pewna kon-
kretna zmienna zawiera w nazwie tajnñ informacjö w postaci,
której siö spodziewamy).
x Je li kto zmodyfikuje kod poprzez zmianö nazwy zmiennej
lub doda nowñ — jeste my w stanie to wykryè. Mo na te
napisaè procedurö, która automatycznie sprawdzi popraw-
no è nazw zmiennych w caäym programie.

5.7. Kodowanie róde PHP
Zakodowanie ródeä programu to co wiöcej ni tylko zaciem-
nienie (rozdziaä 5.6). Dostöpne na rynku narzödzia, takie jak ion-
Cube czy Zend Guard, dokonujñ kompilacji ródeä PHP do tzw.
kodu po redniego, zapisanego w postaci binarnej i nieczytelnego
dla czäowieka. Dodatkowo mogñ one szyfrowaè kod, chroniè go
przed nieuprawnionym u yciem poprzez najró niejsze formy
licencjonowania (ograniczenia czasowe, liczby u yè, limit równo-
legle korzystajñcych u ytkowników itp.) oraz tworzyè jego cyfrowe
sygnatury. Narzödzia takie wymagajñ instalacji na serwerze roz-
szerzenia dekodujñcego kod po redni przed interpretacjñ przez


serwer PHP kodu wäa ciwego. Ta cecha powoduje, e sñ one
najczö ciej niedostöpne dla osób korzystajñcych z usäug firm
hostingowych (choè nieraz firmy takie udostöpniajñ narzödzia
dekodujñce ródäa, tym bardziej e moduäy dekodujñce najczö ciej
sñ darmowe). Je li zale y nam na du ym stopniu poufno ci ródeä,
to warto skorzystaè z takich narzödzi. Pomimo silnej ochrony,
jakñ one dajñ, nie nale y jednak opieraè systemu bezpieczeþstwa
aplikacji jedynie na nich!

5.8. Psychologiczne aspekty
bezpiecze stwa aplikacji sieciowych
Psychologiczne aspekty bezpieczeþstwa aplikacji sieciowych to
bardzo szeroka tematyka. Poruszö tu jedynie kilka istotnych
aspektów. Postulaty zawarte w tym rozdziale nie powinny stano-
wiè gotowych rozwiñzaþ, a jedynie byè „po ywkñ intelektualnñ”,
wspomagajñcñ Czytelnika w dalszych rozmy laniach, majñcych
na celu stworzenie wäasnego systemu zabezpieczeþ. „Miökkie”
sposoby ochrony, tj. metody psychologiczne, w adnym wypadku
nie powinny zastöpowaè „twardych” technik programistycznych.
Program powinien byè po prostu dobrze zabezpieczony, a pewne
psychologiczne techniki, zniechöcajñce potencjalnego wäamywacza
bñd skäaniajñce u ytkownika do zwiökszenia poziomu swojego
bezpieczeþstwa, stanowiè mogñ dodatkowy czynnik zmniejsza-
jñcy prawdopodobieþstwo udanego ataku na naszñ aplikacjö.

5.8.1. Dancing pigs vs security — ta czéce winki
kontra bezpiecze stwo: zmu u ytkownika
do wybrania rozwiéza bezpiecznych
Okre lenie dancing pigs (taþczñce winki) wziöäo siö od uwagi
Edwarda Feltena i Gary’ego McGraw: Given a choice between dan-
cing pigs and security, users will pick dancing pigs every time, co


mo na przetäumaczyè: „Je li dasz u ytkownikowi wybór miödzy
taþczñcymi winkami a wiökszym bezpieczeþstwem, to zawsze
wybierze on taþczñce winki”. Inaczej mówiñc, przeciötny u yt-
kownik zawsze skäonny jest ignorowaè komunikaty o zagro e-
niach, a majñc wybór — wybieraè rozwiñzanie mniej bezpieczne,
ale za to efektowniejsze, modniejsze czy äadniejsze. U ytkownicy
czösto nie czytajñ ostrze eþ, klikajñc Tak niezale nie od wielko ci
u ytej w nich czcionki, ilo ci wykrzykników czy powagi ich tonu.
Po prostu ignorujñ kwestie bezpieczeþstwa, uwa ajñc, e skoro
tyle razy nic siö nie staäo, to nie stanie siö i teraz. Niestety — je li
u ytkownik dozna negatywnych skutków swojego (zäego) wyboru,
to najczö ciej winñ obarczy twórcö oprogramowania, a nie swojñ
lekkomy lno è. Wszystko to sprawia, e programista nie powi-
nien w sprawach bezpieczeþstwa pytaè go o zdanie ani i è na
ustöpstwa czy kompromisy. Ka dy program czy strona WWW
powinny domy lnie byè zabezpieczone w maksymalnym mo li-
wym stopniu, a dopiero potem mo na rozwa yè, czy nie umo -
liwiè zmniejszenia stopnia ochrony najbardziej zaawansowa-
nym u ytkownikom. Taka mo liwo è powinna byè jednak ukryta
wewnñtrz zaawansowanych opcji i trudna do znalezienia dla
poczñtkujñcych. Najistotniejszych zasad, a w szczególno ci tych,
które mogñ wpäynñè na bezpieczeþstwo innych u ytkowników,
nie powinno siö nigdy daè wyäñczyè lub obej è, chyba e za zgodñ
i pod kontrolñ administratora systemu.

5.8.2. Security by obscurity
— prezentuj jak najmniej informacji o aplikacji
Wielokrotnie ju podkre lone zostaäo w tej ksiñ ce, e zaciemnia-
nie kodu i ukrywanie informacji o wewnötrznych szczegóäach
aplikacji nie jest mocnym zabezpieczeniem. Warto jednak zapew-
niè sobie tö dodatkowñ barierö zmniejszajñcñ liczbö potencjalnie
gro nych ataków. Ukrywajñc informacje o sposobie komunikacji


z bazñ danych, dziaäaniu algorytmów, parametrach czy wröcz
o tym, e korzystamy z PHP, mo emy wyeliminowaè bñd znie-
chöciè czö è wäamywaczy, w tym tzw. script kiddies, czyli poczñt-
kujñcych — posäugujñcych siö gotowymi narzödziami, których
zasad dziaäania nie rozumiejñ. Takie podej cie mo e tak e ograni-
czyè liczbö ataków wykonywanych przez roboty i — co jest dodat-
kowñ zaletñ — zmniejszyè nieco niepo ñdane obciñ enie programu
(brak danych mo e zniechöciè czö è wäamywaczy i nie daè robo-
tom punktów zaczepienia do dalszych ataków. W ten sposób bez-
u yteczny ruch do naszej aplikacji zostanie zmniejszony).
Istotne jest równie to, e nie ma ludzi nieomylnych. Ka dy z nas
popeänia bäödy, nawet je li nie zawsze zdajemy sobie z tego sprawö.
Nawet bardzo dobrze przetestowany program wciñ mo e zawie-
raè nieprawidäowo ci i luki w systemie bezpieczeþstwa. Nigdy
nie bödziemy pewni na 100%, e tak nie jest. Dobrze jest wiöc
przynajmniej podjñè próbö zmniejszenia ryzyka wykrycia naszych
pomyäek i dziur przez innych. Wiöcej na temat paradygmatu secu-
rity by obscurity w rozdziale 5.2.

5.8.3. Czarne listy kontra bia e listy
Obrona przed pewnymi zabronionymi elementami, np. odwiedzi-
nami z niektórych adresów IP, okre lonymi frazami w danych
zewnötrznych, niechcianñ korespondencjñ e-mail itp., mo e zostaè
przeprowadzona na dwa sposoby:
x Przy u yciu biaäej listy. Polega ona na dopuszczeniu wyäñcz-
nie zamkniötego zbioru akceptowalnych elementów i zablo-
kowaniu wszystkich innych.
x Przy u yciu czarnej listy. Polega ona na zablokowaniu
wyäñcznie zamkniötego zbioru elementów i dopuszczeniu
wszystkich innych.


Elementy zaliczane do czarnej listy mogñ byè wyznaczane na
podstawie pewnych reguä. Podej cie takie nazywane jest heury-
stycznym. Uäatwia ono stworzenie listy i zwiöksza szansö na zablo-
kowanie elementów nowych, tj. nieznajdujñcych siö na niej, ale
zachowujñcych siö podobnie do znanych ju „czarnych elemen-
tów”. Heurystyczna budowa czarnej listy mo e wiñzaè siö z blo-
kadñ pewnych elementów niezasäu enie, tylko z powodu ich
podobieþstwa do niebezpiecznych. Analogicznie mo na tworzyè
tak e biaäñ listö, ale jej skuteczno è mo e byè wówczas mniejsza i,
podobnie jak w przypadku czarnej, pewne elementy mogñ zostaè
zakwalifikowane do niej nieprawidäowo, co zmniejszy bezpie-
czeþstwo systemu. Generalnie uwa a siö, e biaäe listy sñ bez-
pieczniejsze od czarnych, gdy problemem tych drugich jest to,
e nie mo na przewidzieè wszystkich zagro eþ, jakie mogñ pojawiè
siö w przyszäo ci. Wadñ biaäych list mo e byè z kolei ich nadmierna
restrykcyjno è dla u ytkownika, który musi zatwierdziè ka dy
nowy element. Przykäadem programów korzystajñcych z nich sñ
zapory sieciowe, posiadajñce spis dopuszczalnych portów i adre-
sów, które mogñ äñczyè siö z chronionym przez nie komputerem.
Z kolei programy antywirusowe, które do identyfikowania za-
gro eþ u ywajñ zazwyczaj znanej sobie bazy wirusów, sñ przy-
käadem u ycia czarnych list.
Do ró nych celów nale y stosowaè ró ne rozwiñzania. Oto
przykäad:
x Ja prowadzi maäñ firmö. Jego gäównym sposobem korespon-
dencji z klientami jest poczta elektroniczna. Wielu z nich
po raz pierwszy zgäasza zapotrzebowanie na sprzedawane
przez niego produkty, wäa nie wysyäajñc e-mail. Ja otrzy-
muje tak e du o niechcianej korespondencji, w tym wiele
reklam. Rozwiñzaniem odpowiednim dla niego jest wiöc u y-
cie czarnej listy z pewnymi elementami heurystyki. Jego
program pocztowy powinien blokowaè korespondencjö
zawierajñcñ säowa, o których Ja wie, e nie u yjñ ich nigdy


jego klienci, a które czösto stosowane sñ w reklamach. Ponie-
wa Ja prowadzi dziaäalno è wyäñcznie na terenie Polski,
program powinien blokowaè tak e wszystkie e-maile z innych
krajów, a w szczególno ci z grupy paþstw wysyäajñcych
najwiöcej spamu. W ten sposób Ja wyeliminuje wiökszo è
niechcianej poczty, lecz musi liczyè siö z tym, e program
przepu ci niewielkñ ilo è spamu pochodzñcego z Polski
i niezawierajñcego zabronionych säów. U ycie biaäej listy nie
jest dla niego dobrym rozwiñzaniem, poniewa nie wie on,
kto mo e zostaè jego klientem, i nie jest w stanie stworzyè
skoþczonej listy osób, których wiadomo ci chce czytaè. Spo-
sobem noszñcym cechy biaäej listy byäoby akceptowanie
wyäñcznie wiadomo ci z Polski, sprawdziäby siö on jednak
gorzej ni czarna lista.
x Maägosia u ywa poczty elektronicznej wyäñcznie do komu-
nikacji z rodzinñ i znajomymi. Ona te otrzymuje du o nie-
chcianej korespondencji i chciaäaby to ograniczyè. U ycie
biaäej listy jest dla niej idealnym rozwiñzaniem, poniewa
umo liwia dopuszczenie wiadomo ci TYLKO od ograni-
czonej grupy nadawców. Je li Maägosia pozna nowych zna-
jomych, to doda ich do niej röcznie. Nie powinno sprawiè
jej to käopotu, bo taka sytuacja ma miejsce rzadziej ni raz
w tygodniu. Natomiast u ycie czarnej listy, choè tak e
mo liwe — nie daje jej gwarancji pozbycia siö wszystkich
niechcianych e-maili.
Je eli zbiór prawidäowych, dopuszczalnych kombinacji jest z góry
znany, to lepiej jest zastosowaè biaäñ listö. Przykäadem mo e byè
ochrona przed atakami typu cross site scripting. Mo na wymy liè
wietne metody filtrowania i blokady zäych fragmentów kodu
wstrzykiwanych do danych, ale nie mamy pewno ci, e kto
w przyszäo ci nie wymy li nowego ich zestawu, obchodzñcego
nasze zabezpieczenia. Lepiej jest weryfikowaè informacje z ze-
wnñtrz, sprawdzajñc, czy pasujñ do przygotowanego przez nas


wzorca, o którym wiadomo, e jest zawsze poprawny — czyli
sprawdziè, czy znajdujñ siö one na naszej biaäej li cie. Je li nie
da siö stworzyè wzorca w 100% poprawnego i obawiamy siö, e
na naszej biaäej li cie nadal mogñ znajdowaè siö elementy nie-
chciane, to zastosowanie czarnej listy jako dodatkowej ochrony
jest sensowne.

5.8.4. Karanie w amywacza
Co zrobiè po wykryciu próby wäamania? Czy karaè wäamywacza,
np. usuniöciem konta w systemie, a mo e nawet powiadomieniem
organów cigania? Niekiedy mo e mieè to sens, jednak zawsze
nale y przemy leè nastöpujñce problemy:
x Czy naprawdö mamy 100% pewno ci, e jest to wäamanie?
A mo e to legalny u ytkownik przez przypadek wygene-
rowaä zapytanie do serwera, wyglñdajñce jak próba ataku?
Poniewa w prawie stosuje siö domniemanie niewinno ci, to
i my nie mo emy zakäadaè zäych intencji, nie majñc pewnych
dowodów. Atakowi trzeba zapobiec — to oczywiste, karanie
wäamywacza powinno byè jednak zarezerwowane tylko dla
specyficznych, najbardziej ewidentnych przypadków.
x Lud mi kierujñ ró ne motywy: ciekawo è, chöè sprawdze-
nia siö, uzyskania säawy. Ale mo e byè to tak e chöè szko-
dzenia lub uzyskania korzy ci cudzym kosztem. Czy napast-
nik tylko przeäamaä zabezpieczenia i nic ponadto, czy te
dokonaä realnych zniszczeþ i (lub) w efekcie siö wzbogaciä?
Wäamanie nie zawsze cechuje siö takñ samñ szkodliwo ciñ
i nie zawsze domaga siö zastosowania kary. Byè mo e nawet
atakujñcy zgäosi bäñd w systemie i pomo e w jego rozwiñ-
zaniu? Karaj wäamywaczy, którzy dokonali realnych znisz-
czeþ. Pamiötaj jednak, e nie muszñ one byè fizyczne —
kradzie poufnych informacji, np. przez firmö konkuren-
cyjnñ, mo e spowodowaè spore straty.


x Próba automatycznego ukarania wäamywacza przez program
mo e umo liwiè mu uzyskanie danych cennych przy kolej-
nych wäamaniach (np. gdy program „chwali” siö, e zablo-
kowaä mu konto — nigdy nie wiesz, czy komunikat taki nie
da wäamywaczowi jakich informacji, których szukaä, podczas
gdy samo konto nie jest mu do niczego potrzebne). Mo e
byè te tak, e pierwszy atak jest faäszywy i ma na celu od-
wrócenie uwagi od wäa ciwego lub e mamy do czynienia
z atakiem po rednim i odpowied programu (kara) mo e byè
w jaki sposób wykorzystana przez wäamywacza w kolejnym
jego etapie. Z tego punktu widzenia lepiej jest skupiè siö
na odciöciu mo liwo ci wykonania kolejnych ataków (np.
poprzez niewielkñ blokadö czasowñ aplikacji, wyäñczenie
pewnych funkcji administracyjnych do czasu zakoþczenia
ledztwa przez administratora itp.) ni na karaniu, które i tak
mo e byè nieskuteczne.
Podsumowujñc, aplikacja wykrywajñca próbö wäamania powinna
zneutralizowaè jñ i odmówiè dalszej wspóäpracy, w miarö mo -
liwo ci przygotowujñc dla administratora plik z logiem, zawiera-
jñcy lady pomocne w namierzeniu przyczyny ataku i samego
wäamywacza. Nie jest natomiast priorytetem automatyczne kara-
nie go, chyba e specyfika przypadku naprawdö tego wymaga.
W razie dokonania powa nego przestöpstwa o sporej szkodliwo ci
nale y zebraè dowody i zgäosiè ten fakt organom cigania.

5.8.5. Brzytwa Ockhama
Stosujñc brzytwö Ockhama, nie nale y mno yè bytów ponad
potrzebö. Ka dy dodatkowy moduä programu, ka da nadmiarowa
linia kodu, zawiäo è czy komplikacja jest niepotrzebna, bo mo e
zawieraè bäñd wpäywajñcy na bezpieczeþstwo. Podczas progra-
mowania warto mieè w pamiöci metaforö przedstawiajñcñ system
zabezpieczeþ jako äaþcuch — jest on tak silny, jak jego najsäabsze
ogniwo. W dobrze zabezpieczonym systemie wystarczy jeden


le chroniony moduä lub funkcja, by byä on podatny na ataki.
Wszystkie inne rodki ostro no ci stajñ siö wówczas maäo istotne,
bo wäamywacz prawie na pewno uderzy tam, gdzie opór bödzie
najmniejszy.
Utrzymywanie kodu w postaci czytelnej i samodokumentujñcej
siö równie speänia postulaty brzytwy Ockhama. Im jest on prost-
szy i äatwiejszy w zrozumieniu, tym mniejsza jest szansa na to,
e bödzie zawieraä bäñd obni ajñcy poziom bezpieczeþstwa, i tym
äatwiej bödzie ewentualnñ nieprawidäowo è poprawiè. Czösto
lepiej jest napisaè kilka linii wiöcej, uzyskujñc bardziej czytelny
kod, ni skracaè go maksymalnie, ryzykujñc powstanie bäödów.

5.8.6. Socjotechnika
Najczöstszñ przyczynñ udanych wäamaþ jest uzyskanie przez
wäamywacza informacji znaczñco uäatwiajñcych mu dziaäanie
(w skrajnym przypadku mo e on po prostu zdobyè hasäo ofiary
i podszyè siö pod niñ — przy takich atakach nie jest wa na wie-
dza informatyczna). Dane takie czösto zdobywane sñ przy u yciu
socjotechniki. Wäamywacz mo e przed próbñ ataku przeprowa-
dziè rozpoznanie, u ywajñc do tego celu telefonu bñd wypytujñc
osoby korzystajñce z aplikacji. Mo e na przykäad:
x podszyè siö pod firmö administrujñcñ serwerem lub innñ
infrastrukturñ IT organizacji korzystajñcej z programu;
x podszyè siö pod dziaä ksiögowy, kontrahentów, dostawców,
a nawet pod zarzñd organizacji;
x udawaè zagubionego u ytkownika i wyciñgnñè w ten spo-
sób wa ne informacje od dziaäu obsäugi klienta lub informa-
tycznego;
x znajñc osobi cie pracownika, wyäudziè od niego przydatne
dane podczas prywatnej rozmowy;


x podsäuchaè lub podejrzeè informacje podczas „przypadko-
wej” wizyty w siedzibie organizacji w roli sprzedawcy, mon-
tera, potencjalnego klienta itp. (pracownicy czösto przycze-
piajñ karteczki z hasäami do monitorów lub na blat biurka);
x przekonaè rozmówcö, aby pobraä i zainstalowaä oprogra-
mowanie przesäane przez Internet (odmianñ tego dziaäania
mo e byè phishing);
x przy pomocy podstöpu zaraziè wirusem bñd koniem tro-
jaþskim jednñ lub wiöcej maszyn w sieci wewnötrznej orga-
nizacji itd.
Metod jest wiele i zale ñ one gäównie od wyobra ni i zdolno ci
psychologicznych oraz aktorskich wäamywacza. Zazwyczaj ude-
rza on w osobö najsäabszñ z jego punktu widzenia, np. najmniej
znajñcñ siö na informatyce — czyli takñ, której najtrudniej bödzie
zweryfikowaè techniczne niuanse, lub np. najkrócej pracujñcñ
w organizacji, która nie zna pracowników czy kontrahentów i nie
jest w stanie odró niè ich od wäamywacza.
Nie ma äatwych sposobów zapobiegania zdobyciu informacji przez
sprytnego wäamywacza stosujñcego socjotechnikö. W grö wcho-
dzi tutaj zawodny „czynnik ludzki”. Mo na jedynie przyjñè pewne
zasady i spróbowaè narzuciè je organizacji u ytkujñcej aplikacjö:
x Informacje istotne z punktu widzenia bezpieczeþstwa po-
winny byè znane jak najmniejszej grupie osób.
x Poniewa czasem ciö ko jest przewidzieè, jakie dane mogñ
byè istotne, a jakie nie, u ytkownicy powinni udzielaè infor-
macji na temat programu czy infrastruktury informatycznej
tylko uprawnionym osobom i tylko poprzez zdefiniowany
przez nie kanaä (np. je li administrator wyznaczyä specjalnñ
stronö WWW z panelem do zgäaszania uwag, to pracownicy
nie powinni wysyäaè ich poprzez e-mail ani odpowiadaè na
jakiekolwiek pytania zadane tñ drogñ).


x W organizacji powinna istnieè przemy lana polityka ha-
seä. Mogñ one na przykäad wygasaè co pewien czas. Nie
powinny byè zbyt proste do odgadniöcia ani zapisywane
w sposób trwaäy, szczególnie w miejscu dostöpnym dla osób
z zewnñtrz.
x Infrastruktura informatyczna organizacji powinna byè aktu-
alizowana na bie ñco. Dotyczy to w szczególno ci uaktual-
niania systemów operacyjnych, programów serwerowych
i baz wirusów oprogramowania antywirusowego.
x U ytkownicy powinni stale korzystaè z programu antywi-
rusowego oraz zapory systemowej. Instalowanie prywatnych
programów powinno byè zabronione.
x Co pewien czas powinna byè przeprowadzana inspekcja
infrastruktury informatycznej pod kñtem jej bezpieczeþstwa.
x Kluczowe dla organizacji dane powinny byè stale archiwi-
zowane. Idealnym rozwiñzaniem byäoby przechowywa-
nie archiwów poza siedzibñ firmy (na wypadek powodzi,
po aru itp.).
x Pracownicy powinni byè regularnie szkoleni w kwestiach
bezpieczeþstwa systemów informatycznych.

5.8.7. Nie poprawiaj w amywacza
W sytuacji gdy wykryjemy, e dane wej ciowe nie sñ zgodne
z dopuszczalnym wzorcem, np. zawierajñ litery, gdy dozwolone
sñ tylko cyfry — mo emy zareagowaè dwojako:
x spróbowaè poprawiè je, usuwajñc nieprawidäowe znaki bñd
podmieniajñc je na poprawne (wielu programistów zastöpuje
na przykäad nielegalne symbole znakiem podkre lenia);


x przerwaè dalsze ich przetwarzanie i zwróciè informacjö
o bäödzie.
Drugi ze sposobów jest zazwyczaj bezpieczniejszy. Lepiej jest nie
poprawiaè danych potencjalnie pochodzñcych od wäamywacza,
poniewa :
x Nigdy nie mamy 100% pewno ci, e potrafimy znale è
i poprawiè wszystkie nieprawidäowe znaki. Mo emy zapo-
mnieè o jednym z nich i naraziè program na wäamanie, mimo
e poprawimy ich czö è. Gdy bödziemy zgäaszaè bäñd po
napotkaniu choèby jednego zäego znaku, wäamywacz straci
szansö na udany atak, nawet je li poza nim przemyca te
inne symbole, których nie rozpoznajemy prawidäowo. Aby
atak siö udaä, musiaäby on dodaè do danych wyäñcznie znaki,
których nie potrafimy odrzuciè.
x Nigdy nie wiemy, czy nasza interwencja nie jest na rökö
wäamywaczowi. Byè mo e atak jest po redni i liczy on wäa-
nie na naszñ procedurö naprawczñ. Przypu èmy, e mamy
dwustopniowñ weryfikacjö — najpierw sprawdzamy, czy
ciñg nie zawiera zabronionych säów, w ród których jest
„javascript”, a nastöpnie usuwamy znaki spacji. Wprowadze-
nie przez wäamywacza ciñgu „javascript” zostanie zabloko-
wane przez pierwszy test. Je li jednak poda on go w postaci
„java script”, to dane te przejdñ test pomy lnie, a w drugim
etapie „naprawimy” je do postaci „javascript”, eliminujñc
spacjö.


PHP5. Bezpieczne programowanie. Leksykon kieszonkowy

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (12)

En vedette

En vedette (15)

Similaire à PHP5. Bezpieczne programowanie. Leksykon kieszonkowy

Similaire à PHP5. Bezpieczne programowanie. Leksykon kieszonkowy (20)

Plus de Wydawnictwo Helion

Plus de Wydawnictwo Helion (20)

PHP5. Bezpieczne programowanie. Leksykon kieszonkowy