Bezpieczeństwo – Ochrona WWW

Opracował: Zbigniew Suski

1

Ochrona WWW

Główne zagadnienia wykładu

Wymagania związane z ochroną WWW dotyczą przede wszystkim tworzenia bezpiecznego, uwierzytelnionego

połączenia między klientem WWW i serwerem. W tej chwili system WWW nie jest wolny od zagrożeń. Należą do nich:

•

Wykorzystywanie

błędów programowych serwera WWW i skryptów CGI

1

do uzyskania nielegalnego dostępu do plików

systemu, a nawet przejęcia kontroli nad całym systemem.

•

Wydostawanie

się poufnych informacji z serwera WWW do nieupoważnionych użytkowników.

•

Przechwytywanie poufnych danych przesyłanych pomiędzy serwerem i przeglądarką.

•

Przechwytywanie poufnych danych z komputera, na którym działa przeglądarka WWW do fałszywego serwera WWW.

•

Ujawnianie

się usterek w programach pisanych na zamówienie Niektóre firmy mając na względzie ujawnione niedo-

skonałości pakietów standardowych, zamawia rozwiązania niestandardowe.

Serwery WWW są przeznaczone do odpowiadania na anonimowe żądania z różnych komputerów. Ich konstruk-

cja powoduje, że mogą być wykorzystywane w sposób legalny jak i nielegalny. Kody źródłowe serwerów WWW są często
dostępne, co umożliwia dokładne ich badanie i znajdowanie słabych punktów.

Identyfikator UID serwera WWW

Większość serwerów WWW wymaga uruchomienia przez superużytkownika. Aby mógł nasłuchiwać w porcie 80

musi mieć identyfikator root. Po uruchomieniu zmienia UID na wartość podaną w pliku konfiguracyjnym (dla serwera
NCSA jest to plik conf/httpd/conf). Użytkownikiem wpisanym w tym pliku powinien być użytkownik nie mający żadnych
specjalnych uprawnień w systemie. Jeżeli jakieś skrypty mają być uruchamiane z UID=root, to powinien należeć do supe-
rużytkownika i mieć ustawiony SUID.

Katalogi serwera WWW

Serwery WWW korzystają z wielu plików w wielu katalogach. Zawartość niektórych katalogów jest udostępniana

użytkownikom sieci. Zawartość innych nie może być udostępniana. Nie powinna być również dostępna do odczytu użyt-
kownikom lokalnym. Dotyczy to również niektórych plików (np. konfiguracyjnych).

Przykładowo serwer NCSA korzysta z następujących katalogów:

•

skryptów CGI (cgi-bin),

•

plików konfiguracyjnych serwera (conf),

•

dokumentów

WWW

(htdocs i icons),

•

rejestrów

aktywności serwera (logs),

•

pomocniczych programów serwera (support).

Opcje które można włączać i wyłączać:

•

Automatyczne listingi katalogów. Jeżeli w katalogu nie ma pliku index.html, to jego zawartość jest przez

większość serwerów wyświetlana (niebezpieczna możliwość podglądania).

•

Łącza symboliczne. Niektóre serwery pozwalają na przechodzenie przy pomocy łącz symbolicznych do miejsc

znajdujących się poza katalogami dokumentów. Zwykle możliwe jest wówczas zablokowanie udostępniania
takich miejsc jeżeli właściciel łącza nie jest jednocześnie właścicielem udostępnianego przy jego pomocy
miejsca.

•

Dyrektywy "include". Powodują włączenie plików po stronie serwera. Możliwość użycia takich dyrektyw musi

być w specjalny sposób uruchomiona, Domyślnie jest zablokowana.

Sterowanie dostępem do plików serwera WWW

Potrzeba ograniczania dostępu do plików serwera WWW może być podyktowana chęcią używania serwera

WWW do przesyłania danych wewnętrznych (podręczniki, przepisy, książki adresowe). Większość serwerów używa
trzech podstawowych technik sterowania dostępem do plików i katalogów:

•

ograniczanie

dostępu do określonych adresów IP, podsieci, domen, (możliwe fałszowanie pakietów, podrabia-

nie systemu DNS)

•

