plik

Wydawnictwo Helion
ul. Koœciuszki 1c
44-100 Gliwice
tel. 032 230 98 63

e-mail: helion@helion.pl

Ajax. Bezpieczne
aplikacje internetowe

Autor: hristopher Wells
T³umaczenie: Piotr Rajca
ISBN: 978-83-246-1373-1
Tytu³ orygina³u:

Securing Ajax Applications:

Ensuring the Safety of the Dynamic Web

Format: B5, stron: 248

Otwarte Ÿród³a danych a bezpieczeñstwo aplikacji

•

Jak zabezpieczyæ przep³yw danych klient-serwer?

•

Jak strzec serwera aplikacji przed atakami?

•

Jak przewidzieæ i przeciwdzia³aæ potencjalnym zagro¿eniom

w dynamicznych aplikacjach?

Otwartoœæ i bezpieczeñstwo, utopijne po³¹czenie s³ów, a zarazem nieodwracalna
przysz³oœæ sieci internetowej. Wspó³dzielenie zasobów niesie ze sob¹ szereg zagro¿eñ
na ró¿nych warstwach sieciowych. Efektywniej jest przewidzieæ potencjalne zagro¿enia
na etapie tworzenia aplikacji i zapobiec im, ni¿ póŸniej ³ataæ dziury w oprogramowaniu.
Ka¿dy programista tworz¹cy oprogramowanie sieciowe ostatecznie bêdzie musia³
zmierzyæ siê z niepo¿¹dan¹ ingerencj¹ maj¹c¹ swoje Ÿród³o w sieci internetowej. B¹dŸ
na to przygotowany i nie daj siê zaskoczyæ, wykorzystaj wiedzê zawart¹ w tej ksi¹¿ce.

Ksi¹¿ka

„

Ajax. Bezpieczne aplikacje internetowe

”

traktuje o zagro¿eniach i sposobach

zabezpieczeñ aplikacji sieciowych, a szczególnie dynamicznych interfejsów API.
Przeznaczona jest zarówno dla programistów zaczynaj¹cych przygodê z Ajaksem,
jak i dla tych, którzy Ajaksa jeszcze nie znaj¹. Przyda siê ka¿demu, kto stoi na stra¿y
bezpieczeñstwa aplikacji sieciowych, uczy bowiem, jak zapobiegaæ zagro¿eniom
w trakcie pisania aplikacji oraz jak przeciwdzia³aæ im w ju¿ istniej¹cym oprogramowaniu
sieciowym.

•

Bezpieczeñstwo aplikacji sieciowych

•

Technologie zabezpieczeñ komunikacji klient-serwer

•

Zabezpieczenia na poziomie protoko³ów

•

Serwer WWW i zagro¿enia p³yn¹ce z internetu

•

Zabezpieczanie otwartych zasobów danych

•

Bezpieczeñstwo interfejsów API

•

Zagro¿enia bezpieczeñstwa w aplikacjach typu mushup

Twórz rozleg³e aplikacje sieciowe i zadbaj o ich bezpieczeñstwo?

Spis tre

ļci

Wst

ýp ........................................................................................................................................ 7

1. Ewoluuj

éca Sieë ............................................................................................................11

Powstanie Sieci

2. Bezpiecze

ħstwo aplikacji internetowych ................................................................... 41

Zagadnienia podstawowe

Analiza ryzyka

Czösto spotykane säabe punkty aplikacji internetowych

3. Technologie zabezpiecze

ħ ..........................................................................................69

Jak witryny komunikujñ siö ze sobñ

Bezpieczeþstwo przeglñdarek

Wtyczki, rozszerzenia i programy dodatkowe

4. Zabezpieczanie serwera ............................................................................................113

Bezpieczeþstwo sieci

114

Bezpieczeþstwo komputera

117

Poprawianie zabezpieczeþ serwera WWW

135

Poprawianie zabezpieczeþ serwera aplikacji

143

5. S

ĥabe podstawy ......................................................................................................... 145

Säabe punkty protokoäu HTTP

146

ZagroĔenia

151

JSON

159

XML

161

RSS

164

Atom

165

REST

168

_ Spis treļci

6. Zabezpieczanie us

ĥug sieciowych ..............................................................................171

Ogólne informacje o usäugach sieciowych

172

Usäugi sieciowe a bezpieczeþstwo

183

Web Service Security

188

7. Tworzenie bezpiecznych interfejsów programowania ............................................191

Tworzenie wäasnych interfejsów API

192

Warunki wstöpne

197

Warunki koþcowe

197

Niezmienniki

197

Zagadnienia bezpieczeþstwa

198

Usäugi sieciowe w architekturze REST

201

8. Aplikacje typu mashup ..............................................................................................209

Aplikacje internetowe i otwarte internetowe interfejsy API

211

Dzika Web 2.0

212

Aplikacje typu mashup a bezpieczeþstwo

214

Otwarte kontra bezpieczne

218

Bezpieczna przytulanka

219

Studium przypadków

222

Skorowidz .............................................................................................................................233

ROZDZIA

Ĥ 2.

Bezpiecze

ħstwo aplikacji internetowych

W rozdziale 1. opisano, jak powstaäa Sieè oraz w jaki sposób dziaäa. WaĔne jest, by zapamiötaè,

Ĕe nowoczesna Sieè bazuje na grupie abstrakcji programowych oraz Ĕe tworzenie godnych
zaufania i bezpiecznych aplikacji internetowych wciñĔ wymaga od programistów znajomoĈci
podstawowego protokoäu i infrastruktury.

W niniejszym rozdziale dokäadniej poznasz zasady dziaäania mechanizmów zabezpieczeþ
oraz moĔliwoĈci ich zastosowania w aplikacjach internetowych. JeĈli aplikacja dziaäa w Inter-
necie, to znajduje siö w pierwszej linii Twojej firmowej lub domowej sieci. MoĔna by jñ po-
równaè z drzwiami do Ĉwiata zewnötrznego, przez które odwiedzajñcy mogñ wejĈè i spraw-
dziè, co masz do zaoferowania. Twoja aplikacja musi zatem byè bezpieczna, a Ty sam musisz
mieè ĈwiadomoĈè zagroĔeþ, na jakie naraĔa ona Twojñ sieè.

Zagadnienia podstawowe

WyobraĒ sobie straĔnika przechadzajñcego siö nocñ po säabo oĈwietlonych korytarzach jakie-
goĈ biurowca. Kiedy straĔnik wchodzi do kolejnych pomieszczeþ, oĈwietla je latarkñ, szuka-
jñc wszystkiego, co mogäoby siö wydaè podejrzane, po czym zamyka drzwi i idzie dalej.
StraĔnik wykonuje te czynnoĈci kaĔdej nocy, zapewniajñc dziöki temu bezpieczeþstwo bu-
dynku i znajdujñcym siö w nim biur.

CóĔ, aplikacje internetowe zazwyczaj nie majñ takich straĔników. Nie ma nikogo, kto mógäby
zabezpieczyè je przed potencjalnymi wäamywaczami.

Potrzeba wbudowania zabezpiecze

A zatem co moĔna zrobiè? Pierwsze, co mogñ zrobiè programiĈci, to zauwaĔyè koniecznoĈè
wyposaĔenia aplikacji w mechanizmy zabezpieczeþ. Oprócz tego naleĔy siö upewniè, co tak
naprawdö wymaga ochrony. Gdzie aplikacja zaczyna siö, a gdzie koþczy? Jaka jest jej po-
wierzchnia? JeĈli Twoja aplikacja przypomina typowe aplikacje internetowe, to skäada siö
z trzech podstawowych elementów, które opiszö w dalszej czöĈci rozdziaäu.

Rozdzia

ĥ 2. Bezpieczeħstwo aplikacji internetowych

Oczekuj niespodzianek

Alarm! Internetowi napastnicy próbujñ wäamaè siö do naszej aplikacji. UĔywajñ aplikacji
w nieprzewidziany sposób, by doprowadziè do wystñpienia bäödów i innych sytuacji, które
mogliby wykorzystaè do swoich celów. Sytuacji, których nikt nie przewidziaä, niemal zawsze
stanowiñ zagroĔenie bezpieczeþstwa.

Czy pamiötasz straĔnika? Patroluje on budynek, szukajñc w nim wszystkiego, co odbiega od
normy. Doskonale wie, Ĕe jeĈli coĈ znajdzie siö nie na swoim miejscu, to na pewno coĈ musiaäo
do tego doprowadziè. OczywiĈcie inteligentny wäamywacz czeka do momentu, gdy straĔnik
sprawdzi wszystkie pomieszczenia, i zaatakuje dopiero póĒniej.

Podmioty

Podmioty to wszyscy uĔywajñcy aplikacji. OczywiĈcie, najpopularniejszymi podmiotami bödñ
zwyczajni uĔytkownicy (czyli osoby odwiedzajñce aplikacjö), jednak mogñ to takĔe byè inne
programy korzystajñce z usäug sieciowych lub udostöpnionego, zewnötrznego interfejsu pro-
gramowania (API). NiezaleĔnie od rodzaju podmioty zawsze sñ „bytami” zewnötrznymi ko-
rzystajñcymi z systemu.

WyobraĒmy sobie, Ĕe dysponujemy witrynñ WWW zajmujñcñ siö sprzedawaniem róĔnego
typu kontrolek do aplikacji. Witryna implementuje zwyczajny koszyk zakupów oraz usäugö
sieciowñ.

Takiej aplikacji mogñ uĔywaè dwa odröbne typy podmiotów:

Klienci:

Czyli osoby, które zajrzaäy na witrynö, by kupiè któryĈ z oferowanych produktów, uĔy-
wajñc przy tym koszyka do zakupów.

Partnerzy:

Programy korzystajñce z usäug sieciowych do zarzñdzania produktami i wchodzñce
w skäad wiökszej, zäoĔonej aplikacji.

Gdyby coĈ miaäo pójĈè nie tak, chcielibyĈmy wiedzieè, co siö zdarzyäo i kto doprowadziä do
wystñpienia problemów. WyobraĒ sobie dowolny film kryminalny — podmiotami byliby
wszyscy objöci dochodzeniem.

Obiekty

Obiektami nazywamy wszelkie zasoby aplikacji. Zazwyczaj bödñ to naleĔñce do niej dane,
lecz mogñ to byè takĔe pliki, poäñczenia, usäugi oraz wszelkie inne rzeczy, które majñ dla niej
jakñĈ wartoĈè lub które do niej naleĔñ.

W naszym przykäadzie obiektami bödñ takie rzeczy, jak prywatne dane klientów, dane do-
stawców, firmowe dane zgromadzone w bazie danych oraz same sprzedawane kontrolki.
Innymi säowy, obiekty te moĔna by porównaè do przeróĔnych cennych drobiazgów prze-
chowywanych przez ojca w kredensie.

