Technologie Internetu wykład 6: Bezpieczeństwo aplikacji internetowych Piotr Habela

1. 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. 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. 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. 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: • 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