Polsko-Japońska Wyższa Szkoła Technik Komputerowych

Prezentacja na temat: "Polsko-Japońska Wyższa Szkoła Technik Komputerowych"— Zapis prezentacji:

1 Polsko-Japońska Wyższa Szkoła Technik Komputerowych
Technologie Internetu wykład 6: Bezpieczeństwo aplikacji internetowych Piotr Habela Polsko-Japońska Wyższa Szkoła Technik Komputerowych 1

2 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

3 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

4 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

5 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

6 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. Źródło problemu może stanowić np. rozdźwięk pomiędzy abstrakcjami programistycznymi, w kategoriach których myśli programista (np. zmienne) a ich konkretną implementacją (np. ograniczony zakres wartości). 6

7 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

8 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

9 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

10 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

11 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

12 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

13 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: o nazwie konstruowanej dynamicznie; 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

14 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. W SQL: np. doklejenie do warunku WHERE segmentu OR lub UNION. 14

15 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

16 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

17 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

18 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, Diffie-Helman). Podstawową zaletą jest fakt, że rozwiązują problem bezpiecznej dystrybucji klucza. 18

19 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

20 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. Potwierdzanie przez adresata – w odróżnieniu od modelu z potwierdzaniem pośrednim. 20

21 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

22 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

23 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

24 IPSec – tryby pracy Tunelowy: Transportowy:
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

25 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

26 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

27 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

28 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