Przyglñdajñc  siö  tym  wszystkim  obiektom  i  danym,  naleĔy  zadaè  sobie  pytanie,  czy  trzeba
zachowaè  ich  poufnoĈè?  Czy  aplikacja  powinna  je  w  jakiĈ  sposób  zabezpieczaè?  Jakie  bödñ
konsekwencje  dla  Ciebie  lub  firmy,  jeĈli  te  dane  pojawiñ  siö  nagle  wystawione  na  sprzedaĔ
na jakiejĈ witrynie w byäym Zwiñzku Radzieckim?

Zagadnienia podstawowe

Operacje

Operacje wiñĔñ ze sobñ podmioty i obiekty. To rzeczy, które aplikacja moĔe wykonywaè.
Operacje zapewniajñ podmiotom dostöp do obiektów (a mówiñc precyzyjniej, podmioty uĔy-
wajñ operacji, by pobieraè obiekty i manipulowaè nimi).

W naszej przykäadowej witrynie operacjami dostöpnymi dla klientów mogäyby byè:

dodanie wybranej kontrolki do koszyka z zakupami,

usuniöcie kontrolki z koszyka,

zamówienie wybranych kontrolek,

przeglñdanie katalogu.

Podobnie usäuga uĔywana przez partnerów mogäaby udostöpniaè nastöpujñce operacje:

wyszukiwanie kontrolek,

zakup kontrolek.

Wszystkie trzy wymienione wczeĈniej podstawowe elementy aplikacji — podmioty, obiekty
oraz operacje (przedstawione na rysunku 2.1) — okreĈlajñ wspólnie powierzchniö aplikacji.

Rysunek 2.1. Podmioty, obiekty oraz operacje

Powierzchnia

KaĔdy uĔytkownik dodany do systemu, kaĔda operacja wykonywana przez aplikacjö oraz
kaĔdy uĔywany przez niñ zasób zwiökszajñ powierzchniö aplikacji. A zatem, wziñwszy pod
uwagö zagadnienia bezpieczeþstwa, naleĔy to sobie uĈwiadomiè i ograniczyè moĔliwoĈci
aplikacji jedynie do tych, które sñ jej absolutnie niezbödne.

Rozdzia

ĥ 2. Bezpieczeħstwo aplikacji internetowych

NaleĔy ograniczaè powierzchniö ataku. Ograniczenie liczby funkcji aplikacji jedynie
do tych, które sñ niezbödne, uäatwi nam wäaĈciwe zajöcie siö jej zabezpieczeniem.

Po ustaleniu powierzchni aplikacji — czyli okreĈleniu, kim bödñ jej uĔytkownicy oraz jakie
czynnoĈci bödñ mogli wykonywaè — bödziemy mogli zajñè siö wykorzystaniem najlepszych
metod zabezpieczania w pozostaäych obszarach aplikacji.

Poufno

ļë

Kluczowym elementem dynamicznych witryn WWW sñ dane. To wäaĈnie one sprawiajñ, Ĕe
witryny sñ dynamiczne. Niektóre dane sñ banalne, na przykäad wartoĈè pola wyboru lub
przycisku opcji. Jednak sñ takĔe dane specjalne, na przykäad nazwiska i adresy klientów,
daty ich urodzenia, numery ubezpieczeþ, kart kredytowych i tak dalej. Takie specjalne dane
muszñ byè chronione, a aplikacja powinna je ujawniaè tylko w odpowiednich sytuacjach.

PoniewaĔ aplikacje internetowe obsäugujñ wiele rodzajów takich wraĔliwych informacji, za-
tem ich zadaniem jest takĔe je chroniè. To oznacza, Ĕe koniecznie naleĔy upewniè siö, iĔ
w trakcie dziaäania aplikacji informacje te w Ĕaden niezaplanowany i przypadkowy sposób
nie zostanñ ujawnione.

Oprócz tego, jeĈli aplikacja przesyäa wraĔliwe dane przez sieè, konieczne jest przedsiöwziöcie
odpowiednich Ĉrodków majñcych na celu zapewnienie bezpieczeþstwa informacji podczas
transmisji, na przykäad zaszyfrowanie ich.

Prywatno

ļë

Czym jest prywatnoĈè, albo mówiñc ĈciĈlej: czym sñ dane prywatne? CóĔ, gdybym zdradziä
tö informacjö, to chyba nie moĔna by ich juĔ byäo nazywaè prywatnymi, nieprawdaĔ? Pro-
blem z prywatnoĈciñ polega na tym, Ĕe dla róĔnych osób oznacza ona zupeänie co innego.
Jednak wiökszoĈè ludzi okreĈla dane prywatne jako takie, które nie powinny staè siö ogólno-
dostöpne ani bezpaþskie. Ich wartoĈè polega na tym, Ĕe pomagajñ ustaliè unikalnñ toĔsamoĈè
ich wäaĈciciela.

Hackerzy uwielbiajñ dane prywatne. W ich poszukiwaniu bödñ grzebaè w naszych Ĉmie-
ciach, segregowaè lepkie odpadki, rozmokäe kawaäeczki papieru i wñchaè resztki koĈci z kur-
czaka. Bödñ to robiè chötnie, wiedzñc, Ĕe kiedyĈ ich styl Ĕycia siö zmieni. WyobraĔajñ sobie
zupeänie nowe, inne Ĕycie — Ĕycie w którym bödñ kimĈ zupeänie innym, takim jak Ty.

Szyfrowanie

Dobrym sposobem zabezpieczenia danych jest ich szyfrowanie. Zalecanym sposobem szy-
frowania jest wykorzystanie matematycznie mocnego algorytmu zatwierdzonego przez
National Institute of Standards and Technology (w skrócie: NIST, Narodowy Instytut Standardów
i Technologii), takiego jak AES.

Zagadnienia podstawowe

Szyfrowanie wraĔliwych danych — zabezpieczanie wraĔliwych danych przy wyko-
rzystaniu matematycznie mocnego algorytmu. Szyfrowanie zapewnia poufnoĈè oraz
integralnoĈè danych.

Istnieje kilka ogólnie dostöpnych, dobrych algorytmów szyfrowania, opracowanych przez
godne zaufania instytucje. Wybierajñc jeden z nich, naleĔy siö takĔe upewniè, Ĕe równieĔ
wybrana implementacja algorytmu pochodzi od dostawcy godnego zaufania. Nie warto siliè
siö na tworzenie wäasnej implementacji.

Zagadnienia zwiñzane z szyfrowaniem sñ trudne. NaleĔy wybraè algorytm, który bödzie sto-
sowany, zarzñdzaè kluczami szyfrujñcymi oraz zaimplementowaè specjalny kod säuĔñcy do
przechowywania danych. To naprawdö sporo zachodu. Dlatego teĔ zamiast szyfrowania nie-
którzy programiĈci decydujñ siö ukrywaè, separowaè bñdĒ w jakikolwiek inny sposób „za-
ciemniaè” dane, utrudniajñc przez to ich analizö i zrozumienie.

PoniĔej przedstawiono kilka sposobów takiego zaciemniania danych:

kodowanie Base64,

kodowanie stosowane w adresach URL,

kodowanie UTF8,

zaciemnianie przez przesuwanie bitów.

Jeszcze gorsi sñ programiĈci, którzy uwaĔajñ, Ĕe sñ w stanie zaimplementowaè algorytmy
szyfrowania lepiej, niĔ to zrobiä Bruce Schneier

. Ci wkäadajñ swoje klejnoty koronne do tek-

turowego pudeäka i umieszczajñ je w Internecie, wprost przed wszelkimi hackerami.

Integralno

ļë i walidacja

PoniewaĔ obecnie tak wiele aplikacji internetowych bazuje na danych, dlatego tak ogromne
znaczenie ma zapewnienie prawidäowoĈci danych, przy czym w tym kontekĈcie oznacza to,
Ĕe stosowanie danych musi byè bezpieczne, a same dane nie mogñ byè modyfikowane. Speä-
nienie tych warunków oznacza, Ĕe dane zostanñ sprawdzone za kaĔdym razem, gdy trafiñ do
systemu, oraz Ĕe bödñ istnieè sposoby weryfikacji ich poprawnoĈci. Niestety, niezwykle

äatwo jest zaäoĔyè, Ĕe ktoĈ inny za nas zajñä siö zapewnieniem poprawnoĈci danych.

Dodatkowo naleĔy siö upewniè, Ĕe dane nie zmieniñ siö ani nie uszkodzñ. Jednym z dobrych
rozwiñzaþ tego problemu jest szyfrowanie danych, kiedy nie sñ uĔywane. Dziöki temu moĔ-
na mieè pewnoĈè, Ĕe póĒniej, kiedy dane zostanñ odszyfrowane, bödñ miaäy dokäadnie takñ
samñ postaè jak w momencie szyfrowania.

Uwierzytelnianie

Od uwierzytelnienia powinna zaczynaè siö kaĔda dobra sesja. Nic nie powinno siö zdarzyè,
zanim nie upewnimy siö, z kim mamy do czynienia. Uwierzytelnianie jest procesem po-
zwalajñcym okreĈliè, czy osoba lub rzecz jest tym, za kogo lub za co siö podaje.

Bruce Schneier to amerykaþski kryptograf i specjalista z zakresu bezpieczeþstwa teleinformatycznego

— przyp.täum.

Rozdzia

ĥ 2. Bezpieczeħstwo aplikacji internetowych

Zarówno  w  prywatnych,  jak  i  publicznych  sieciach  komputerowych  (w  tym  w  Internecie)
uwierzytelnianie jest  czösto  wykonywane  przy  wykorzystaniu  nazw  uĔytkowników  i  haseä.
ZnajomoĈè nazwy uĔytkownika oraz skojarzonego z niñ hasäa jest traktowana jako potwier-
dzenie  autentycznoĈci  uĔytkownika.  KaĔdy  uĔytkownik  poczñtkowo  rejestruje  siö  (lub  jest
przez  kogoĈ  rejestrowany),  podajñc  jakieĈ  przypisane  mu  lub  samodzielnie  okreĈlone  hasäo.
Podczas nastöpnych wizyt uĔytkownik musi znaè to hasäo i je podaè.

Problem z hasäami polega na tym, Ĕe ludzie czösto je zapominajñ. To w koþcu naturalne. Nie
ma w tym nic dziwnego, zwaĔywszy na narzucane reguäy konstrukcji haseä, do których
uĔytkownicy muszñ siö stosowaè.

Zobaczmy, czemu  musimy  stawiè  czoäa.  OtóĔ  wymyĈlane  hasäa  nie  mogñ  byè  zwyczajnymi
säowami,  muszñ  zawieraè  dziwne  znaki,  duĔe  i  maäe  litery  oraz  cyfry.  KtóĔ  byäby  w  stanie
zapamiötaè coĈ takiego? Dlatego teĔ ludzie zapominajñ hasäa. A to z kolei sprawia, Ĕe zapi-
sujñ  je  na  maäych  samoprzylepnych  karteczkach  i  przyklejajñ  pod  klawiaturñ,  w  szufladzie
lub na monitorze.

