Cyfroteka.pl

klikaj i czytaj online

Cyfro
Czytomierz
00441 008684 10464328 na godz. na dobę w sumie
PHP5. Bezpieczne programowanie. Leksykon kieszonkowy - książka
PHP5. Bezpieczne programowanie. Leksykon kieszonkowy - książka
Autor: Liczba stron: 160
Wydawca: Helion Język publikacji: polski
ISBN: 83-246-0635-1 Data wydania:
Lektor:
Kategoria: ebooki >> komputery i informatyka >> webmasterstwo >> php - programowanie
Porównaj ceny (książka, ebook, audiobook).
Twórz bezpieczny kod w PHP!

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ą!

Wykorzystaj możliwości PHP w pełni i bezpiecznie!

Znajdź podobne książki Ostatnio czytane w tej kategorii

Darmowy fragment publikacji:

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 7 9 10 12 13 18 23 27 30 2.1. Obsäuga danych z zewnñtrz 2.2. Wstrzykiwanie kodu 2.3. Nadmiar uprawnieþ 2.4. Przekazywanie danych miödzy skryptami 2.5. Nieuprawnione uĔycie skryptu 2.6. Uwierzytelnianie uĔytkownika 2.7. UĔycie niebezpiecznych instrukcji 2.8. Bezpieczna obsäuga bäödów 2.9. Bezpieczeþstwo systemu plików 3. Rodzaje ataków na aplikacje PHP ..............................................32 32 34 34 38 40 42 54 3.1. Atak siäowy na hasäo 3.2. Przechwycenie hasäa przez nieuprawnionñ osobö 3.3. Wäamanie na serwer bazy danych 3.4. Wäamanie na serwer PHP 3.5. Cross site scripting (XSS) 3.6. Wstrzykiwanie kodu SQL (SQL injection) 3.7. Wstrzykiwanie poleceþ systemowych (shell injection) 3.8. Wstrzykiwanie nagäówków HTTP do wiadomoĈci e-mail (e-mail injection) 3.9. Cross site request forgery (XSRF) 3.10. Przeglñdanie systemu plików (directory traversal) 56 57 61 3 3.11. Przejöcie kontroli nad sesjñ (session fixation) 3.12. Zatruwanie sesji (session poisoning) 3.13. HTTP response splitting 3.14. Wykrywanie robotów 3.15. Ataki typu DOS i DDOS 3.16. Cross site tracing 3.17. Bezpieczeþstwo plików cookie 3.18. Dziura w preg_match 62 68 84 84 97 101 101 102 4. Konfiguracja serwera PHP ........................................................105 105 106 107 4.1. Dyrektywa register_globals 4.2. Tryb bezpieczny (safe mode) 4.3. Ukrywanie PHP, dyrektywa expose_php 5. Metody produkcji bezpiecznego oprogramowania ................109 109 5.1. Architektura programu a bezpieczeþstwo 5.2. Ochrona przez ukrycie informacji (security by obscurity) 111 5.3. Pozostawianie „tylnych wejĈè” i kodu tymczasowego 113 114 5.4. Aktualizowanie wersji PHP i uĔywanych bibliotek 5.5. UĔycie gotowych bibliotek i frameworków 115 120 5.6. Zaciemnianie kodu PHP 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. 6.2. Kierunki rozwoju jözyka PHP w wersji 6. 138 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 5. Metody produkcji bezpiecznego oprogramowania _ 111 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. 112 _ PHP5. Bezpieczne programowanie. Leksykon kieszonkowy 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 5. Metody produkcji bezpiecznego oprogramowania _ 113 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- 114 _ PHP5. Bezpieczne programowanie. Leksykon kieszonkowy 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 5. Metody produkcji bezpiecznego oprogramowania _ 115 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ä, 116 _ PHP5. Bezpieczne programowanie. Leksykon kieszonkowy 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 5. Metody produkcji bezpiecznego oprogramowania _ 117 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. 118 _ PHP5. Bezpieczne programowanie. Leksykon kieszonkowy 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 5. Metody produkcji bezpiecznego oprogramowania _ 119 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 120 _ PHP5. Bezpieczne programowanie. Leksykon kieszonkowy 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. 5. Metody produkcji bezpiecznego oprogramowania _ 121 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Ĕ 122 _ PHP5. Bezpieczne programowanie. Leksykon kieszonkowy 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è). 5. Metody produkcji bezpiecznego oprogramowania _ 123 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. 124 _ PHP5. Bezpieczne programowanie. Leksykon kieszonkowy 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 5. Metody produkcji bezpiecznego oprogramowania _ 125 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 126 _ PHP5. Bezpieczne programowanie. Leksykon kieszonkowy 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 5. Metody produkcji bezpiecznego oprogramowania _ 127 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 128 _ PHP5. Bezpieczne programowanie. Leksykon kieszonkowy 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. 5. Metody produkcji bezpiecznego oprogramowania _ 129 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 130 _ PHP5. Bezpieczne programowanie. Leksykon kieszonkowy 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 5. Metody produkcji bezpiecznego oprogramowania _ 131 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. 132 _ PHP5. Bezpieczne programowanie. Leksykon kieszonkowy 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 5. Metody produkcji bezpiecznego oprogramowania _ 133 Ē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; 134 _ PHP5. Bezpieczne programowanie. Leksykon kieszonkowy 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ñ). 5. Metody produkcji bezpiecznego oprogramowania _ 135 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); 136 _ PHP5. Bezpieczne programowanie. Leksykon kieszonkowy 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ö. 5. Metody produkcji bezpiecznego oprogramowania _ 137
Pobierz darmowy fragment (pdf)

Gdzie kupić całą publikację:

PHP5. Bezpieczne programowanie. Leksykon kieszonkowy
Autor:

Opinie na temat publikacji:


Inne popularne pozycje z tej kategorii:


Czytaj również:


Prowadzisz stronę lub blog? Wstaw link do fragmentu tej książki i współpracuj z Cyfroteką: