Transcript Document

Technologie Internetu
wykład 6: Bezpieczeństwo aplikacji
internetowych
Piotr Habela
Polsko-Japońska Wyższa Szkoła
Technik Komputerowych
1
W poprzednim odcinku…
• Specyfikę aplikacji WWW stanowią narzucone przez ten
interfejs ograniczenia w budowie warstwy prezentacji.
• W oparciu o to kryterium wyróżniono 3 modele architektury
aplikacji.
• Specyficzne dla WWW elementy warstwy prezentacji
wymagają wprowadzenia stosownych pojęć do języka
modelowania (tu UML). Są również przedmiotem ważnych
wzorców projektowych.
• Pozostałe aspekty funkcjonowania aplikacji WWW nie
różnią się od aplikacji konwencjonalnych. Kluczowym
postulatem jest podział oprogramowania na warstwy:
ograniczenie złożoności; łatwiejsza optymalizacja,
pielęgnacja i zarządzanie bezpieczeństwem.
2
Plan wykładu
• Przegląd zagrożeń dla bezpieczeństwa
• Bezpieczeństwo w komunikacji internetowej:
serwer, klient, łącze
• Czynnik ludzki
• Kryptografia
• Bezpieczne połączenia
• Bezpieczeństwo kodu
3
Zmiany w problematyce bezpieczeństwa
• Upowszechnienie komputerów i sieci zmusza do założenia,
że wprowadzone rozwiązania muszą być efektywne wobec
nieprofesjonalistów.
• Rozwój struktur elektronicznego biznesu nie pozwala
oprzeć się na „instytucjonalnym” systemie bezpieczeństwa
zakładającym, że każdy z uczestników mających dostęp do
danego środowiska jest wiarygodny.
• Kolejnym związanym z tym problemem jest brak
pojedynczego ośrodka zawiadującego uprawnieniami.
• Potrzebne są łatwe w użyciu środki nadające się do użycia
w systemie otwartym na świat (tu m.in. problem
bezpiecznej dystrybucji kluczy szyfrowania).
4
Bezpieczeństwo komunikacji w Internecie
• Stuprocentowe zabezpieczenie systemu wymagałoby
fizycznego odizolowania go od wszelkich potencjalnych
intruzów. W wypadku oprogramowania działającego w
Internecie z założenia trzeba ów dostęp dopuścić.
• Dla aplikacji internetowych należy wyróżnić trzy elementy
wraz ze specyficznymi dlań rodzajami zagrożeń:
– Serwer;
– Komputer klienta;
– Łącze sieciowe;
• Analizując zagrożenia należy uwzględnić zarówno
niedoskonałości techniczne wykorzystywanych rozwiązań
jak i czynnik ludzki.
5
Zagrożenia dla strony serwera
• Wiążą się zwłaszcza z niedoskonałościami oprogramowania
(luki w bezpieczeństwie) oraz jego niewłaściwą
konfiguracją.
• Należy zadbać o wyłączenie wszelkich nieużywanych opcji.
Np. starsze rozwiązania technologii dynamicznych jak CGI
czy SSI uchodzą za szczególnie podatne na powstawanie
takich luk.
• Podstawowym zagrożeniem jest nieuprawniony dostęp do
danych zgromadzonych przez aplikację WWW.
• Istotnym sposobem ochrony serwera pracującego na
potrzeby sieci wewnętrznej jest użycie zapory (firewall).
• Należy pamiętać o aktualizacjach oprogramowania, celem
łatania znanych luk. Dotyczy to zarówno bezpieczeństwa
serwera jak i oprogramowania klienta.
6
Zagrożenia dla strony klienta
• Są w większości specyficzne dla stosowanej technologii.
• Np. dla cookies może dojść do naruszenia prywatności poprzez ich
nieuprawniony odczyt. [O ile obecne rozwiązania dot. cookies
uchodzą za szczelne, to umieszczanie wewnątrz cookie istotnych
danych (np. autoryzacja) uchodzi za poważny błąd projektowy.]
• Wczesny JavaScript: wysyłanie lokalnych plików bez zgody
użytkownika, czy też dostęp do historii i zawartości związanych z
inną ramką.
• Możliwości apletów Javy są szersze, choć zadbano o odizolowanie
zasobów klienta od środowiska wykonania apletu. Sytuacja zmienia
się w wypadku cyfrowo podpisanych apletów zaaprobowanych przez
użytkownika (szersza funkcjonalność).
• Większe potencjalne zagrożenie stanowią ActiveX (również
zabezpieczane systemem certyfikatów).
• Podobnie duże możliwości mają wtyczki (plugin) do przeglądarek,
służące obsłudze zasobów określonego typu (MIME extensions).
7
Zabezpieczenie łącza
• Łącze sieciowe wymaga ochrony z uwagi na możliwość
jego nasłuchu.
• Stosuje się niskopoziomowe kodowanie przesyłanych
informacji (np. SSL). W takim rozwiązaniu zestawiający
bezpieczne połączenie serwer, a opcjonalnie również klient,
muszą wylegitymować się odpowiednim certyfikatem
potwierdzającym tożsamość.
• Rozwijane są również specyfikacje przewidziane specjalnie
dla e-commerce (np. SET). Chodzi o bardziej wyrafinowane
środki ochrony newralgicznych danych jak i prywatności:
– m.in. ukrycie w potwierdzeniu dla sprzedawcy sposobu dokonania
wpłaty oraz ukrycie tytułu płatności przed podmiotem
autoryzującym kartę.
8
Czynnik ludzki
• Z tą sferą wiąże się m.in. zapewnienie właściwego doboru i
posługiwania się hasłami użytkowników:
– Poziom świadomości zagrożeń związanych z zaniedbaniem
poufności haseł uważa się za dramatycznie niski.
– W związku z tym poza koniecznością edukowania pracowników
sugeruje się rozbudowanie mechanizmu autentykacji o
identyfikator sprzętowy.
• Organizacje muszą zadbać o wykwalifikowany personel,
który zajmie się monitorowaniem zagrożeń i doskonaleniem
technicznej i organizacyjnej strony zabezpieczeń.
• Uproszczenie i częściowa automatyzacja aktualizacji
oprogramowania dają szansę na skuteczniejsze
uszczelnianie oprogramowania u indywidualnych
użytkowników.
9
Bezpieczeństwo aplikacji
• Głównym przedmiotem troski w bezpieczeństwie aplikacji
WWW jest oprogramowanie po stronie serwera, w tym
przede wszystkim zagrożenia związane z technologiami
dynamicznych stron WWW.
• Kluczowe zagrożenia w tych technologiach to:
– Ujawnienie szczegółów implementacyjnych;
– Nieuprawniony dostęp do danych na serwerze;
– Nieuprawnione wywołanie poleceń:
API, systemu operacyjnego, SQL czy podstawionego kodu;
– Atak na przesyłane parametry;
– Atak na sesję.
Źródło użyte w tej sekcji:
Wojciech Dworakowski: „Aplikacje internetowe – Zagrożenia i metody ataku”.
10
Ochrona szczegółów implementacyjnych
• Nie sposób zakładać całkowitej „szczelności” naszego
oprogramowania, toteż warto zadbać o ukrycie przed użytkownikami
informacji o sposobie implementacji stron. Jest to potencjalne
ułatwienie penetracji systemu, nie wspominając o ew. osadzenia w
kodzie danych chronionych – np. hasło do bazy danych).
• Poważnym błędem jest tu pozostawienie kodu używanego przy
debugowaniu, jak również umieszczenie komentarzy nt. kodu
dynamicznego jako komentarzy HTML (znajdą się w źródle strony
klienta!).
• Nazwa oprogramowania deweloperskiego w komentarzu HTML
również jest niepożądana.
• Rozszerzenia nazw plików a ochrona kodu:
– pliki o zarejestrowanych nazwach (.php, .jsp) nie zostaną wypuszczone przez
serwer w postaci „surowej”;
– używając niejawnie kodu z plików o innych rozszerzeniach (np. import z pliku
.inc w PHP), czy nie sprzątając kopii zapasowych (np. rozszerzenia .bak, .old),
narażamy się na ujawnienie kodu źródłowego.
11
Obsługa przesyłanych parametrów
• Pamiętajmy, że przeglądarka jest pod kontrolą użytkownika,
toteż nie hermetyzuje skutecznie przesyłanych lub
przechowywanych przezeń parametrów: mogą one zostać
podmienione, usunięte lub dodane (Np. tzw. „przeklejanie
ceny”).
• Problem dotyczy zarówno parametrów żądania jak i cookies.
• Dlaczego np. nowsze wersje PHP standardowo wyłączają
wygodną opcję „register globals”?
• Możliwość nadpisania stanu istotnej zmiennej (wymaga
odgadnięcia jej nazwy) poprzez doklejenie dodatkowego
parametru żądania.
• Z powyższych względów kod musi być przygotowany na
obsłużenie wszelkich potencjalnych błędów, a nie jedynie tych
możliwych przy zwyczajnym użytkowaniu serwowanych stron.
12
Bezpieczeństwo katalogów niedostępnych dla klienta
•
•
•
Serwer nie zrealizuje żądań wskazujących na pliki w
takich katalogach.
Jednakże skrypty działające na serwerze mogą z nich
korzystać...
Jeśli którakolwiek z naszych stron zwraca zawartość pliku:
1. o nazwie konstruowanej dynamicznie;
2. w sposób zależny od parametrów klienta;
•
•
to jest to źródło zagrożenia.
Odpowiednio spreparowana ścieżka może też zostać
podstawiona jako parametr żądania, lub np. jako nagłówek
HTTP „Accept-Language:”.
Metody tego rodzaju określa się kategorią „path
traversal”.
13
Nieuprawnione wywołanie poleceń
• Jeszcze groźniejsze są wywołania poleceń systemowych
(lub funkcji API) konstruowane w sposób zależny od
parametrów klienta.
• Potencjalna możliwość wprowadzenia nieprzewidzianych
parametrów komendy, czy wręcz wywołania innej komendy.
• Odmianą takich ataków są modyfikacje poleceń SQL:
– dołączenie segmentu rozluźniającego warunek selekcji (WHERE);
– dołączenie (np. za parametrem warunku WHERE) średnika i
kolejnego polecenia (np. usunięcia danych).
• Typy ataków zwane odpowiednio OS command injection i
SQL injection.
14
Niedostateczna kontrola parametrów – inne problemy
• W wypadku języków, które nie chronią pamięci, możliwe są
próby przesłania odpowiednio długiego parametru, który
spowoduje przepełnienie bufora i nadpisze pamięć
(modyfikując sąsiednią zmienną lub wstawiając kod
maszynowy). Są to tzw. metody buffer overflow.
• Z kolei brak kontroli treści wpisywanej przez
użytkowników i wyświetlanej na naszych stronach (np.
aplikacje typu forum), powodują zagrożenia prywatności
użytkownika (np. wykradnięcie cookie). Metoda ta zwana
jest cross-site scripting.
15
Bezpieczeństwo sesji
• Sesja oferuje programiście wyższy poziom abstrakcji: celem
zapamiętania stanu dba o identyfikację użytkownika.
• Jest to jednak realizowane przez poznane wcześniej proste
środki (cookies, pola ukryte lub parametry URL).
• Pod słabo kontrolowaną sesję można się więc podszyć. Aby
zapobiec podstawieniu identyfikatora sesji (token), należy
zadbać o:
–
–
–
–
znaczną długość (przestrzeń) identyfikatora;
skuteczny losowy algorytm jego generowania;
ograniczony czas ważności;
brak związku z parametrami użytkownika;
• Problem wiąże się też z bezpieczeństwem po stronie klienta
(wykradnięcie ID sesji).
16
Bezpieczeństwo aplikacji - podsumowanie
• Jak widzimy, najważniejszym źródłem problemów jest brak
sprawdzenia parametrów nadesłanych przez klienta,
zwłaszcza, gdy mają one wpływ na:
– wskazanie pobieranych zasobów;
– zawartość utrzymywanej przez nas strony HTML;
– wywołanie polecenia systemu operacyjnego lub SQL;
• Wskazana jest duża wyobraźnia i nieufność wobec
parametrów mogących nadejść od klienta.
• Istotne są ponadto odpowiednia konfiguracja serwera i
postać kodu ukierunkowane na ochronę szczegółów
implementacyjnych.
17
Metody kryptograficzne
(1)
• Komunikacja w Internecie zwiększyła zapotrzebowanie na
techniki bezpieczeństwa danych oparte na kryptografii.
Oczekuje się przede wszystkim realizacji następujących
zadań:
– Poufność – tj. niemożność odczytania podsłuchanej wiadomości;
– Autentyczność – możliwość sprawdzenia autentyczności nadawcy;
– Spójność – możliwość wykrycia, czy wiadomość nie została
zmieniona;
– Niezaprzeczalność (non-repudation) przyjęcia wiadomości.
• Szczególną rolę odgrywają tu systemy z kluczem
publicznym (Rivest, Shamir i Adleman RSA, DiffieHelman). Podstawową zaletą jest fakt, że rozwiązują
problem bezpiecznej dystrybucji klucza.
18
Metody kryptograficzne
(2)
• Druga istotna właściwość umożliwia odczytanie oryginału
wiadomości, którą najpierw przetworzono funkcją
rozszyfrowującą (użycie klucza prywatnego), a następnie
szyfrującą (klucz publiczny). Pozwala to na podpisywanie
wiadomości.
• Jeżeli celem jest weryfikacja wiadomości, to można
zastosować haszowanie – czyli za pomocą odpowiedniej
funkcji sporządzić skrót (czy ekstrakt) wiadomości.
Mechanizm działania przypomina w założeniach liczenie
sumy kontrolnej CRC. Następnie taki skrót można
dodatkowo zaszyfrować.
• Podpis cyfrowy:
– W podpisanym pliku zaznaczony jest początek i koniec
podpisywanej treści oraz dołączony jest ekstrakt wiadomości
podpisany kluczem prywatnym nadawcy.
19
Bezpieczna komunikacja – protokół SSL
• Opracowany przez firmę Nestscape, dla zabezpieczenia
komunikacji w protokołach HTTP, Telnet, NNTP i FTP.
• Służy szyfrowaniu komunikacji, ale również potwierdzaniu
tożsamości serwera i klienta oraz sprawdzaniu integralności
przesłanej informacji.
• Operuje pomiędzy warstwą aplikacyjną a warstwą
transportową.
• Wspierany m.in. przez wszystkie nowoczesne przeglądarki.
• W TCP/IP wspierane są połączenia w tzw. modelu
potwierdzania przez adresata.
• Bezpieczeństwo komunikacji wymaga ponadto
potwierdzenia tożsamości serwera.
• Służą temu certyfikaty nadawane przez niezależne
instytucje (np. Verisign). Przy zestawianiu połączenia klient
ma możliwość sprawdzenia certyfikatu serwera.
20
SSL – mechanizm działania
• Przesyłane dane podlegają szyfrowaniu: służy temu klucz
tajny zwany kluczem sesji.
• Jak sugeruje nazwa, klucz ten jest dla każdej sesji
generowany.
• Rodzi to problem bezpiecznej dystrybucji klucza, który
rozwiązano następująco:
– stosowany jest tzw. system klucza publicznego;
– w pierwszym kroku klient wysyła swój unikatowy klucz publiczny
(wygenerowany dla zainstalowanej przeglądarki);
– serwer odpowiada komunikatem (zaszyfrowanym przy użyciu tego
klucza), w którym podaje dane połączenia oraz swój klucz
publiczny;
– klient koduje za pomocą tego klucza i wysyła szczegóły połączenia
oraz prośbę o klucz sesji;
– serwer wysyła klucz sesji, którym kodowana jest dalsza
komunikacja.
21
Bezpieczna komunikacja – protokół IPSec
• Zapewnia prywatność, integralność i autentyczność
przesyłanych w sieci danych. (zob. specyfikacje RFC 2401 i
dalsze).
• Jak sugeruje nazwa: szyfrowanie w warstwie sieciowej.
Mniej inwazyjna od innych metod – nie musi wymagać
zmian w oprogramowaniu.
• Bardziej uniwersalne od SSL, gdyż nie ograniczone do
wybranych aplikacji.
• Stosowane są następujące algorytmy:
–
–
–
–
Klucza publicznego – Diffie-Hellmana.
Szyfrowanie danych typu DES.
Algorytmy funkcji skrótu (haszujące): HMAC, MD5, SHA.
Certyfikaty cyfrowe.
22
IPSec – składniki protokołu
• Authentication Header (AH): spójność i autentykacja.
Zwykle stosuje funkcje skrótu jako szybsze od podpisów
cyfrowych.
• Encapsulating Security Payload (ESP): poufność,
spójność, autentykacja.
• Internet Security and Key Management Protocol:
zarządzanie kluczami.
• AH lub ESP stosowane w zależności od potrzeb (zwykle
tylko jeden z nich w danym pakiecie).
• Dla każdego kierunku pomiędzy dwoma komunikującymi
się węzłami jest negocjowany kanał bezpiecznego
połączenia (Security Association).
23
IPSec – tryby pracy
• Tunelowy:
– Koduje zarówno dane, jak i oryginalny nagłówek IP (zastępuje go
nowym).
– Zabezpiecza przed możliwością analizy ruchu. W tym trybie
kodowaniem do IPSec mogą się zajmować rutery, udostępniając
docelowym węzłom oryginalne datagramy.
• Transportowy:
–
–
–
–
Pozostawia oryginalny nagłówek IP.
Koduje dane.
wymaga rozumienia protokołu IPSec przez docelowe węzły.
Przebieg ruchu nie jest utajniony; pozwala to zarządzać ruchem
datagramów (np. celem zapewnienia jakości usług).
24
Bezpieczeństwo kodu
• Celem jest bezpieczne uruchamianie oprogramowania w
lokalnym środowisku.
• Platformy takie jak Java czy .NET dostarczają
wyrafinowanych środków dla kontrolowania uprawnień
poszczególnych modułów oprogramowania.
• Dominują metody deklaratywne:
– System sprawdza uprawnienia danego kodu dla dostępu do
zasobów systemu.
– Kod deklaruje swoje zapotrzebowania na uprawnienia. Muszą być
one określone statycznie, aby zestaw uprawnień był znany w
czasie kompilacji.
– Żądanie przyznania uprawnień może być skierowane do kodu,
który je posiada.
– .NET wyróżnia w żądaniach deklaracje uprawnień: minimalnych,
opcjonalnych, i nieprzyjmowanych (refused).
25
Bezpieczeństwo oparte na dowodzie (evidence-based)
• Ów dowód określa, czy kod jest godny zaufania.
Sprawdzenie jest wykonywane przez CLR lub środowisko
Javy:
– miejsce pochodzenia kodu; URL pochodzenia kodu;
– weryfikacja autora (podpis cyfrowy);
– weryfikacja certyfikatu oprogramowania;
• Polityka taka może być konfigurowana. .NET stosuje model
hierarchiczny, w którym efektywna polityka jest
przecięciem następujących definicji:
– poziom organizacji (enterprise);
– poziom maszyny (machine);
– poziom użytkownika (user);
26
Tożsamość kodu
• Opiera się na tzw. „mocnej nazwie” (strong name) danego
kodu:
–
–
–
–
nazwa (bez rozszerzenia pliku);
numer wersji;
klucz publiczny;
podpis cyfrowy.
• Podsumowując – dowód złożony z nazwy i miejsca
pochodzenia kodu, jest rozpatrywany przez moduł
bezpieczeństwa, w oparciu o lokalną politykę. W oparciu o
te czynniki jest określane, czy zostaną mu przyznane
uprawnienia wskazane w żądaniu.
27
Lokalny zapis danych
• Dostęp celem lokalnego zapisu danych do systemu plików
stanowi poważny wyłom w bezpieczeństwie.
• Dla ominięcia tego problemu wprowadzono pojęcie
izolowanego obszaru przechowywania. Dostęp doń nie
wymaga uprawnień do operacji plikowych.
• Tworzy on wirtualny system plików, mogący mieć
określony zasięg (np. dla aplikacji, dla użytkownika, dla
domeny).
28