Dlatego teĔ coraz wiöcej firm wykorzystujñcych Internet w swojej dziaäalnoĈci, na przykäad
banki, zaczyna wymagaè stosowania dodatkowych mechanizmów uwierzytelniania. Niektóre
uĔywajñ specjalnych Ĕetonów (ang. token), które uĔytkownicy majñ przy sobie, inne stosujñ certy-
fikaty cyfrowe. Wraz z rozwojem prowadzonej dziaäalnoĈci roĈnie takĔe potrzeba stosowania
pewnych i wiarygodnych metod uwierzytelniania oraz zapewnienia niezaprzeczalnoĈci.

Jak juĔ zaznaczono, wszelka interakcja z aplikacjñ powinna zaczynaè siö od uwierzytelnienia
uĔytkownika. Zanim mu cokolwiek udostöpnimy, uĔytkownik powinien zadeklarowaè, kim
jest. Dotyczy to wszystkich Ĕñdaþ przesyäanych Internetem. Co wiöcej, jeĈli nie uwierzytelniono
uĔytkownika, nie naleĔy tworzyè sesji.

NaleĔy przeprowadzaè uwierzytelnianie wszystkich Ĕñdaþ przesyäanych Internetem.
Dotyczy to takĔe Ĕñdaþ przesyäanych asynchronicznie. Nie zapominaj uwierzytelniaè
Ĕñdaþ przesyäanych przy uĔyciu obiektu MXLHttpRequest — i to kaĔdego z nich.

OczywiĈcie, po uwierzytelnieniu naleĔy przeprowadziè autoryzacjö (choè obie te operacje
mogñ siö wydawaè ze sobñ powiñzane).

Autoryzacja i kontrola dost

ýpu

No dobrze, zatem uĔytkownik zalogowaä siö… i co dalej? No cóĔ, samo to, Ĕe ktoĈ zalogowaä
siö do aplikacji, nie oznacza wcale, Ĕe powinien mieè uprawnienia do wykorzystania wszyst-
kich jej moĔliwoĈci. Zawsze naleĔy okreĈlaè, jakie moĔliwoĈci bödzie miaä uwierzytelniony
uĔytkownik.

Autoryzacja jest procesem przydzielania uĔytkownikom uprawnieþ do wykonywania pew-
nych czynnoĈci lub dostöpu do okreĈlonych danych.

W systemach komputerowych obsäugujñcych wielu uĔytkowników ich administratorzy okre-
Ĉlajñ, jacy uĔytkownicy majñ prawo dostöpu do systemu oraz jakie majñ uprawnienia (na
przykäad do jakich katalogów bödñ mieè dostöp, w jakich godzinach bödñ mogli korzystaè
z systemu, jaki obszar dysku zostanie im przydzielony i tak dalej). JeĈli ktoĈ zalogowaä siö do
systemu operacyjnego lub aplikacji, system lub aplikacja moĔe chcieè okreĈliè, do jakich za-
sobów dany uĔytkownik powinien mieè dostöp podczas sesji.

Zagadnienia podstawowe

A  zatem  pod  pojöciem  autoryzacji  rozumie  siö  czasami  zarówno  wstöpne  przydzielenie
uprawnieþ przez administratora systemu, jak i póĒniejsze, faktyczne sprawdzenie uprawnieþ
przypisanych uĔytkownikowi, wykonywane w momencie, gdy Ĕñda on dostöpu do jakiegoĈ
zasobu  lub  wykonania  jakiejĈ  operacji.  Autoryzacja  jest  zazwyczaj  wykonywana  po  uwie-
rzytelnieniu. W koþcu aby sprawdziè, co jakaĈ  osoba moĔe zrobiè, trzeba  najpierw okreĈliè,
kim ona jest i jakie ma uprawnienia.

Rozdzia

ĥ obowiézków

Interfejsy i funkcje uĔywane przez administratorów systemu powinny byè oddzielone od
funkcji dostöpnych dla zwyczajnych uĔytkowników. Dlatego w kaĔdym z tych obszarów
aplikacji naleĔy umieĈciè odpowiednie kontrolki. Poza tym kod wymagajñcy uprawnieþ oraz
kod obsäugujñcy zwyczajnych uĔytkowników nie powinny byè wdraĔane i umieszczane razem.

TakĔe samo Ĉrodowisko aplikacji powinno byè dzielone na warstwy, na podstawie których
bödzie nastöpnie przeprowadzany proces tworzenia, testowania i wdraĔania aplikacji. Taka
organizacja zapewnia, Ĕe do uĔytkownika koþcowego trafi sprawdzony kod o odpowiedniej,
produkcyjnej jakoĈci.

Oto typowe warstwy, na które jest dzielone Ĉrodowisko aplikacji:

Warstwa programowania

Wykorzystywana do celów tworzenia, wykrywania i usuwania bäödów w aplikacji.

Warstwa testowania

UĔywana do przeprowadzania testów moduäów, testowania wydajnoĈci i jakoĈci.

Warstwa produkcyjna

Gotowa i dziaäajñca witryna WWW.

Przez zastosowanie strategii polegajñcej na zwiökszaniu ograniczeþ wraz ze zbliĔaniem siö
do momentu wdroĔenia aplikacji, moĔna dokäadniej kontrolowaè dostöp w miejscach, gdzie
autoryzacja ma najwiöksze znaczenie.

Niezaprzeczalno

ļë

Kiedy uĔytkownik zostanie juĔ uwierzytelniony, naleĔy Ĉledziè wykonywane przez niego
operacje i rejestrowaè te spoĈród nich, które majñ kluczowe znaczenie dla bezpieczeþstwa
systemu. Dziöki temu, jeĈli stanie siö coĈ zäego, bödzie moĔna uzyskaè informacjö o tym, co
siö staäo oraz kto moĔe byè za to odpowiedzialny.

Rejestracja zdarzeþ zwiñzanych z bezpieczeþstwem systemu — rejestrowanie takich
zdarzeþ, jak próby uwierzytelniania, dostöpu, edycji i usuwania danych, tworzy ich
fizyczny Ĉlad, który moĔe pomóc w uzyskaniu niepodwaĔalnoĈci.

PoniĔej podano kilka przykäadów waĔnych zdarzeþ zwiñzanych z bezpieczeþstwem systemu:

inicjalizacja lub utworzenie sesji;

udane, jak i nieudane próby zalogowania siö do systemu;

wylogowanie siö uĔytkownika;

Rozdzia

ĥ 2. Bezpieczeħstwo aplikacji internetowych

próby logowania, w których podano nieprawidäowe hasäo;

operacje utworzenia, odczytu, aktualizacji i usuniöcia konta uĔytkownika;

zmiany konfiguracji;

uruchomienie i zatrzymanie serwera;

nieprzewidziane zdarzenia systemowe;

próby wykonania operacji, do których uĔytkownik nie ma uprawnieþ;

zmiany hasäa;

wykonanie czynnoĈci wymagajñcej wiökszych uprawnieþ;

transakcje;

zastosowanie metody

GET

zamiast

POST

Podczas rejestrowania powyĔszych zdarzeþ koniecznie naleĔy zapisywaè takĔe nastöpujñce
dane:

kto wykonaä operacjö;

skñd pochodziäo Ĕñdanie;

na jakich zasobach Ĕñdanie operowaäo;

na jakiej stronie zostaäa wykonana operacja;

data oraz godzina zajĈcia zdarzenia

… oraz wszelkie inne informacje, które mogñ póĒniej przydaè siö w prowadzeniu dochodzenia.

Dost

ýpnoļë

To, czy aplikacja bödzie dobra czy zäa, nie bödzie miaäo wiökszego znaczenia, jeĈli nie za-
pewnimy uĔytkownikom moĔliwoĈci korzystania z niej. PoniewaĔ aplikacje zaleĔñ od do-
stöpnoĈci zasobów i danych, naleĔy przedsiöwziñè odpowiednie kroki, by takĔe te systemy
byäy dostöpne.

Jednym ze sposobów mierzenia dostöpnoĈci jest wyraĔenie jej przy wykorzystaniu mitu
dziewiñtek. Stwierdzenie „nasz system jest dostöpny przez 99,99% czasu” moĔna rozumieè
w ten sposób, Ĕe system nie dziaäa przez 52,6 minuty w roku lub przez 1,01 minuty dziennie
(odpowiednie przeliczenia moĔna znaleĒè w tabeli 2.1).

Tabela 2.1. Tabela dostöpnoĈci

% dost

ýpnoļci

Czas przestoju w roku

Czas przestoju w miesi

écu

Czas przestoju w tygodniu

98%

7,30 dnia

3,36 godziny

99%

3,65 dnia

1,68 godziny

99,5%

1,83 dnia

3,60 godziny

50,4 minuty

99,9%

8,76 godziny

43,2 minuty

10,1 minuty

99,99%

52,6 minuty

4,32 minuty

1,01 minuty

99,999%

5,26 minuty

25,9 sekundy

6,05 sekundy

99,9999%

31,5 sekundy

2,59 sekundy

0,605 sekundy

Analiza ryzyka

W przewaĔajñcej wiökszoĈci przypadków ten sposób pomiaru dostöpnoĈci jest stosowany
w dokumentach marketingowych — zapewne dlatego, Ĕe wyglñda dosyè imponujñco. Niemniej
jednak takie informacje o dostöpnoĈci czösto sñ zamieszczane w oficjalnych kontraktach
i umowach o Ĉwiadczeniu usäug, dlatego warto je zapamiötaè.

Zaufanie

Zaufanie to pewnoĈè co do integralnoĈci danej osoby lub rzeczy. W kontekĈcie aplikacji in-
ternetowych zaufanie w przewaĔajñcej wiökszoĈci przypadków odnosi siö do uĔytkowników.
Aby uzyskaè zaufanie uĔytkowników, musimy:

zapewniè odpowiednie uwierzytelnianie;

upewniè siö, Ĕe uĔytkownik wykonuje jedynie te operacje, które moĔe wykonywaè;

sprawdzaè i przeprowadzaè weryfikacjö wszystkich pobieranych danych;

rejestrowaè i generowaè raporty z informacjami o wszystkich waĔnych operacjach.

Problem z zaufaniem polega na tym, Ĕe zawsze jest ono aktem wiary. Nigdy do koþca nie
wiadomo, czy danej osobie bñdĒ rzeczy moĔna w peäni zaufaè.

Analiza ryzyka

A co, jeĈli coĈ pójdzie Ēle? Trzeba mieè plan na takie sytuacje. Musimy wiedzieè, co naleĔy
zrobiè, kiedy nasza aplikacja zostanie zaatakowana. Doskonaäym sposobem znalezienia roz-
wiñzania tego problemu jest opracowanie modelu zagroĔenia dla aplikacji.