ograniczanie dostępu do określonego zbioru użytkowników (dane o użytkownikach są zwykle przesyłane w

postaci otwartej)

•

ograniczanie

dostępu do użytkowników, którzy przedstawiają klucze publiczne podpisane przez odpowiednie

organizacje certyfikujące (tylko serwery wyposażone w programy kryptografii publicznej).

W serwerze NCSA globalne informacje o ograniczeniach są umieszczane w pliku conf/access.conf. Ograniczenia moż-
na również umieścić w osobnych plikach dla poszczególnych katalogów. Nazwy tych plików określa się w parametrze

1

Common Gateway Interface (CGI) jest protokołem umożliwiającym tworzenie programów, które mogą być dowiązywane do stron WWW. Przykładem

są liczniki użytkowników odwiedzających stronę.

Bezpieczeństwo – Ochrona WWW

Opracował: Zbigniew Suski

2

Access File Name w pliku conf/srm.conf. Domyślna nazwa pliku z ograniczeniami dla poszczególnych katalogów to
.htaccess. Ograniczenia rozproszone umożliwiają przenoszenie katalogów bez aktualizacji listy ograniczeń. Nie trzeba
również restartować serwera WWW. W niektórych serwerach występuje błąd, który umożliwia pobranie plików .htaccess
przez podanie do nich adresu URL. W ten sposób nieupoważnieni użytkownicy mogą poznać szczegóły systemu autory-
zacji. Dlatego dobrze jest zmienić nazwy plików.

Wiersze ograniczeń:
order
Porządek deny,allow - najpierw sprawdzane warunki deny. Hosty spełniające oba typu warunków są przyjmowane.
Porządek allow,deny - najpierw sprawdzane warunki allow. Hosty spełniające oba typu warunków są odrzucane.
Porządek mutual-failure - hosty na liście allow są przyjmowane. Hosty na liście deny lub obu są odrzucane.

allow deny - listy hostów
require user, require group, require valid-user - udzielanie dostepu użytkownikom lub grupom. Ostatnia opcja do-
puszcza wszystkich użytkowników
Plik haseł można utworzyć przy pomocy programu htpasswd z opcją c
Dodawanie użytkowników realizuje się bez opcji (gdyż inaczej poprzedni użytkownicy zostaną usunięci).
Plik haseł nie powinien być dostępny dla zwykłych użytkowników. Jego położenie określa się poleceniem AuthUserFile w
pliku ograniczeń.

Podsłuch w systemach WWW

Ryzyko podsłuchu jest ma szczególne znaczenie w systemie WWW ze względu na przesyłanie poufnych infor-

macji takich jak np. numery kart kredytowych. Zabezpieczenie polega na wykorzystaniu fizycznie zabezpieczonej sieci
(czyli nie Internet) lub szyfrowaniu przesyłanych danych.

Podsłuch można również realizować poprzez analizę ruchu. Takie działanie polega na zdobywaniu informacji o

transakcjach wykonywanych przez system, bez wnikania w ich treść.

Sposoby szyfrowania wysyłanych danych:
Szyfrowanie łącza - można zastosować szyfrujące routery, automatycznie kodujące dane. Oznacza to szyfrowanie całej

komunikacji. Wymagane jest więc zgodne skonfigurowanie sprzętu.

Szyfrowanie dokumentów - dokumenty pobierane z serwera mogą być szyfrowane za pomocą dowolnego systemu (np.

PGP). Jest to sposób efektywny, ale nieco kłopotliwy.

SSL (Secure Socket Layer) - system opracowany przez Netscape Communications umożliwiający utworzenie zaszyfro-

wanego łącza pomiędzy dwoma hostami. Może być wykorzystany do szyfrowania protokołów TCP/IP takich jak

Sterowanie dostępem do serwera WWW

Plik

srm.conf

#AccessFilename

nazwa pliku z ograniczeniami

#

dostępu do katalogów

AccessFileName .xyz

acces.conf

.htacces

<directory /nsa/man>

<limit GET>

<limit GET>

order deny,allow

order deny,allow

deny from all

deny from all

allow from 129.128.15

allow from .pjw.waw.pl.

require user jasio zosia