W jaki sposób moĔna oszacowaè bezpieczeþstwo aplikacji? CóĔ, w pierwszej kolejnoĈci musimy
odpowiedzieè na pytanie, czym jest aplikacja internetowa.

Anatomia aplikacji internetowych

Aplikacje internetowe zapewniajñ uĔytkownikom dostöp do bazy danych z dowolnego miej-
sca na Ĉwiecie. Z jednej strony aplikacje te dziaäajñ w Internecie, obsäugujñ nadsyäane Ĕñdania
HTTP i wysyäajñ odpowiedzi. Z drugiej strony operujñ na znajomych elementach: plikach,
zasobach systemowych i danych. PoniewaĔ zapewniajñ one dostöp do zasobów na serwerze,
trzeba je sprawdziè bardzo uwaĔnie i krytycznie.

Punkty wej

ļcia

Punktami wejĈcia sñ te miejsca aplikacji, w których dane sñ wprowadzane do systemu. Takie
dane muszñ byè zweryfikowane. JeĈli nie przeprowadzimy walidacji (czy teĔ kontroli) danych
przed ich zastosowaniem, to naleĔy je uznaè za potencjalnie skaĔone.

Do poprawnego dziaäania aplikacje wymagajñ prawidäowych danych. JeĈli do systemu trafiñ
skaĔone dane, to aplikacja mogäaby je nieumyĈlnie wyĈwietliè. Oprócz tego stosowanie ska-
Ĕonych danych mogäoby doprowadziè do zgäoszenia wyjñtku, który stanowiäby Ēródäo in-
formacji o systemie. Internetowi napastnicy poszukujñ takich sytuacji i wykorzystujñ je do
swoich celów.

Rozdzia

ĥ 2. Bezpieczeħstwo aplikacji internetowych

Informacje mogñ trafiaè do aplikacji z wielu róĔnych Ēródeä:

od uĔytkowników,

z plików,

z gniazd sieciowych,

z wäaĈciwoĈci systemowych,

z potoków,

z interfejsów programistycznych,

z rejestru systemowego,

z poczty elektronicznej,

z argumentów wiersza poleceþ,

z parametrów inicjalizacyjnych,

z zmiennych Ĉrodowiskowych,

z bazy danych.

WaĔne, by przeanalizowaè kaĔdy z tych punktów wejĈcia i okreĈliè typy przekazywanych
przez niego danych oraz sposób, w jaki sñ one uĔywane przez aplikacjö.

Poziom zaufania

Poziom zaufania to zaufanie, jakim obdarzany jest zewnötrzny byt przez przydzielenie mu
roli okreĈlajñcej moĔliwoĈci dostöpu do punktu wejĈcia aplikacji. Na przykäad rola Admini-
strator jest rolñ uprzywilejowanñ, majñcñ znacznie wiöcej uprawnieþ niĔ zwyczajni uĔytkownicy.

UĔytkownikom aplikacji naleĔy przypisywaè role, na podstawie których system bödzie okre-

Ĉlaè, czy majñ oni uprawnienia niezbödne do wykonywania poszczególnych operacji. Przez
rozdzielenie operacji, które moĔna wykonywaè w aplikacji, pomiödzy kilka róĔnych ról moĔna
utrudniè jednemu uĔytkownikowi uzyskanie zbyt duĔej kontroli nad systemem.

Aktywa

Osoby atakujñce aplikacjö zazwyczaj czegoĈ chcñ. Tym „czymĈ” sñ aktywa aplikacji. Mogñ to
byè dane albo uĔytkownicy. MoĔe to byè tajny przepis na pieczonego kurczaka. Czymkolwiek
by te aktywa byäy, atakujñcy ich chcñ, a zadaniem twórców aplikacji jest ich ochrona.

Zagro

Ŝenia i ļcieŜki ataku

Napastnicy nie majñ Ĕadnego powodu do atakowania aplikacji, o ile nie zawiera czegoĈ, co
ich interesuje. Zanim zaczniemy chroniè wszystko, co tylko moĔna zobaczyè w aplikacji, mu-
simy odpowiedzieè na pytanie, czy dany punkt wejĈcia bñdĒ operacja stwarzajñ jakieĈ zagro-

Ĕenie dla bezpieczeþstwa aplikacji. Czy jest w niej coĈ interesujñcego? Czy w efekcie ataku
system moĔe przestaè prawidäowo dziaäaè?

JeĈli weĒmiemy pod uwagö punkt wejĈcia, poäñczymy go z poziomem zaufania uĔytkownika,
a nastöpnie z aktywami aplikacji, uzyskamy ĈcieĔkö ataku. Analizujñc przepäyw danych wzdäuĔ

ĈcieĔki ataku, moĔna okreĈliè wszystkie moĔliwe zagroĔenia czyhajñce na dane, uĔytkownika
oraz system.

Analiza ryzyka

Trzeba my

ļleë jak wĥamywacz

A zatem w jaki sposób moĔna siö wäamaè do aplikacji? W jaki sposób moĔna wykorzystaè
punkt wejĈcia lub dane? W jaki sposób moĔna skaziè dane trafiajñce do systemu? W jaki spo-
sób moĔna by przeprowadziè atak? Nadszedä czas, by pomyĈleè jak internetowy wäamywacz.
Co najgorszego moĔe siö zdarzyè?

Zadaj sobie nastöpujñce pytania:

Jak przejñè kontrolö nad systemem?

Jak uzyskaè dostöp do informacji?

Jak manipulowaè informacjami?

Jak spowodowaè awariö systemu?

Jak uzyskaè dodatkowe uprawnienia?

Doskonale! A skoro system zostaä juĔ zaatakowany, co mógäby zrobiè napastnik:

bez zostania zarejestrowanym?

przez pominiöcie kroków kontroli dostöpu?

przez podszycie siö pod innego uĔytkownika?

Napastnicy w swoich atakach wcale nie muszñ siliè siö na oryginalnoĈè. Okazuje siö, Ĕe
w praktyce nowe rodzaje ataków pojawiajñ siö stosunkowo rzadko. Zazwyczaj atakujñcy
wykorzystujñ dobrze znane säaboĈci, gdyĔ jest to znacznie prostsze od poszukiwania nowych
sposobów. Internetowi napastnicy nie lubiñ utrudniaè sobie Ĕycia.

Najcz

ýļciej spotykane typy ataków

Analizujñc punkt wejĈcia w poszukiwaniu potencjalnych säabych punktów, naleĔy
sprawdziè, czy atakujñcy moĔe:

x  dokonaè trwaäych modyfikacji;
x  bezpoĈrednio przeglñdaè zasoby;
x  modyfikowaè lub wprowadzaè faäszywe dane.

Oprócz tego naleĔy sprawdziè, czy aplikacja jest w stanie prawidäowo:

x  weryfikowaè dane wejĈciowe;
x  stosowaè najlepsze praktyki pozytywnej weryfikacji;
x  uwierzytelniaè uĔytkowników;
x  autoryzowaè role;
x  zarzñdzaè konfiguracjñ;
x  prawidäowo obsäugiwaè wyjñtki;
x  uwierzytelniaè i autoryzowaè systemy serwerowe;
x  rejestrowaè zdarzenia w dziennikach;
x  szyfrowaè obecnie nieuĔywane dane.

Rozdzia

ĥ 2. Bezpieczeħstwo aplikacji internetowych

Analiza zagro

Ŝeħ

W praktyce analiza zagroĔeþ polega na zrozumieniu, w jaki sposób atakujñcy postrzega naszñ
aplikacjö. Co chce osiñgnñè? Musimy okreĈliè, w jaki sposób atakujñcy bödzie chciaä wykorzy-
staè aplikacjö. Z jakich ról oraz operacji atakujñcy skorzysta, by zagroziè jej bezpieczeþstwu?

Znalezienie odpowiedzi na te wszystkie pytania wymaga pewnych zaäoĔeþ co do moĔliwoĈci
zröcznego napastnika. Zatem przy jakich zaäoĔeniach moĔna mówiè o zagroĔeniu?

OtóĔ czösto zakäada siö, Ĕe atakujñcy moĔe na przykäad chcieè:

czegoĈ (na przykäad danych);

coĈ uszkodziè (atak typu odmowa dostöpu);

uniemoĔliwiè komuĈ zrealizowanie pewnego celu;

coĈ zmieniè;

coĈ ukryè.

Nie naleĔy jednak zgadywaè na Ĉlepo, lecz kierowaè siö przemyĈleniami bazujñcymi na wiedzy
dotyczñcej ataków.

Oto co jeszcze moĔna zaäoĔyè:

w jakim stanie musi siö znajdowaè aplikacja;

jakñ rolö ma atakujñcy;

w którym miejscu systemu zostanie przeprowadzony atak;

czy atak nie zostanie wykryty?

Modelowanie zagroĔeþ pozwala takĔe spojrzeè na aplikacjö strukturalnie i zbadaè zagroĔenia
faktyczne, a nie jedynie reagowaè na ogóle säaboĈci zabezpieczeþ. Nie moĔna zabezpieczyè
aplikacji bez wczeĈniejszego okreĈlenia zagroĔeþ.

Pionierem badaþ dotyczñcych modelowania zagroĔeþ jest firma Microsoft, a zgromadzone
przez niñ wnioski stanowiñ doskonaäy punkt wyjĈciowy. Wedäug Microsoftu proces mode-
lowania zagroĔeþ skäada siö z szeĈciu nastöpujñcych etapów:

Identyfikacji aktywów — okreĈlenia typów danych lub informacji, które mogñ intereso-
waè napastników, oraz przeanalizowania ich obecnych zabezpieczeþ.

Stworzenia ogólnego opisu architektury — przeanalizowania komponentów systemu
w celu wskazania punktów wejĈcia aplikacji oraz udokumentowania ĈcieĔek przepäywu
danych w systemie.

Dekompozycji aplikacji — przeanalizowania kaĔdej z funkcji aplikacji oddzielnie i okre-

Ĉlenia ĈcieĔek przepäywu danych oraz komponentów, które biorñ w nim udziaä.

OkreĈlenia zagroĔeþ — wskazania miejsc, w których mogñ siö pojawiè usterki w aplikacji,
oraz potencjalnych miejsc ataku.

Dokumentacji zagroĔeþ — zapisania wszystkich moĔliwych zagroĔeþ.

Oszacowania zagroĔeþ — okreĈlenia moĔliwoĈci wystñpienia i wykrycia poszczególnych
zagroĔeþ.

ýsto spotykane sĥabe punkty aplikacji internetowych

Czasami najprostszym sposobem znalezienia säabych punktów aplikacji jest przeanalizowa-
nie tego, co siö zdarzyäo w przeszäoĈci. Przez przeanalizowanie säabych punktów wykrytych
w innych aplikacjach moĔemy uczyè siö na cudzych bäödach.

OWASP

OWASP — Open Web Application Security Project (Otwarty projekt do spraw bezpieczeþstwa
aplikacji internetowych) — to otwarta spoäecznoĈè osób, których celem jest umoĔliwienie or-
ganizacjom i firmom tworzenia, kupowania oraz utrzymywania godnych zaufania aplikacji.

OWASP posiada narzödzia, dokumenty, fora dyskusyjne i lokalne oddziaäy zajmujñce siö
rozwojem bezpieczeþstwa aplikacji internetowych. Wszystkie te zasoby sñ darmowe i dostöpne
bez ograniczeþ dla wszystkich osób zainteresowanych poprawñ bezpieczeþstwa aplikacji.

OWASP sugeruje rozwiñzywanie problemów bezpieczeþstwa aplikacji poprzez analizö za-
gadnieþ zwiñzanych z ludĒmi, procesami oraz technologiñ. Okazuje siö bowiem, Ĕe najbardziej
efektywne sposoby poprawiania bezpieczeþstwa aplikacji internetowych ĈciĈle wiñĔñ siö
z usprawnieniami w tych trzech dziedzinach.

JeĈli jeszcze nie trafiäeĈ na stronö OWASP, to koniecznie powinieneĈ na niñ zajrzeè: http://
www.owasp.org.

10 najcz

ýļciej spotykanych sĥabych punktów wedĥug OWASP

OWASP okreĈliäa listö 10 najczöĈciej wystöpujñcych säabych punktów, stanowiñcych plagö
aplikacji internetowych. Oto ona:

Brak weryfikacji danych wejĈciowych

Informacje przekazywane w Ĕñdaniach nie sñ weryfikowane przed ich zastosowaniem
w aplikacji. Napastnicy mogñ wykorzystaè tö usterkö, by za poĈrednictwem aplikacji in-
ternetowej przeprowadziè atak na komponenty serwerowe.

Wadliwa kontrola dostöpu

Ten problem polega na niewäaĈciwym okreĈlaniu lub stosowaniu ograniczeþ dotyczñcych
moĔliwoĈci, jakie ma uwierzytelniony uĔytkownik systemu. Napastnicy mogñ wykorzy-
staè usterki tego typu do uzyskania dostöpu do kont innych uĔytkowników, przeglñdania
waĔnych plików bñdĒ wykonywania operacji, do których nie majñ prawa.

Wadliwe uwierzytelnianie lub zarzñdzanie sesjami

Ten problem polega na niewäaĈciwej ochronie informacji stosowanych do uwierzytelnia-
nia uĔytkowników lub danych sesji. Napastnicy, którzy mogñ przejñè hasäa, klucze,
cookies u

Ĕywane do obsäugi sesji oraz inne dane, mogñ przeäamaè system uwierzytelniania

i podszywaè siö pod innych uĔytkowników.

Ataki typu cross-site scripting

Aplikacjö internetowñ moĔna wykorzystaè jako Ĉrodek ataku na przeglñdarkö uĔytkow-
nika. Udany atak tego typu moĔe ujawniè napastnikowi informacje o sesji uĔytkownika,
umoĔliwiè zaatakowanie lokalnego komputera lub zmodyfikowanie treĈci strony w celu
wprowadzenia uĔytkownika w bäñd.

Rozdzia

ĥ 2. Bezpieczeħstwo aplikacji internetowych

Przepeänienie bufora

W przypadku nieprawidäowej weryfikacji danych komponenty aplikacji internetowych
pisanych w niektórych jözykach programowania mogñ dziaäaè nieprawidäowo, a niekiedy
moĔna je wykorzystaè do przejöcia kontroli nad procesem. Te komponenty to miödzy in-
nymi skrypty CGI, biblioteki, sterowniki oraz wykonywane na serwerze komponenty
aplikacji internetowych.

Usterki zwiñzane ze wstawianiem kodu

Kiedy aplikacje internetowe korzystajñ z systemów zewnötrznych lub lokalnego systemu
operacyjnego, przekazujñ do nich parametry. JeĈli atakujñcy bödzie w stanie przekazaè
w nich odpowiednio spreparowane polecenia, to zewnötrzny system bödzie mógä je wykonaè.

Nieprawidäowa obsäuga bäödów

Ten problem polega na niewäaĈciwej obsäudze bäödów pojawiajñcych siö podczas normal-
nego dziaäania aplikacji. JeĈli napastnikowi uda siö doprowadziè do wystñpienia bäödu,
którego aplikacja nie obsäuguje prawidäowo, to bödzie mógä uzyskaè szczegóäowe infor-
macje o systemie, sprawiè, Ĕe aplikacja nie bödzie odpowiadaè na Ĕñdania, przeäamaè me-
chanizmy zabezpieczeþ, lub nawet doprowadziè do awarii serwera.

Mechanizmy przechowywania danych, które nie zapewniajñ bezpieczeþstwa

Aplikacje internetowe czösto wykorzystujñ funkcje kryptograficzne do zabezpieczania in-
formacji i danych uwierzytelniajñcych. Zastosowanie tych funkcji jest trudne, a kod inte-
grujñcy je z resztñ aplikacji jest trudny do napisania, co czösto powoduje, Ĕe ochrona danych
jest säaba.

Odmowa dziaäania aplikacji

Ten problem polega na tym, Ĕe atakujñcym uda siö wykorzystaè zasoby aplikacji do tego
stopnia, iĔ jej peänoprawni uĔytkownicy nie bödñ w stanie z niej korzystaè. Atakujñcy
mogñ takĔe odciñè uĔytkowników aplikacji od ich kont, a nawet doprowadziè do caäkowitej
awarii aplikacji.

Niebezpieczne zarzñdzanie konfiguracjñ

Zastosowanie pewnego standardu konfiguracji serwera ma kluczowe znaczenie dla bez-
pieczeþstwa aplikacji internetowych. Wiele aspektów konfiguracji serwerów ma wpäyw
na bezpieczeþstwo, a ich domyĈlne ustawienia nie zawsze sñ optymalne.

OczywiĈcie istnieje znacznie wiöcej säabych punktów, które mogñ stanowiè zagroĔenie dla
bezpieczeþstwa aplikacji, niemniej jednak powyĔsza lista obejmuje te najwaĔniejsze i najczöĈciej
wystöpujñce.

Teraz, kiedy poznaäeĈ juĔ 10 najczöĈciej spotykanych säabych punktów aplikacji internetowych,
przyjrzyjmy siö kaĔdemu z nich nieco dokäadniej.

Niezweryfikowane dane wej

ļciowe

JeĈli z niniejszej ksiñĔki miaäbyĈ zapamiötaè tylko jednñ informacjö, to niech niñ bödzie ta: nie
moĔna ufaè Ĕadnym informacjom pochodzñcym z klienta lub przeglñdarki. Rysunek 2.2
pokazuje, gdzie czösto mogñ siö pojawiaè niezweryfikowane dane wejĈciowe.

ýsto spotykane sĥabe punkty aplikacji internetowych

Rysunek 2.2. Niezweryfikowane dane wejĈciowe

Trzeba pamiötaè, Ĕe aplikacje internetowe sñ bezstanowe, co oznacza, Ĕe poszczególne Ĕñda-
nia  sñ  od  siebie  caäkowicie  odseparowane,  a  pomiödzy  nimi  wystöpujñ  przerwy.  W  trakcie
jednej z takich przerw, przed przesäaniem Ĕñdania na serwer, atakujñcy moĔe zmodyfikowaè
dowolnñ  jego  czöĈè.  WartoĈci  zapisane  w  nagäówkach,  cookies,  polach  formularzy,  polach
ukrytych,  parametrach  äaþcucha  zapytania,  informacjach  o  kliencie  —  wszystkie  te  dane  sñ
zagroĔone.  Oznacza  to,  Ĕe  bez  przeprowadzenia  odpowiedniej  weryfikacji  nie  moĔna
ufaè Ĕadnym danych przesyäanym z przeglñdarki.

Zawsze naleĔy weryfikowaè dane pochodzñce ze Ēródeä zewnötrznych. Dane trafiajñce
do aplikacji ze Ēródeä zewnötrznych, takich jak uĔytkownicy, kanaäy informacyjne
i inne aplikacje, zawsze powinny byè weryfikowane.

Weryfikacja pozytywna oraz negatywna

Jednym z popularnych rozwiñzaþ stosowanych przez programistów jest poszukiwanie kon-
kretnych danych wykorzystywanych do przeprowadzania ataków. Kiedy takie dane uda siö
odnaleĒè, zostajñ one usuniöte. Rozwiñzania tego typu okreĈlane sñ mianem weryfikacji
negatywnej.

Weryfikacja negatywna ma jednak pewnñ wadö: nie moĔna znaè wszystkich potencjalnych
metod ataku i zabezpieczyè aplikacji przed nimi.

Poza tym jest tyle róĔnych metod pozwalajñcych na zakodowanie lub innñ zmianö postaci
danych, iĔ uzyskanie 100-procentowej pewnoĈci, Ĕe Ĕadne spreparowane i wrogie dane nie
przedostanñ siö do systemu, jest praktycznie niemoĔliwe.

Znacznie lepszym rozwiñzaniem jest zastosowanie weryfikacji pozytywnej. Polega ona na
okreĈleniu, jak powinny wyglñdaè prawidäowe dane, i podejmowaniu odpowiednich dziaäaþ,
jeĈli dane, które dotaräy do aplikacji, nie sñ zgodne z tymi prawidäowymi wzorcami. Na
przykäad, jeĈli dane wpisane przez uĔytkownika w polu Nazwisko bödñ siö zaczynaäy od
znaku apostrofu, a nie od jakiejĈ litery, to bödzie moĔna uznaè, Ĕe podane nazwisko nie jest
prawidäowe.

Rozdzia

ĥ 2. Bezpieczeħstwo aplikacji internetowych

Weryfikacja po stronie klienta

Zadziwiajñco duĔo aplikacji wykorzystuje kod pisany w jözyku JavaScript do przeglñdania
formularzy przed ich przesäaniem na serwer i sprawdzeniem, czy podane w nich informacje
sñ prawidäowe.

W przeszäoĈci powszechna byäa opinia, Ĕe przeprowadzanie weryfikacji pól formularza po
stronie klienta przy wykorzystaniu do tego celu mocy obliczeniowej przeglñdarki jest chytrym
rozwiñzaniem.

Niestety, poniewaĔ caäy ten kod ma dziaäaè po stronie przeglñdarki, nie ma Ĕadnej gwarancji,
Ĕe faktycznie zostanie wykonany. Atakujñcy moĔe przejrzeè ten kod i ominñè go samodzielnie,
przesyäajñc formularz z dowolnie spreparowanymi danymi.

Rozmywanie