</limit>

</limit>

</directory>

Konfigurowanie kont i zakładanie haseł

#./htpasswd -c /usr/loc/httpd/auth jasio
Adding password for jasio
New password: tomy489
Re-type new password: tomy489

Bezpieczeństwo – Ochrona WWW

Opracował: Zbigniew Suski

3

HTTP, TELNET czy FTP. SSL może wykorzystywać różne klucze publiczne i różnych systemów wymiany klucza
sesyjnego. Aktualnie programy korzystające z SSL dostępne przez anonimowe FTP lub sprzedawane, używają
kluczy 40-bitowych. Po obu stronach (serwera i przeglądarki) wymagane jest stosowanie specjalnego oprogra-
mowania

SHTTP (Secure HTTP) - system kryptograficzny dla protokołu HTTP opracowany przez Commerce Net.

W przypadku używania protokołu szyfrującego bezpieczeństwo zależy od:

•

mocy

algorytmu

szyfrującego,

•

długości klucza szyfrującego,

•

tajności klucza szyfrującego,

•

niezawodności oprogramowania działającego na serwerze WWW,

•

niezawodności oprogramowania działającego na przeglądarce WWW,

Większość systemów WWW tworzy pliki rejestrów, gromadzące dane dotyczące zgłaszanych żądań. Dla serwera httpd
NCSA są to np.:

•

lista

dostępów do serwera (access_log),

•

lista programów używanych do uzyskania dostępu (agent_log),

•

rejestr

błędów napotkanych przez serwer - np. błędy CGI (error_log),

•

adresy

URL

odwiedzone przez przeglądarkę (refer_log).

Informacje pamiętane w liście dostępów:

•

nazwa komputera, który zainicjował transfer,

•

nazwa

użytkownika (jeżeli występuje),

•

czas inicjacji transferu (data, godzina, przesunięcie strefy czasowej),

•

wykonane

polecenie:

−

GET pobieranie plików,

−

POST przetwarzanie formularzy,

−

HEAD przeglądanie nagłówków MIME.

•

zwrócony kod statusu,

•

liczba

przesłanych bajtów.

Użytkownicy powinni zdawać sobie sprawę z tego, że ich działania są monitorowane.

Inne problemy bezpieczeństwa związane z WWW

Większość przeglądarek ma funkcję powodującą automatyczne ładowanie odpowiednich aplikacji pomocniczych

podczas pobierania plików określonych typów. Programy pobierane w sieci nie powinny być uruchamiane automatycznie,
gdyż w ten sposób osobom z zewnątrz pozwala się na uruchamianie programów bez weryfikacji uprawnień (program
może być osadzony jako obrazek). Automatyczne uruchamianie programów Excel lub Word może spowodować uaktyw-
nienie wirusów makrowych.

Użytkownicy nie znają zwykle wszystkich funkcji przeglądarki. Jedna z funkcji Live Script (nowa postać języka

Java Script) w Netscape Navigatorze 2.0 beta umożliwiała uzyskanie z przeglądarki przez dowolny serwer WWW listy
adresów URL ostatni odwiedzanych przez nią miejsc. Usterka ta została usunięta. Co dzieje się teraz i co będzie się
działo się w przyszłości ???

Java umożliwia pobieranie aplikacji z systemu WWW. Aplikacje są uruchamiane dopiero po ich zaaprobowaniu

przez weryfikator przeglądarki. Model zabezpieczeń w Javie nakłada na programy duże ograniczenia. Programy mogą
uzyskiwać dostęp do sieci lub plików lokalnych, ale nie jednocześnie. Użytkownicy będą się prawdopodobnie domagać
modelu bardziej otwartego co doprowadzi do wystąpienia nowych problemów z zakresu bezpieczeństwa.

Certyfikacja w WWW

Przy przekazywaniu szczególnych danych pomiędzy serwisem WWW a przeglądarką należy być pewnym, że są

one zupełnie bezpieczne i nie dostaną się w niepowołane ręce. W zabezpieczeniach WWW ogromną rolę odgrywają
certyfikaty cyfrowe. Są to dokumenty elektroniczne używane w celu zidentyfikowania i zautoryzowania indywidualnych
uczestników połączenia. Certification Authority (CA) jest jednostką zaufaną odpowiedzialną za wydawanie cyfrowych
świadectw (certyfikatów) indywidualnym klientom jak i całym systemom. Takie świadectwo można zaprenumerować. Naj-
bardziej popularnym certyfikatem jest X.509. Został on zdefiniowany przez Internetional Telecommunication Union (ITU)
w 1989 jako standard certyfikatów kluczy publicznych. X.509 jest podzbiorem X.500 standardu systemów otwartych na
usługi katalogowe. Większość serwerów i przeglądarek WWW (m.in. Microsoft Internet Information Server, Netscape
Enterprise Server) dostarcza świadectwa X.509.
Zabezpieczenia WWW wymagają trzech rodzajów certyfikatów:

•

certyfikatu

CA,

Bezpieczeństwo – Ochrona WWW

Opracował: Zbigniew Suski

4

•

certyfikatu

przeglądarki,

•

certyfikatu

serwera.

Świadectwo CA identyfikuje CA i zawiera jego klucz publiczny. Świadectwo przeglądarki identyfikuje użytkownika korzy-
stającego z niej i zawiera jego klucz publiczny. Certyfikat serwera autoryzuje serwer WWW i zawiera jego klucz publiczny.

Niektóre protokoły używają certyfikatów WWW do zabezpieczenia bezpieczeństwa sesji. Takim protokołem jest

np. SSL. Używa on trzech świadectw: CA, przeglądarki i serwera.

Jeżeli użytkownik chce obejrzeć niejawne informacje udostępniane przez serwer, to jego przeglądarka i serwer mogą

użyć SSL do autoryzacji obojga i zachowania bezpieczeństwa sesji. Sesja jest chroniona poprzez mechanizm identyfika-
cji serwera i przeglądarki oraz szyfrowanie transmitowanych danych. W SSL występują trzy fazy:

•

autoryzacji

serwera,

•

autoryzacji

przeglądarki,

•

ustanowienia

sesji.

W fazie autoryzacji serwera przeglądarka prosi serwer o bezpieczną sesję poprzez podanie adresu

https://www.xyz.abc. W odpowiedzi serwer wysyła do przeglądarki swój certyfikat. Ta z kolei używa klucza publicznego
CA załączonego do świadectwa w celu zweryfikowania podpisu serwera. Do autoryzacji przeglądarki konieczne jest wy-
słanie jej świadectwa do serwera WWW. Serwer używając klucza publicznego przeglądarki (zawartego w jej certyfikacie),
weryfikuje dokument. W SSL weryfikacja przeglądarki jest opcjonalna. Po wzajemnej identyfikacji, przeglądarka jest zo-
bligowana do wygenerowania jednorazowego klucza symetrycznego. Jest to klucz sesji lub inaczej klucz główny. Prze-
glądarka szyfruje klucz sesji kluczem publicznym serwera i wysyła go do serwera. Ten deszyfruje klucz sesji korzystając z
własnego klucz prywatnego. Od tej chwili serwer i przeglądarka wykorzystują symetryczny klucz sesji do szyfrowania
przesyłanej pomiędzy nimi informacji.

Aby serwery i przeglądarki mogły skorzystać z protokołu SSL, CA musi rozesłać do nich swoje certyfikaty. Można

to zrealizować poprzez zezwolenie przeglądarkom na połączenie z tzw. interfejsem klienta w CA i ściągnięcie świadec-
twa. Można także przesłać klientom zbiór zawierający certyfikaty. Następnym krokiem jest wysłanie certyfikatu przeglą-
darki.

Certyfikat serwera uzyskuje się poprzez stworzenie pliku (klucza) prośby za pomocą odpowiedniego narzędzia do gene-
racji kluczy (np. Key Manager w IIS). Zbiór taki może zawierać identyfikatory serwera, adres poczty elektronicznej admi-
nistratora i klucz publiczny serwera. Administrator dołącza zawartość tego pliku do formularza certyfikatu serwera. Admi-
nistrator serwera może uzyskać świadectwo poprzez wykorzystanie interfejsu klienta i kopiowanie odpowiedniego frag-
mentu do pliku. Zbiór ten jest wykorzystywany do instalacji świadectwa na serwerze WWW.