Modyfikowanie  danych  oraz  wprowadzanie  faäszywych  danych  w  celu  doprowadzenia  do
awarii  dziaäajñcych  aplikacji  internetowych  okreĈlane  jest  jako  rozmywanie  (ang.  fuzzing).
Jest to najprawdopodobniej najpopularniejszy sposób  przeprowadzania  ataków  na  aplikacje
internetowe.  Skrypty  i  narzödzia  uĔywane  przez  internetowych  napastników  zaczynajñ  po-
woli automatyzowaè przeprowadzanie ataków tego typu, a zatem moĔna przypuszczaè, Ĕe
w przyszäoĈci stanñ siö one jeszcze bardziej popularne.

Nieprawid

ĥowa kontrola dostýpu

Kontrola dostöpu to proces polegajñcy na ograniczaniu moĔliwoĈci dostöpu do funkcji i da-
nych systemu. Nie kaĔdy powinien mieè dostöp do wszystkiego. Model uwierzytelniania
aplikacji internetowych jest ĈciĈle powiñzany z wykorzystywanymi w nich rolami oraz funk-
cjonalnoĈciñ aplikacji, a uĔytkownik powinien mieè moĔliwoĈè wykonywania wyäñcznie tych
operacji, które dopuszcza przydzielona mu rola. Rysunek 2.3 przedstawia kilka potencjalnych
säabych punktów, zwiñzanych z nieprawidäowo dziaäajñcymi mechanizmami kontroli dostöpu.

Rysunek 2.3. Nieprawidäowa kontrola dostöpu

Prawidäowe zaimplementowanie mechanizmów kontroli dostöpu jest trudne. ProgramiĈci
stosunkowo czösto nie doceniajñ zäoĔonoĈci i trudnoĈci tego zagadnienia. Niektórzy próbujñ
implementowaè wäasne metody autoryzacji, co stwarza zagroĔenie dla bezpieczeþstwa apli-
kacji. Zastosowanie wypróbowanego modelu autoryzacji jest znacznie lepszym rozwiñza-
niem niĔ tworzenie wäasnego z nadziejñ, Ĕe uda siö obsäuĔyè wszystkie miejsca i sytuacje
wymagajñce kontroli dostöpu.

ýsto spotykane sĥabe punkty aplikacji internetowych

Zasada najniĔszych uprawnieþ: uĔytkownik powinien mieè moĔliwoĈè wykonywa-
nia tylko absolutnie niezbödnych czynnoĈci.

Interfejsy administracyjne

Kolejny problem zwiñzany z autoryzacjñ pojawia siö, kiedy uĔytkownicy korzystajñcy z apli-
kacji internetowej majñ dostöp do interfejsów lub funkcji administracyjnych. Interfejsy te sta-
nowiñ äakomy kñsek dla napastników atakujñcych aplikacjö, gdyĔ jeĈli uda siö do nich dostaè,
napastnik bödzie mógä dowolnie zwiökszyè swoje uprawnienia.

Rozdziaä obowiñzków — naleĔy przypisywaè uĔytkownikom role i przydzielaè róĔ-
ne poziomy uprawnieþ. NaleĔy kontrolowaè sposób, w jaki aplikacja jest tworzona,
testowana i wdraĔana, oraz to, kto ma dostöp do jej danych.

Interfejsy administracyjne ze wzglödu na swoje ogromne moĔliwoĈci powinny byè wdraĔane
niezaleĔnie od podstawowej aplikacji internetowej; dziöki temu bödzie moĔna monitorowaè
i okreĈlaè prawa dostöpu bardziej dokäadnie.

Wadliwe uwierzytelnianie i zarz

édzanie sesjami

Stój! Kto idzie? Kim sñ osoby logujñce siö do aplikacji? Skñd to wiemy? Jak moĔna siö prze-
konaè, czy osoby korzystajñce z aplikacji faktycznie sñ tymi, za które siö podajñ?

Przed frontowymi drzwiami do naszej internetowej aplikacji stojñ systemy uwierzytelniania.
Wymagajñ one, by uĔytkownicy przed „wejĈciem” do aplikacji przeszli rodzaj testu. KaĔdy
taki test jest uwaĔany za czynnik uwierzytelniania i uĔytkownik musi go przejĈè, aby uzy-
skaè dostöp do systemu. Uwierzytelnianie zostaäo symbolicznie przedstawione na rysunku 2.4.

Rysunek 2.4. Wadliwe uwierzytelnianie

Czym jest czynnik uwierzytelniania?

Czynnik uwierzytelniania to pewna informacja wykorzystywana do potwierdzenia toĔsa-
moĈci osoby. Czterema najlepiej znanymi i najczöĈciej stosowanymi czynnikami uwierzytel-
niania sñ:

Rozdzia

ĥ 2. Bezpieczeħstwo aplikacji internetowych

coĈ, co uĔytkownik zna, na przykäad hasäo lub kod;

coĈ, co uĔytkownik ma, na przykäad karta kredytowa lub specjalne urzñdzenie sprzötowe
(tak zwany token);

coĈ zwiñzanego z samñ osobñ uĔytkownika, na przykäad odcisk palca, wzór siatkówki
oka lub inne cechy biometryczne;

miejsce przebywania, na przykäad fizyczna lokalizacja uĔytkownika.

Informacje uwierzytelniaj

éce

W przypadku aplikacji internetowych najczöĈciej stosowanymi informacjami uwierzytelniajñ-
cymi sñ nazwa uĔytkownika i hasäo. Istniejñ pewniejsze metody uwierzytelniania, takie jak
cechy biometryczne lub certyfikaty cyfrowe, niemniej jednak ich koszt jest zbyt duĔy, by sto-
sowaè je w aplikacjach internetowych.

Zdecydowanie  najwaĔniejsze  jest,  by  system  uwierzytelniania  byä  bezpieczny.  Nawet  dobre
mechanizmy  uwierzytelniania  mogñ  zostaè  przeäamane  w  efekcie  wystñpienia  bäödu,  zasto-
sowania  niewäaĈciwej  konfiguracji,  braku  dostöpu  (na  przykäad  do  bazy  danych  z  informa-
cjami uwierzytelniajñcymi), nieodpowiedniego zarzñdzania nazwñ uĔytkownika i hasäem do-
stöpu i tak dalej.

Interfejsy administracyjne

PoniewaĔ interfejsy administracyjne majñ duĔe moĔliwoĈci i mogñ wykonywaè operacje
wymagajñce wyĔszych uprawnieþ, naleĔy je lepiej ochraniaè. Na przykäad moĔna zastosowaè
dodatkowe czynniki uwierzytelniania. Optymalnym rozwiñzaniem jest zastosowanie co naj-
mniej dwóch czynników. Rysunek 2.5 pokazuje sposób obsäugi sesji przy wykorzystaniu
identyfikatora sesji oraz cookie.

Rysunek 2.5. Obsäuga sesjami

ýsto spotykane sĥabe punkty aplikacji internetowych

Obs

ĥuga sesji

Czy pamiötasz, Ĕe protokóä HTTP jest bezstanowy? Oznacza to, Ĕe nie jest on wyposaĔony
w mechanizmy obsäugi sesji. Obsäuga sesji zostaäa dodana do aplikacji internetowych oraz
serwerów aplikacji jako sposób pozwalajñcy na zachowanie stanu. Czösto siö jednak zdarza,

Ĕe programiĈci sami obsäugujñ zarzñdzanie stanem.

Serwery udostöpniajñ ograniczone mechanizmy obsäugi sesji, które zazwyczaj bazujñ na wy-
korzystaniu nagäówków HTTP oraz cookies. Sesje naleĔy jednak traktowaè jako obiekty
chronione, a otrzymanie sesji przez uĔytkownika powinno byè poprzedzone jego uwie-
rzytelnieniem.

A zatem poczñtek sesji powinien byè wyznaczany przez uwierzytelnienie. W rzeczywistoĈci
w ogóle nie naleĔy tworzyè sesji, jeĈli uĔytkownik nie zostaä uwierzytelniony.

Po przeprowadzeniu uwierzytelnienia system musi zapewniè, Ĕe gdy uĔytkownik ponownie
odwiedzi aplikacjö, zostanie rozpoznany bez koniecznoĈci ponownego uwierzytelniania. Nie-
stety, wiökszoĈè systemów internetowych wykorzystuje do tego celu cookies. Aplikacja tworzy
cookie zawierajñce identyfikator uĔytkownika. Identyfikator ten pozwala, by w przyszäoĈci,
w momencie nadesäania nowego Ĕñdania, zostaäo ono powiñzane z sesjñ uĔytkownika.

Koniecznie naleĔy zrozumieè i zapamiötaè, Ĕe po udanym przeprowadzeniu uwie-
rzytelniania wykorzystujñcego dwa czynniki (takie, jak identyfikator uĔytkownika i hasäo)
kolejne Ĕñdania bödñ obsäugiwane na podstawie tylko jednego czynnika uwierzytel-
niania — identyfikatora uĔytkownika.

NaleĔy zauwaĔyè, Ĕe ze wzglödu na bezstanowy charakter protokoäu HTTP caäa komu-
nikacja z klientem (bñdĒ przeglñdarkñ) powinna byè realizowana przy wykorzystaniu bez-
piecznego kanaäu, takiego jak HTTPS (SSL/TLS). Jest to konieczny warunek zachowania
integralnoĈci cookie przechowujñcego identyfikator uĔytkownika oraz wszystkich przesyäanych
danych.

Nie pozwalaj na ponowne wizyty starych go

ļci

Czösto systemy uwierzytelniania aplikacji sñ tworzone w taki sposób, by rozpoznawaäy
uĔytkowników odwiedzajñcych aplikacjö po däuĔszym czasie. Nie naleĔy jednak wpuszczaè
uĔytkownika do aplikacji tylko i wyäñcznie dlatego, Ĕe kiedyĈ siö do niej zalogowaä.

JeĈli sesja uĔytkownika wygasäa lub jeĈli od ostatniej wizyty uĔytkownika minñä däuĔszy
okres, naleĔy ponownie go uwierzytelniè.

Ataki typu cross-site scripting (XSS)

Ataki typu cross-site scripting (w skrócie: XSS) wykorzystujñ säabe punkty aplikacji interne-
towych, uĔywajñc przy tym danych dostarczonych przez atakujñcego, które w dynamiczny
sposób zostajñ wyĈwietlone w przeglñdarce uĔytkownika. Dane dostarczane przez napastni-
ków przybierajñ zazwyczaj formö skryptów i sñ wykonywane w przeglñdarce uĔytkownika.
Sposób przeprowadzania ataków typu cross-site scripting z wykorzystaniem odbitych oraz
zachowanych danych przedstawiono na rysunku 2.6.

Rozdzia

ĥ 2. Bezpieczeħstwo aplikacji internetowych

Rysunek 2.6. Atak typu cross-site scripting

Zazwyczaj  ataki  XSS  przybierajñ  jednñ  z  dwóch  form:  ataku  z  wykorzystaniem  danych  za-
chowanych lub odbitych. W przypadku  ataku  z  wykorzystaniem  danych  zachowanych  ata-
kujñcy  zapisuje  swój  skrypt  na  serwerze  (na  przykäad  w  bazie  danych).  PóĒniej,  gdy  ofiara
odwiedzi witrynö WWW, w dynamiczny sposób wyĈwietli ona zachowany zäoĈliwy kod, co
spowoduje przeprowadzenie ataku. Z kolei atak z wykorzystaniem danych odbitych polega
na  tym,  Ĕe  atakujñcy  wstawia  swój  skrypt  do  zmiennej  Ĕñdania  lub  parametru  äaþcucha
zapytania i przekazuje äñcze do ofiary.

Ataki XSS pozwalajñ napastnikom takĔe na wyĈwietlanie w przeglñdarce wybranej zawartoĈci
HTML, wykonywanie w przeglñdarce dowolnych skryptów (napisanych w jözyku JavaScript
lub VB Script) oraz umieszczanie na stronach zäoĈliwego kodu (takiego, jak aplety, kontrolki
ActiveX lub Flash). Ataki tego typu mogñ powodowaè niezamierzone ujawnienie danych,
doprowadziè do zniszczenia witryny WWW, pozwalaè na przechwytywanie sesji, przejmowanie
toĔsamoĈci i zasobów konta, podszywanie siö oraz uniemoĔliwianie obsäugi innych Ĕñdaþ.

Jeszcze innym sposobem przeprowadzania ataków XSS jest wykorzystanie serwera WWW
oraz jego domyĈlnych stron i mechanizmów obsäugi bäödów. Czösto zdarza siö, Ĕe serwery
WWW oraz serwery aplikacji wyĈwietlaj

ñ na stronach informujñcych o bäödach dane przeka-

zane w Ĕñdaniu. JeĈli atakujñcemu uda siö umieĈciè kod XSS w Ĕñdaniu, a serwer umieĈci go
na stronie informacyjnej i zwróci do uĔytkownika, to taka strona informacyjna moĔe staè siö
narzödziem do przeprowadzania ataków.

Wiele witryn ma säabe punkty pozwalajñce na przeprowadzanie ataków XSS. Zapewne dla-
tego jest to obecnie najczöĈciej spotykany typ ataków na aplikacje internetowe. Usterki i säabe
punkty pozwalajñce na stosowanie ataków XSS moĔna wykorzystywaè na wiele róĔnych
sposobów. ProgramiĈci, którzy próbujñ filtrowaè i odrzucaè zäoĈliwe czöĈci Ĕñdania, äatwo
mogñ przegapiè potencjalne ataki, które na przykäad wykorzystujñ nowe sposoby kodowania.

ýsto spotykane sĥabe punkty aplikacji internetowych

PopularnoĈè ataków XSS ma jednak takĔe swojñ pozytywnñ stronö. OtóĔ powstaäo wiele na-
rzödzi uäatwiajñcych wykrywanie säabych punktów aplikacji, które mogäyby zostaè wykorzy-
stane do przeprowadzenia ataku.

Najlepszym i najbezpieczniejszym rozwiñzaniem, jakie moĔna zastosowaè, jest kodowanie
wszystkich dynamicznych danych przed ich przesäaniem do przeglñdarki. W takim przy-
padku caäy kod skryptowy zostanie potraktowany jako tekst, a przeglñdarka, zamiast go wy-
konaè, wyĈwietli go.

Przepe

ĥnienie bufora

Przepeänienie bufora jest zapewne najlepiej znanym problemem wystöpujñcym we wszelkie-
go typu aplikacjach komputerowych. NajczöĈciej wystöpuje ono w aplikacjach, które samo-
dzielnie zarzñdzajñ pamiöciñ oraz zasobami i wykorzystujñ dane wejĈciowe, których däugoĈè
i typ nie zostaäy sprawdzone. Atak polegajñcy na przepeänieniu bufora zostaä przedstawiony
na rysunku 2.7.

Rysunek 2.7. Przepeänienie bufora

Usterki umoĔliwiajñce przeprowadzenie ataków tego typu jest trudno wykryè, gdyĔ zazwy-
czaj wystöpujñ one wyäñcznie w sytuacji, gdy aplikacja znajduje siö w ĈciĈle okreĈlonym
stanie.

Na przykäad klasyczny scenariusz przeprowadzenia ataku wykorzystujñcego przepeänienie
bufora polega na tym, Ĕe atakujñcy znajduje obszar, w którym aplikacja nie sprawdza däugo-
Ĉci zapisanych danych. Nastöpnie atakujñcy umieszcza w nim wartoĈè, której däugoĈè prze-
kracza wielkoĈè obszaru przydzielonego przez aplikacjö. W efekcie dane umieszczone na sto-
sie wywoäaþ zostajñ nadpisane przez dane podane przez napastnika, który zyskuje w ten
sposób moĔliwoĈè okreĈlenia, gdzie zostanie przekazane sterowanie.

W ten sposób atakujñcy moĔe wykonywaè dowolne operacje w systemie, wykorzystujñc przy
tym uprawnienia, jakie miaä zaatakowany program.

Czasami usterki umoĔliwiajñce dokonanie ataku tego typu sñ ukryte gäöboko w kodzie.
Zazwyczaj wystöpujñ one dlatego, Ĕe programista dokonaä pewnych zaäoĔeþ co do däugoĈci
danych i z jakiegoĈ wzglödu zrezygnowaä z ich weryfikacji.

Rozdzia

ĥ 2. Bezpieczeħstwo aplikacji internetowych

Przepe

ĥnienie bufora w aplikacjach internetowych

Aplikacje internetowe nie sñ odporne. Atakujñcy mogñ w nich przesyäaè „zäoĈliwñ” zawar-
toĈè przy wykorzystaniu formularzy, a jeĈli aplikacja nie bödzie sprawdzaè typów i däugoĈci
odbieranych danych, to takĔe moĔe paĈè ofiarñ ataku typu przepeänienie bufora.

Usterki umoĔliwiajñce przeprowadzenie ataku tego typu mogñ byè umiejscowione w samej
aplikacji, serwerze WWW bñdĒ serwerze aplikacji. W koþcu serwery wykonujñ oprogramo-
wanie pisane przez programistów, którzy zawsze robiñ jakieĈ zaäoĔenia.

MoĔe siö okazaè, Ĕe usterka nie jest nawet zlokalizowana w kodzie, do którego ma dostöp
twórca aplikacji — moĔe siö ona znajdowaè w którejĈ z uĔywanych bibliotek lub kompo-
nentów.

Dlatego tak waĔne jest sprawdzanie typów oraz däugoĈci wszystkich odbieranych danych
przed ich przekazaniem do innego kodu wykonywanego na serwerze.

Usterki zwi

ézane ze wstawianiem

Usterki zwiñzane ze wstawianiem wystöpujñ w sytuacji, gdy aplikacja pobiera niezweryfi-
kowane dane wejĈciowe i zapisuje je w zmiennych, uĔywanych nastöpnie do uzyskania do-
stöpu i korzystania z innych zasobów systemowych, takich jak bazy danych SQL, polecenia
systemowe oraz inne programy. RóĔne rodzaje ataków polegajñcych na wstawianiu zostaäy
przedstawione na rysunku 2.8.

Rysunek 2.8. RóĔne typy ataków polegajñcych na wstawianiu

PoniewaĔ do zmiennych dodawane sñ niezweryfikowane dane wejĈciowe, atakujñcy moĔe
zmieniè te dane w dowolny sposób, okreĈlajñc w ten sposób informacje, które zostanñ póĒniej
przekazane do systemu operacyjnego bñdĒ innego programu. Za kaĔdym razem, gdy aplika-
cja uĔywa dowolnego zasobu interpretera lub systemu operacyjnego, jest naraĔona na prze-
prowadzenie ataku polegajñcego na wstawianiu.

Szczególnie naraĔone na takie ataki sñ funkcje zewnötrzne, takie jak wysyäanie poczty elek-
tronicznej lub korzystanie z baz danych przy wykorzystaniu zapytaþ SQL. Ataki polegajñce
na wstawianiu moĔna wykrywaè w prosty sposób. W Internecie moĔna znaleĒè wiele
skryptów i programów, które robiñ to automatycznie.

ýsto spotykane sĥabe punkty aplikacji internetowych

Niew

ĥaļciwa obsĥuga bĥýdów

Nawet w przypadku, gdy w naszej aplikacji wydarzy siö jakaĈ awaria, musimy zwróciè
uwagö, by nie zdradziè zbyt wielu informacji o uĔywanym Ĉrodowisku. KaĔda informacja,
jakñ zdobödzie napastnik, moĔe zwiökszyè moĔliwoĈè przeprowadzenia pomyĈlnego ataku.

Podczas pracy w Ĉrodowisku roboczym, przed wdroĔeniem aplikacji w Ĉrodowisku produk-
cyjnym, kaĔdy chce wiedzieè, gdzie wystöpujñ problemy i usterki; dlatego teĔ tworzone sñ
wszelkiego rodzaju dzienniki i kod testujñcy, uäatwiajñcy wykrywanie problemów. Kiedy
jednak kod aplikacji bödzie juĔ gotów do umieszczenia w Ĉrodowisku produkcyjnym, wszelki
kod testujñcy powinien byè usuniöty.

JeĈli programista zapomni usunñè z aplikacji kod testujñcy, w przeglñdarce mogñ byè wy-
Ĉwietlane informacje o bäödach oraz zrzuty stosu wywoäaþ. Zarówno komunikaty o bäödach,
jak i zrzuty stosu wywoäaþ mogñ dostarczyè napastnikom bardzo cennych informacji. Dziöki
nim napastnik moĔe poznaè kluczowe szczegóäy dotyczñce stosowanej infrastruktury: nazwy
zmiennych i metod, schemat przepäywu danych i tak dalej.

Komunikaty o bäödach naleĔy skonfigurowaè w taki sposób, by prezentowaäy jedynie te in-
formacje, które powinny dotrzeè do uĔytkownika. WiökszoĈè serwerów WWW oraz serwe-
rów aplikacji zawiera grupö domyĈlnych stron z informacjami o bäödach oraz narzödzi po-
mocnych przy testowaniu aplikacji. Zarówno te domyĈlne strony, jak i narzödzia mogñ jednak
ujawniè szczegóäowe informacje o Ĉrodowisku, w którym aplikacja jest wykonywana. Infor-
macje tego typu sñ nieocenione dla osób przygotowujñcych ataki. JeĈli uĔytkownik planujñcy
atak na aplikacjö uzyska moĔliwoĈè przeglñdania komunikatów o bäödach, tworzonych, by
uäatwiè jej testowanie (takich, jak informacje o wyjñtkach i postaè stosu wywoäaþ), to bödzie
mógä wykorzystaè te informacje do dokäadniejszego wybrania miejsca ataku oraz okreĈlenia
sposobu, w jaki naleĔy go przeprowadziè.