Interfejs CGI (Common Gateway Interface)

?

?

?

?

?

?

?

?

Przepływ danych pomiędzy przeglądarką, serwerem i CGI
(A) - zwykłe CGI
(B) - CGI typu nph

Klient

Przeglądarka

WWW

Serwer

HTTP

Program

CGI

Pełna odpowiedź HTTP i sformatowane wyjście

(B)

Sformatowane wyjście

(A)

Wejście i zmienne

środowiskowe

Wejście za pomocą

formularza HTML

Odpowiedź HTTP

i wyjście CGI

(A)

Bezpieczeństwo – Ochrona WWW

Opracował: Zbigniew Suski

5

Zadaniem tego interfejsu jest udostępnienie elastycznego, wygodnego mechanizmu rozszerzania funkcji serwera

poza model: prześlij i wyświetl plik. Strony WWW nie muszą być statyczne. CGI jest interfejsem niezależnym od języka
wobec czego możliwe jest generowanie dokumentów dynamicznych w niemal każdym języku. W tej chwili najbardziej
popularny jest PERL.

CGI są na tyle łatwe do zbudowania, że programiści piszą je tak, jak inne proste programy. Nie biorą pod uwagę

faktu, że każde CGI jest serwerem internetowym i jest narażone na atak. Przede wszystkim należy je pisać tak, aby prze-
rywały pracę w przypadku stwierdzenia danych mogących spowodować zniszczenia lub danych nie przewidywanych.

Charakterystyka CGI określa jedynie sposób przekazywania danych pomiędzy programami. CGI typu nph (non-

parsed headers - nie obrabiane nagłówki) może omijać serwer i przekazywać wyjście bezpośrednio do przeglądarki. Jest
to konieczne gdy program chce określić swój własny kod HTTP odpowiedzi lub zapewnić, że serwer nie będzie przetrzy-
mywał danych w buforze.

Program CGI może otrzymywać dane poprzez:

•

Argumenty linii poleceń.

•

Zmienne środowiskowe.

•

Standardowy strumień wejściowy.

Każdy z tych sposobów może być wykorzystany przez włamywacza. Nie powinno się ślepo ufać serwerowi i protokołowi
HTTP. Nie należy np. zakładać, że serwer prawidłowo ustawi zmienne środowiskowe (np. PATH). Nie należy opierać się
na możliwościach konkretnego serwera, gdyż nie wiadomo jaki będzie używany w przyszłości ani czy następna wersja
będzie się zachowywała tak samo. Zmienne środowiskowe przekazane przez użytkownika w nagłówkach mogły zostać
zmienione w wyniku spoofingu. Zmienne takie zawierają np. adres URL, z którego pochodzi odniesienie, adres poczty
elektronicznej użytkownika przeglądarki, adres IP klienta, nazwę hosta klienta, identyfikator użytkownika, itp.

Istnieją dwa modele zezwalania na wykonanie na serwerze programów CGI. Pierwszy polega na wyznaczeniu

przez administratora katalogów zawierających programy i zachowanie dla siebie kontroli nad zawartością tych katalogów.
Ma on wtedy pełna kontrolę publicznie dostępnych danych. Tego modelu nie lubią użytkownicy.

W modelu bardziej liberalnym, administrator wyznacza specjalne rozszerzenie nazw plików CGI. Pozwala to

wszystkim udostępniającym dokumenty HTML na pisanie programów CGI.

Jeżeli liczba programów CGI uruchamianych na serwerze jest mała, to warto rozważyć całkowite wyłączenie CGI

i zintegrowanie programów bezpośrednio z serwerem.

Literatura:
1) V.

Ahuja.

Network & Internet Security. Academic Press, Inc, 1996. (tłum.)

2) D. Atkins i inni, Internet Security. Professional Reference, New Readers Publishing, 1997 (tłum. LT&P 1997).
3) L.

Klander.

Hacker Proof. Jamsa Press, 1997. (tłum.)

4) M.

Mathiesen.

Marketing on the Internet. Maximun Press, 1995