Kolejnym Ēródäem problemów sñ sytuacje, w których atakujñcy jest w stanie doprowadziè do
wystñpienia bäödu w aplikacji, który pozwoli mu ominñè pewne jej kluczowe mechanizmy
(na przykäad uwierzytelnianie lub kontrolö dostöpu). Sytuacja taka wystöpuje, gdy aplikacja
reaguje pozytywnie na wystñpienie problemu. W przypadku implementacji mechanizmów
zabezpieczeþ, takich jak uwierzytelnianie lub kontrola dostöpu, znacznie lepszym rozwiñza-
niem jest tworzenie kodu, który w razie jakichkolwiek problemów nie bödzie zezwalaä uĔyt-
kownikowi na dostöp do aplikacji. Wszystkie mechanizmy zwiñzane z zabezpieczeniami
powinny odmawiaè dostöpu aĔ do momentu pomyĈlnego uwierzytelnienia uĔytkownika
oraz okreĈlenia jego uprawnieþ.

PoniĔszy listing demonstruje, w jaki sposób nieprawidäowo napisany kod obsäugi bäödów
moĔe doprowadziè do bäödnego dziaäania mechanizmu uwierzytelniania:

authenticated = true;
try {
if (authenticateUser(user, password) {
// u

Īytkownik zostaá uwierzytelniony

    authenticated = true;
  } else {
    // u

Īytkownik nie zostaá uwierzytelniony

    authenticated = false;
  }
} catch (Exception e) {
  System.out.print("B

Īîd uwierzytelniania: " + e.message());

}

Rozdzia

ĥ 2. Bezpieczeħstwo aplikacji internetowych

JeĈli w metodzie

authenticateUser()

zostanie zgäoszony wyjñtek, bödzie moĔna kontynu-

owaè uwierzytelnianie, gdyĔ sam test okreĈlajñcy, czy uĔytkownik powinien byè uwierzytel-
niony, czy nie, zostanie pominiöty.

Bezpiecznie obsäuguj sytuacje awaryjne. JeĈli jakiĈ warunek moĔe doprowadziè do
awarii aplikacji lub sprawiè, Ĕe jakaĈ jej czöĈè nie zostanie wykonana prawidäowo,
upewnij siö, Ĕe domyĈlny stan, w jakim znajdzie siö aplikacja, bödzie bezpieczny.

Kod  obsäugi  bäödów  implementowany  w  mechanizmach  zwiñzanych  z  zabezpieczeniami
aplikacji  powinien  byè  takĔe  znacznie  bardziej  podejrzliwy.  To  wäaĈnie  nim  hackerzy  bödñ
najbardziej  zainteresowani.  Ze  wzglödu  na  znaczenie  funkcjonalnoĈci  zwiñzanej  z  uwierzy-
telnianiem  i  kontrolñ  dostöpu  moĔna  przypuszczaè,  Ĕe  napastnicy  znacznie  czöĈciej  bödñ
próbowali wywoäywaè bäödy wäaĈnie w tych, a nie innych fragmentach aplikacji. Z tych sa-
mych  powodów  mechanizmy  zabezpieczeþ  powinny  znacznie  czöĈciej  korzystaè  z  dzienni-
ków. W ich przypadku naleĔy rejestrowaè absolutnie wszystko! Rejestracja bäödów w kodzie
zwiñzanym  z  zabezpieczeniami  aplikacji  ma  kluczowe  znaczenie,  jeĈli  zaleĔy  nam  na  two-
rzeniu dobrych i przydatnych dzienników. W koþcu po udanym ataku dziennik moĔe byè
wszystkim, co nam pozostanie.

Niebezpieczne mechanizmy przechowywania

Aplikacje  zazwyczaj  muszñ  przechowywaè  wraĔliwe  dane  lub  informacje.  W  niektórych
przypadkach przechowywane dane (które w danej chwili nie sñ uĔywane) wymagajñ dodat-
kowego zabezpieczenia. Takie informacje, jak hasäa, numery ubezpieczeþ spoäecznych czy kart
kredytowych,  wymagajñ  takich  zabezpieczeþ,  by  nie  moĔna  ich  byäo  wykorzystaè,  jeĈli  zo-
stanñ  przypadkowo  znalezione  w  systemie.  W  takich  przypadkach  najczöĈciej  stosowanym
rozwiñzaniem jest uĔycie szyfrowania.

ChociaĔ mechanizmy kontroli dostöpu staäy siö stosunkowo äatwe do zaimplementowania
i uĔycia, programiĈci i tak zazwyczaj popeäniajñ bäödy podczas stosowania ich w aplikacjach
internetowych. ProgramiĈci mogñ przeceniaè poziom ochrony, jaki zapewnia szyfrowanie,
i nie przykäadaè odpowiedniej wagi do wykorzystania innych mechanizmów zabezpieczeþ.

OWASP wskazuje czösto popeäniane bäödy:

caäkowitñ rezygnacjö z szyfrowania krytycznych danych;

zastosowanie niewäaĈciwych sposobów przechowywania kluczy, certyfikatów i haseä;

niewäaĈciwñ konfiguracjö;

zastosowanie niewäaĈciwych sposobów przechowywania tajnych danych w pamiöci;

säabe generatory liczb pseudolosowych;

niewäaĈciwy dobór algorytmów;

próby wymyĈlania nowych algorytmów szyfrujñcych;

rezygnacjö z implementacji mechanizmów zmiany kluczy szyfrujñcych oraz innych wy-
maganych procedur pielögnacyjnych.

ýsto spotykane sĥabe punkty aplikacji internetowych

JeĈli zastosowane mechanizmy szyfrowania zostanñ przeäamane, bezpieczeþstwo danych bö-
dzie zagroĔone. Dlatego teĔ poprawna konfiguracja oraz efektywne zarzñdzanie mechani-
zmami szyfrowania majñ kluczowe znaczenie dla bezpieczeþstwa aplikacji.

Odmowa dzia

ĥania aplikacji

Czasami nie mamy kontroli nad niektórymi zdarzeniami. Doskonale sobie radzimy. Prowa-
dzimy fantastycznñ, nowñ witrynö WWW. Jest ona na tyle interesujñca, Ĕe ktoĈ zamieĈciä in-
formacjö o niej w popularnym serwisie agregujñcym, takim jak Digg. I nagle BUM! Nasz
niewielki serwer umieszczony w piwnicy zawiesza siö z powodu nawaäu Ĕñdaþ od osób ze
wszystkich stron Ĉwiata, które nagle chcñ obejrzeè naszñ witrynö.

Innym razem jakiĈ napastnik moĔe znaleĒè sposób na to, by aplikacja korzystaäa z coraz to
wiökszej iloĈci zasobów systemowych — pamiöci, dysku itp. — i zuĔywaäa je aĔ do momen-
tu, gdy serwer nie bödzie w stanie dalej obsäugiwaè nadsyäanych Ĕñdaþ. Niestety, czasami
bödziemy musieli zastosowaè efektywne metody rozróĔniania, co jest atakiem, a co zwyczajnym
ruchem na witrynie. Atak poprzez odmowö obsäugi zostaä przedstawiony na rysunku 2.9.

Rysunek 2.9. Odmowa obsäugi

Czytaj dalej...

Rozdzia

ĥ 2. Bezpieczeħstwo aplikacji internetowych

Problem  ten  jest  dodatkowo  komplikowany  przez  wiele  innych  czynników,  takich  jak  bez-
stanowoĈè  protokoäu  HTTP  oraz  brak  pewnoĈci,  Ĕe  danym  przesyäanym  w  Ĕñdaniu  moĔna
zaufaè.  Czynniki  te  powodujñ,  Ĕe  znacznie  trudniej  jest  odnajdywaè  niebezpieczne  Ĕñdania,
na przykäad na podstawie przesyäanych w nich informacji, takich jak adres IP, i odrzucaè je.

Najpopularniejsze zasoby, które moĔna wykorzystaè do przeprowadzenia ataku tego typu, to:

pamiöè,

przepustowoĈè,

uchwyty plików,

poäñczenia z bazñ danych,

wñtki,

mechanizmy rejestracji danych w dziennikach,

pojemnoĈè obszaru przeznaczonego do przechowywania plików lub danych.

Kiedy atakujñcy znajdzie sposób, by wykorzystaè wszystkie lub tylko niektóre spoĈród wy-
maganych zasobów, bödzie w stanie uniemoĔliwiè korzystanie z systemu normalnym uĔyt-
kownikom.

Na przykäad, jeĈli witryna pozwala nieuwierzytelnionym uĔytkownikom pobieraè informacje
o ruchu na forach dyskusyjnych, to dla jednego Ĕñdania HTTP moĔe byè tworzonych wiele
poäñczeþ z bazñ danych. Atakujñcy bez wiökszych problemów moĔe wygenerowaè na tyle
wiele Ĕñdaþ, by w caäoĈci wyczerpaè dostöpnñ pulö poäñczeþ z bazñ danych. W takim przy-
padku zabraknie poäñczeþ do obsäugi Ĕñdaþ normalnych uĔytkowników witryny.

Inny typ ataku moĔe polegaè na celowym generowaniu wyjñtku w celu zapisywania infor-
macji o nim w pliku dziennika systemowego. W ten sposób plik dziennika moĔe rosnñè aĔ do
wyczerpania siö caäego wolnego miejsca na dysku.

Istniejñ setki róĔnych sposobów przeprowadzania ataków polegajñcych na odmowie obsäugi,
a wiökszoĈè z nich moĔna bez trudu przeprowadziè przy wykorzystaniu kilku wierszy kodu.
Choè nie ma Ĕadnej metody pozwalajñcej pewnie zabezpieczyè siö przed tymi atakami, to
jednak moĔna utrudniè ich przeprowadzanie i zmniejszyè ich skutecznoĈè.

Niebezpieczne zarz

édzanie konfiguracjé

WäaĈciwa konfiguracja ma kluczowe znaczenie dla bezpieczeþstwa dziaäajñcej aplikacji inter-
netowej.

Konfiguracja aplikacji, jak równieĔ konfiguracja serwera i zasobów systemowych, musi byè
odpowiednio przygotowana. Bardzo czösto programiĈci skäadajñ odpowiedzialnoĈè za przy-
gotowanie konfiguracji Ĉrodowiska serwera na barki administratorów. Choè moĔe siö wyda-
waè, Ĕe takie rozwiñzanie jest prawidäowe, to jednak programiĈci nie mogñ caäkowicie unik-
nñè zajmowania siö konfiguracjñ.

Aplikacje internetowe sñ w tak wielkim stopniu zaleĔne od warstwy internetowej oraz war-
stwy serwera aplikacji, Ĕe trzeba przeanalizowaè ich konfiguracjö, aby uzyskaè pewnoĈè, iĔ
Ĉrodowisko aplikacji faktycznie jest bezpieczne.