Bezpieczeństwo aplikacji internetowych na podstawie systemu esekretariat

Transkrypt

1 Bezpieczeństwo aplikacji internetowych na podstawie systemu esekretariat esekretariat jest internetową aplikacją wspomagającą działanie sekretariatu kancelarii prawnych w Katowicach. Z tego powodu narażony jest na różne niebezpieczeństwa związane z przechwytywaniem danych poufnych. Sprawozdanie opisuje problematykę bezpieczeństwa z perspektywy oprogramowania w PHP jak i bazach danych. Opisane zostały metody zabezpieczania aplikacji w celu ochrony danych klientów przed potencjalnymi intencyjnymi jak i przypadkowymi wyciekami danych. Michał Mikulski Architekt Oprogramowania

2 Spis treści Bezpieczeństwo aplikacji internetowych na podstawie systemu esekretariat Podstawowe informacje o esekretariacie... 3 Geneza... 3 Architektura systemu... 3 Inżynieria oprogramowania... 3 Obsługa... 4 Znaczenie bezpieczeństwa w systemie esekretariat... 4 Bezpieczeństwo Hardwareowe... 5 Bezpieczeństwo softwareowe... 6 Przesyłanie danych do użytkownika... 6 Autoryzacja i weryfikacja użytkowników... 7 Pobieranie informacji z bazy danych Dostęp do bazy danych Serwer mysql Autentyfikacja użytkowników i weryfikowanie ich danych MD5 i algorytmy jednokierunkowe Zabezpieczenia dostępu do plików serwerowych Zalety HTTP do omijania przeszkód Zrozumieć HTTP i serverside zrozumieć bezpieczeństwo plików Pliki webowe Zaleta PHP w rozwiązaniach bazujących na plikach w bazach danych Problematyka rozwiązań bazodanowych Podsumowanie

3 Podstawowe informacje o esekretariacie Geneza esekretariat został oficjalnie oddany do użytku wraz z końcem roku 2006 w wersji 1.0. Jest on autorskim projektem Michała Mikulskiego i był od fundamentów tworzony przez niego. Obejmuje on technologie takie jak: XHTML 1.0 Transitional, CCS2, JavaScript, PHP5, MSSQL, mysql, postgresql i inne. esekretariat jest dystrybuowany prze firmę HBF Consulting Artur Fronczek z Katowic i dostępny pod adresem Poniższe sprawozdanie ma na celu przedstawić najczęstsze problemy występujące w zabezpieczaniu aplikacji internetowych, dobrą praktykę i sposoby zabezpieczania się przed wyciekami informacji, oraz atakami w sieci. Jest to ważna część projektowania aplikacji narażonych na intencyjne pozyskiwanie informacji prywatnych. esekretariat jest przykładem aplikacji, w której zabezpieczenia są na istotnym miejscu w hierarchii projektowej. Jeśliby dowolna aplikacja przechowująca dokumenty poufne nie byłaby odpowiednio zabezpieczona, nie miałaby szans odnieść sukcesu na rynku. Architektura systemu System Wspomagania Pracy Sekretariatu został podzielony na trzy główne części, wg standardu architektury systemów CVM: Controller, View, Module, tj. Silnik, Widok i Klasy. Poprzez taki podział SWPS jest w pełni integralnym systemem z zewnętrznymi elementami, jest łatwy w rozbudowie i konserwacji. Podział umożliwia także pracę wielu osób przy projekcie. Wygląd SWPS v1.1.3 Inżynieria oprogramowania System został stworzony w oparciu o język programowania server-side PHP5, wraz z pakietami SMARTY do celów obróbki XHTMLa 1.0 Transitional. Kod wyświetlany przez SWPS jest zgodny ze standardami W3C, które zapewniają kompatybilność systemu w różnych przeglądarkach 3

4 sieciowych. SWPS jest testowany na bieżąco w przeglądarkach tj. Microsoft Internet Explorer 7, Mozilla Firefox 3, Opera Software ASA - Opera 9.5, Google Chrome. Kolejną zaletą systemu jest jego kompatybilność z silnikami baz danych MySQL oraz MSSQL. Taka spójność została osiągnięta dzięki zastosowaniu klas modularnych, obsługujących referencje do baz danych. Obsługa Głównym celem w czasie tworzenia Systemu Wspomagania Pracy Sekretariatu było zawarcie kluczowych informacji i szybko działającego programu z jednocześnie prostym interfacem, tak, by każdy użytkownik mógł swobodnie się poruszać i w pełni wykorzystać moc, którą daje SWPS. Dzięki zastosowaniu zwykłej przeglądarki internetowej do obsługi systemu oraz pełnej automatyzacji procesu użytkowania, SWPS spełnia założone cele programowe. Dzięki licznym kreatorom, wyszukiwarkom, wyglądzie silnie przypominającym kreatory windowsowe, a także jasnej obsłudze wyjątków PHP w każdym momencie możemy zasięgnąć pomocy oraz zorientować się w systemie. Wygląd SWPS v 1.2 Znaczenie bezpieczeństwa w systemie esekretariat Priorytetem całości projektu zawsze było i jest bezpieczeństwo danych. Aplikacji SWPS używają kancelarie prawne w Katowicach każdego dnia, zatem informacje, które wgrywają do systemu są zazwyczaj poufne. Żadna osobą z zewnątrz dostępu do danych nie powinna uzyskać. Co więcej, bezpieczeństwem danych możemy także uznać sytuacje, w której żadna informacja w systemie nie może zostać zgubiona. Wiele danych i dokumentów zawiera w sobie klauzule terminu 4

5 odpowiedzi. W przypadku stracenia takiego dokumentu, mogą wystąpić poważne konsekwencje prawne i personalne. SWPS działa by zapewnić płynny przepływ informacji w firmie, oraz przekazywanie i archiwizacje danych. Zabezpieczenia, które zostały zastosowane podczas tworzenia aplikacji esekretariatu możemy podzielić następująco: Rodzaje bezpieczeństwa Hardware Software Ochrona przed kradzieżą Przesyłanie danych do użytkownika Bezpieczeństwo nieprzerwanej pracy Autoryzacja i weryfikacja użytkowników Pobieranie informacji z bazy danych Zabezpieczenia dostępu do plików serwerowych Schemat przedstawiający rodzaje bezpieczeństwa esekretariatu Bezpieczeństwo Hardwareowe Wielu programistów wydając swoje projekty nie interesuje się gdzie wylądują ich aplikacje. Niemniej jednak Firma HBF CONSULTING zadbała o należyte bezpieczeństwo dla esekretariatu pod względem hardwarowym. Wystawiona została deklaracja bezpieczeństwa, mówiąca o wykorzystanych zabezpieczeniach przed kradzieżą, jakie są jednostki awaryjnego zasilania wykorzystane do obsługiwania dedykowanego serwera, na którym stoi SWPS. Hardware, mimo że często pomijany w przypadku aplikacji wykorzystywanej w wielu firmach bez przerwy musi być online całą dobę, codziennie. Deklaracja bezpieczeństwa jest dołączona na końcu sprawozdania. 5

6 Ponieważ bezpieczeństwo hardwareowe nie jest głównym celem tego sprawozdania, nie będzie tutaj opisane dokładniej. Bezpieczeństwo softwareowe Przesyłanie danych do użytkownika W dobie ogólnie dostępnego oprogramowania do inwigilacji sieci bezprzewodowych i wszelkiego rodzaju snifferów, gigantycznym zagrożeniem na utratę prywatności danych przesyłanych jest ich przechwycenie w trakcie przesyłania ich między użytkownikiem a aplikacją sieciową. Pierwszym zabezpieczenie na tym torze informacji jest zastosowany w esekretariacie szyfrowany protokół SSL. Używany standard to RapidSSL, potwierdzony przez organ certyfikacji Equifax Secure Inc. Zasada działania algorytmu szyfrującego kluczem publicznym jest jak przedstawiona poniżej: Otwarty tekst Algorytm szyfrujący kluczem publicznym Tekst zaszyfrowany Algorytm deszyfrujący kluczem prywatnym Otwarty tekst Algorytm szyfrowania SSL kluczem publicznym Dla zastosowania w przeglądarkach SSL jest najpewniejszym sposobem szyfrowania danych a jednocześnie najbardziej popularnym. RapidSSL używa algorytmu RSA do szyfrowania danych, opracowanego przez Rivesta, Shamira i Adelmana z instytutu MIT. Gdy komputer z kompatybilną przeglądarką internetową (a SWPS obsługuje wszystkie najpopularniejsze przeglądarki) łączy się z witryną, otrzymuje klucz publiczny, którego używa serwer SSL do szyfrowania danych, oraz prywatny i indywidualny dla konkretnego użytkownika klucz publiczny. Informacje dla tego komputera mogą być odkodowane tylko i wyłącznie tym kluczem publicznym. Zabezpiecza to użytkownika, któremu hacker przechwytuje pakiety, że jego dane zostaną poufne. Każda osoba podsłuchująca, która nie zna 6

7 i nie może wygenerować klucza prywatnego przechwyci w jakiś sposób pakiety wysyłane do innego użytkownika, nie zdoła odkodować zawartości strony internetowej. Jeśli chodzi o szyfrowanie całości strony esekretariatu, największe problemy sprawia szyfrowanie plików wysyłanych wcześniej do systemu. Pliki takie jak PDF oraz TIFF muszą być ściągane na dysk użytkownika, a są one generowane z bazy danych. Zobowiązuje to PHP do zakodowania odpowiednio tych plików względem wszystkich obowiązujących standardów bezpieczeństwa transmisji po SSLu. Dla przeglądarek takich jak Firefox, Chrome czy Opera nie stanowi to żadnego problemu, gdyż ich twórcy w pierwszej kolejności starają się zapewnić kompatybilność z jak największą ilością serwisów. Wyjątkiem stanowi Internet Explorer 7, którego wymagania zabezpieczeniowe obejmują także ilość przechowywania Cachea dla konkretnych załączników. Zazwyczaj wartości cachea są pomijane, niemniej jednak dla IE muszą być to znaczni dokładniejsze dane. esekretariat spełnia wszystkie normy każdej z głównych przeglądarek i aplikacja jest zabezpieczona w każdym miejscu poprzez SSL. Dużo serwisów internetowych jeszcze wystawia swoje pliki na serwery FTP z bezpośrednim dostępem do nich przez http, wierząc, że przez to, że nikt nie zna ich adresu, nikt nie będzie ich szukał. Dane w esekretariacie takie jak pliki dokumentów (JPG, GIF, TIFF, PDF, BMP) są utrzymywane w bazie danych, dostępne tylko poprzez aplikację PHP. Bezpośredni dostęp bez zalogowania jest niemożliwy, o czym więcej powiem w kolejnych podpunktach. Autoryzacja i weryfikacja użytkowników Gdy Internet był młody i dopiero strony internetowe rozrastały się, popularnym było stosowanie liczników i generalnie autoryzacji użytkowników na podstawie Cookie, które przetrzymywały całe informacje o użytkowniku. Dziś wiadomo, że nie jest to najrozsądniejsza metoda przetrzymywania danych. Za każdym razem, gdy użytkownik otrzymuje jakieś dane w postaci Cookie, lądują one na jego dysku twardym zapisane w cacheu przeglądarki, której używa. Ponieważ większość internautów używa jednak tworu Microsoft u Internet Explorera, w którym wszystkie Cookie są trzymane w postaci tekstowej w zazwyczaj w C:\Document and Settings\User\Cookies. Wyobraźmy sobie sytuacje, że typowy użytkownik wchodzi na stronę swojego banku, nazwijmy go Bank dla Zuchwałych BdZ. BdZ jest nowym bankiem na rynku i najwidoczniej nie docenia programisty aplikacji internetowych i bierze najtańszą na rynku osobę, która zna tylko podstawy, bo kiedyś dawno, dawno temu programowała strony internetowe. Nasz programista stwierdzi, że Cookie to jest cudowny sposób zapisywania danych, które są często używane, np. Login, Hasło do konta bankowego potencjalnych klientów Banku. Nasz klient loguje się i zapisuje informacje o swoim loginie i haśle na dysku twardym dowolnej kafejki internetowej. W takim wypadku, jeśli nie skasował Cookie (bądź skasował do Kosza, lub skasował a te dane dalej można odzyskać) dowolna osoba zdolna do odzyskania tych danych zyska dostęp do konta bankowego klienta BdZ. Tutaj widać nierozsądek Banku dla Zuchwałych. esekretariat używa Sesji do przechowywania danych tj. login i hasło, niemniej jednak hasło jest zakodowane algorytmem jednokierunkowym MD5. Zdekodowanie hasła jest niemożliwe. Istnieje oczywiście sposób, niemniej jednak uwzględnia on algorytm kodowania po kolei wszystkich wyrazów możliwych i sprawdzaniu czy wygenerowany string MD5 zgadza się z tym zapisanym w Cookies. Wszystkie konta użytkowników zapisane są w bazie danych, a hasła dostępowe do danych ich firm są zakodowane właśnie poprzez MD5. Nawet jeśliby ktoś dowiedział się login i zakodowane hasło do 7

8 konkretnej firmy, nie będzie w stanie dostać się do serwisu. Poniżej przedstawiam proces logowania do SWPS a: Podaj login i hasło Zakodu hasło algorytmem MD5 Sprawdź, czy zakodowane hasło zgadza się z zakodowanym hasłem w bazie danych dla podanego loginu Jeśli tak, zaloguj do bazy danych firmy Sposób sprawdzenia poprawności logowania w systemie Mimo, że systemy zabezpieczeń szyfrowaniem haseł dostępowych są krok przed naszym Bankiem dla Zuchwałych istnieje szereg dodatkowych algorytmów usprawniających pracę aplikacji sieciowych o poszerzonym bezpieczeństwie. Postaram się wymienić główne usprawnienia algorytmów esekretariatu, które są w trakcie opracowywania, oraz częste błędy, które można zauważyć w innych aplikacjach. Stosowanie klucza SSID PHP umożliwia stosowanie indywidualnego klucza SSID dla użytkowników korzystających z danej witryny. Jest on ustalany przez serwer, a informacje dla danej sesji są zapisywane na serwerze aplikacyjnym. Jest to duże udogodnienie, ponieważ nie zostają żadne informacje (jak np. login i hasło) na komputerze, z którego korzysta nasz klient. Niemniej jednak identyfikowanie komputera tylko po jego SSID indywidualnym jest ryzykowne. Niektóre aplikacje przekazują swój klucz w pakiecie zmiennych GET, czyli bezpośrednio przez adres witryny, który jest dostępny dla użytkownika. Istnieją dwa warianty używania SSID, albo przekazywanie go do przeglądarki poprzez Cookie, albo poprzez adres. Przekazywanie takich informacji poprzez adres jest wyjątkowo zuchwałe, ponieważ często klienci np. allegro przekazują między sobą linki do konkretnych przedmiotów na aukcjach, a 8

9 niedoświadczony użytkownik komputera nie wie, że wysyła swój klucz sesji innemu koledze. Do przemyślenia zostaje zakodowanie SSID w Cookie. Przyjmijmy za przykład kolejna wersje aplikacji Banku dla Zuchwałych. BdZ wprowadziło zmiany do swojego systemu, zmieniając zapisywanie haseł i loginów w Cookie, zapisuje tylko numer sesji SSID na komputerze użytkownika. Jest to dodatkowe usprawnienie, gdy nasz klient wyjdzie z kafejki zostawiając niewykasowane prywatne dane, jest duża szansa, że sesja się przeterminuje i kolejna osoba chcąca dostać się potajemnie do konta naszego klienta spotka się z ekranem logowania, a w Cookie znajdzie niedziałający numer sesji. Czyli innymi słowy, wróci do punku wyjścia, będzie musiał zgadnąć hasło użytkownika, by dostać się na jego konto, dokładnie tak samo, jak w jednokierunkowym algorytmie szyfrującym MD5. Istnieje natomiast ryzyko, co jeśli nasz klient aktualnie siedzi przy komputerze i korzysta ze swojego konta bankowego. Wtedy, jeśli jedynym zabezpieczeniem jest nieznajomość klucza SSID przez hackera, wystarczy zgadnąć, lub podejrzeć (w dowolny sposób, udostępniony katalog Cookie, sniffer sieciowy, trojan, lub po prostu przez ramię). W przypadku braku zabezpieczeń (wszystkie informacje dotyczące sesji są na serwerze, a na komputerze użytkownika tylko SSID) wystarczy wpisać SSID do Cookie i rozkoszować się wolnym dostępem w czasie trwania sesji do konta bankowego użytkownika. Krótki czas życia sesji Sposobem bardzo często używanym np. przez CK Politechniki Śląskiej jest ustawianie odpowiednio krótkiego czasu życia sesji. Jest to znacznym zmniejszeniem ryzyka włamania się na tą samą sesję, jeśli sesja jest odpowiednio krótka. W esekretariacie sesje także są ustawione na krótko żyjące, ale na tyle, by nie zakłócały ciągłej pracy użytkownika. Niestety jak można się spodziewać osoby korzystające z SWPS a narzekają na i tak za krótki czas sesji i częste potrzeby logowania do systemu. Niemniej jest to konieczne w systemach zwiększonego bezpieczeństwa. Jednorazowe klucze SSID i rejestrowanie IP Klucze SSID nie są złym rozwiązaniem, niemniej jednak trzeba przemyśleć dodatkowe rozwiązania chronienia kluczy. Sposobem bardzo efektywnym są jednorazowe klucze sesji SSID. Przy każdorazowym przeładowaniu strony systemu SID jest zmieniany na inny, a poprzedni klucz sesji jest niszczony. Tworzy to dodatkowe zabezpieczenie, przed włamaniem i uniemożliwia efektywne przechwycenie sesji. Nawet, jeśli ktoś przechwyci sesję klienta wyznaczany jest nowy klucz sesji. Działa to szczególnie dobrze, jeśli rejestrowane są adresy IP, przyporządkowane do konkretnych kluczy sesji. Jeśli ktoś chce wkraść się na sesję innego użytkownika, to o ile nie jest z tego samego IP, sesja nie zostanie przechwycona. Istnieje tutaj jak zawsze problem A co jeśli hacker użyje tego samego IP do przechwycenia sesji, co to, z którego loguje się klient? Odpowiedź jest prostsza niż się wydaje. Z sąsiadami trzeba krótko. A tak naprawdę, to nie ma idealnego systemu obrony przed hackerami. Na każdy system da się włamać a w naszej mocy robimy co się da, by takie włamanie nie było możliwe. Bezpieczeństwo sesji na serwerze Istotną częścią bezpieczeństwa sesji jest ich miejsce na serwerze. Zabezpieczenia aplikacyjne zazwyczaj obejmują autentyfikacje użytkownika, niemniej jednak, jeśli nie mamy bezpiecznego serwera, na którym swoi nasza system, hacker może włamać się (np. poprzez FTP) na nasz serwer i zmienić standardowo zapisywane sesje w plikach na serwerze. Jest to poważnym niebezpieczeństwem, niemniej jednak zbyt obszernym tematycznie by tu wnikać w szczegóły. 9

10 Jeśli chodzi natomiast o pewnego rodzaju zabezpieczenia, które można łatwo zrealizować, to jest ich parę. Przede wszystkim, by uniemożliwić podejrzenie informacji o sesjach w plikach, należy przekierować informacje sesji z plików do bazy danych, które są zazwyczaj dodatkowo zabezpieczone. PHP umożliwia zmianę docelowego kierowania sesji do bazy danych. Uszczelnia to system i jest rozwiązaniem zalecanym. Ciekawostka Pierwsza wersja esekretariatu była pozbawiona autentyfikacji użytkowników hasłami i loginami. Była to też wersja intranetowa na serwerze IIS dla stacji roboczych z systemem Windows i przeglądarką Internet Explorer. SWPS posiadał opcję potwierdzania zapoznania się korespondencją przychodzącą, realizowaną poprzez VB Script. Krótki skrypt wsadowy jak sama nazwa wskazuje był napisany w Visual Basicu, na bazie pierwszych wersji ASP. Skrypt pobierał z komputera w Intranecie nazwę użytkownika aktualnie zalogowanego w systemie Windows oraz nazwę sieciową stanowiska roboczego. Informację te SWPS zapisywał w bazie danych, do późniejszej analizy przez przełożonych. Takie rozwiązanie było znacznie prostsze niż system autentyfikacji, niemniej jednak wprowadzał gigantyczne ograniczenia sprzętowe i sieciowe. Za czasu działania skryptu, IE6 posiadał wiele backdorów i podobnymi skryptami na bazie ASP można było zarządzać plikami np. na pulpicie użytkownika. Był to jeden z głównym powodów przeciwko ASP w czasie developowanie pierwszych wersji esekretariatu. Pobieranie informacji z bazy danych Ogólne informacje o budowie baz danych esekretariat jest systemem wielobazodanowym z dwóch powodów. Po pierwsze istnieje wiele baz danych, osobnych na różnych firm i globalnej systemowej, ale także, dlatego, że jest system wieloplatformowym. Pierwsza wersja esekretariatu była stworzona i kompatybilna z bazami danych MSSQL, mysql i postgresql. Do dnia dzisiejszego kompatybilność została zachowana, niemniej jednak w pierwszej kolejności nie była potrzebna już baza postgresql i kompatybilność z nią została porzucona już w wersji Mimo, że wraz z wypuszczeniem wersji 1.2 baza MSSQL przestała być supportowana, kompatybilność wsteczna została zachowana dzięki modułowemu rozwiązaniu budowy esekretariatu. Każda pojedyncza kliencka baza danych posiada 9 tabel, a globalna baza danych klientów składa się z dwóch dodatkowych tabel. (Informacje aktualne dla SWPS build 1.2). Dostęp do bazy danych Bazy danych dla firm korzystających z esekretariatu są tworzone przez HBF CONSULTING, która zarządza informacjami dostępowymi pracowników. Bezpośredni dostęp do bazy danych firmy, np. z innego, zewnętrznego programu jest niemożliwy. Zapewnia to bezpieczeństwo, że żadne informacje nie wyciekną bez kontroli systemu. Hasła i loginy do bazy danych są trzymane w SWPS ie i także nie są dostępne dla użytkowników. Cała kontrola nad dostępami do baz danych jest poprzez aplikacje. Każda firma korzystająca z esekretriatu ma swoją własną bazę danych w serwisie. Takie rozwiązanie daje dodatkową gwarancję, że jakikolwiek błąd programistyczny w aplikacji, jeśliby miał być popełniony, to nie wyświetli danych innej firmy, niż aktualnie zalogowanej do systemu. Poniżej pokazane jest jak zapytanie do bazy danych o informacje. 10

11 Schemat prezentujący zapytanie do SWPS a o informacje z bazy danych. Oczywiście pobieranie uprawnień użytkownika jest jednokrotne, później zapisane te informacje są w sesji, która to sprawdza poprawność autoryzacji. Takie rozwiązanie wielobazodanowe usprawnia proces pobierania informacji z bazy danych. Bazy danych obsługuje SWPS i ma on do nich uprawnienia. Wszystkie zapytania do bazy przechodzą przez niego i zapewnia on, że wszystkie zmiany w bazach są spójne i logiczne. Serwer mysql Bazy danych stoją aktualnie na serwerze mysql. Ponieważ komunikacja między PHP a mysql em musi być solidnie zabezpieczona, obie platformy stoją na jednym serwerze, co zapobiega potencjalnemu narażeniu danych prywatnych na przechwycenie. Wyobraźmy sobie sytuacje, aplikacji zrealizowanej inaczej narażonej na potencjalne ataki. Idealnym przykładem byłby tutaj Bank dla Zuchwałych. Prześledzimy tutaj drogę, która przebywają dane poufne między bazą danych a użytkownikiem. Załóżmy, że BdZ postawił serwer bazodanowy w innym miejscu i komunikacja do niego jest po TCP/IP w Internecie, co się zdarza. Wprowadźmy też dodatkowe zabezpieczenia tj. SSL, by nie rozważać ich w tym przykładzie. 11

12 Diagram reprezentujący połączenia sieciowe między elementami systemu Tworząc nowe połączenie z bazą danych musimy zapewnić temu połączeniu ochronę. esekretariat zapewnia taką ochronę nie dopuszczając do przenoszenia danych poufnych między serwerami, o których nie wiemy nic. Jest to proste i słuszne rozwiązanie. Autentyfikacja użytkowników i weryfikowanie ich danych Poświęciliśmy już dość dużą uwagę na rozwiązania sesji w PHP dla esekreatariatu, niemniej jednak istotną częścią weryfikacji użytkownika jest przechowywanie jego danych w bazie danych. By sprawdzić tożsamość klienta logującego się do esekretariatu weryfikowane są trzy rzeczy: Login, Hasło, NIP firmy. Informacje o firmach i użytkownikach aplikacji SWPS przechowywane są w głównej bazie danych, która zawiera także uprawnienia. Bardzo istotną kwestia jest tutaj przechowywanie haseł w bazie danych. Poniżej przedstawiam parę priorytetowych rzeczy dotyczących ostrożności i kroków bezpieczeństwa zastosowanych w systemie. 12

13 Hasła przechowywane zaszyfrowane algorytmym jednokierunkowych MD5 Informacje z głównej bazy danych nigdynie nie są wyświetlane i jawne Żaden użytkownik nie ma uprawnień do zmiany danych w głównej bazie danych Diagram przedstawiający najważniejsze zasady komunikacji z bazą główną Wiele początkujących autorów aplikacji internetowych nie widzi potrzeby szyfrowania haseł swoich użytkowników w bazie danych. Jest to bardzo duży błąd z wielu powodów. Po pierwsze daje im to możliwość monitorowania niczego niespodziewających się ludzi i wykradanie ich poufnych danych. Zazwyczaj przecież internauci mają jedno lub niewiele haseł, które podają do wszystkich witryn. Co więcej, przechowywane hasła nie są bezpieczne, gdy są przechowywane na kupnym serwerze udostępniającym bazy danych. Nigdy nie możemy mieć pewności, czy dana firma nie może mieć wglądu w nasze informacje zlokalizowane w bazie danych. Istotnym też jest konieczność przygotowania się na możliwość włamania na serwer bazy danych i przechwycenia tych haseł przez hackerów. MD5 i algorytmy jednokierunkowe esekretariat do przechowywania haseł swoich klientów używa szyfrowania haseł MD5. Zapewnia to, że nawet jeśliby osoba trzecia pozyskała dostęp do przeczytania informacji w bazie głównej, nie będzie w stanie zalogować się na konto klienta SWPSa. Hasła MD5 są jednokierunkowe, czyli szyfrowanie jest możliwe, ale odszyfrowanie jest niemożliwe. Dla odpowiednio skomplikowanych haseł niebędących wyrazami słownikowymi, crackowanie hasła zaszyfrowanego MD5 może trwać parę tygodni, dłużej lub może całkowicie być niemożliwe. Poniżej zamieszczam przykłady algorytmów crackujących MD5 dostępnych na Internecie: 13

14 Typowy algorytm łamania hasła zaszyfrowanego poprzez MD5 Zabezpieczenia dostępu do plików serwerowych Zalety HTTP do omijania przeszkód Każdy, kto interesuje się Internetem, lub przynajmniej dostatecznie dużo czasu spędza online wie, że brak linku do pliku na stronie internetowej nie oznacza, że nie można się do niego dostać. Najczęściej ciekawscy studenci uczelni takich jak np. Uniwersytet Śląski lub niektórych Państwowych Wyższych Szkół Zawodowych wiedzą, że w dramatycznym oczekiwaniu na plany zajęć na nowy semestr, ich beta wersje ukazują się na Internecie, ale linki do nich są pochowane i przekazywane między wykładowcami i osobami układającymi grafiki. Wystarczy znać odpowiedni ukryty katalog, w którym one są i jeśli serwer np. Apache pozwala na listing plików katalogu to już mamy do nich dostęp. Jeśli nie, wystarczy znać zazwyczaj prosty sposób nazywania plików i także ten dostęp jest jawny. 14

15 Dokładnie tak samo działają przeglądarki internetowe. Mimo, że w większości przypadków listing plików jest wyłączony, by otrzymać informacje takie jak np. zdjęcia, użytkownicy muszą mieć do nich dostęp. Dokładnie tak powstają problemy z hotlinkowaniem i na prawdę żenujące ostrzeżenia Proszę o nie hotlinkowanie zdjęć autorów stron internetowych nie radzących sobie z wyciekiem informacji z ich strony internetowej. Jeśli gra toczy się tylko o transfer z serwera, na którym stoi aplikacja, to nie jest to naprawdę wielki problem, niemniej jednak, jeśli dane są poufne, a z takimi mamy do czynienia w esekretariacie, takie rozwiązanie nie jest do przyjęcia. Ciekawostka SWPS w wersji aż do 1.2 obsługiwał dane poufne poprzez pliki, niemniej jednak w tamtych czasach był aplikacją w Intranecie i dostępną tylko i wyłącznie dla pracowników jednej firmy. Realizacja zabezpieczeń i algorytmów do obsługi plików z baz danych jest kłopotliwa i skomplikowana, dlatego nie była realizowana do momentu, gdy była konieczna. Dla rozwiązań takich jak zabezpieczenia plików poufnych, bądź ograniczenie zużycia łącza przez zablokowanie hotlinkowania idealnie nadaje się PHP. Zanim jednak przejdziemy do omówienia algorytmów bezpieczeństwa, obejrzyjmy jak wygląda typowy plik pobierany z serwera i na czym polega komunikacja HTTP. Zrozumieć HTTP i serverside zrozumieć bezpieczeństwo plików W programach użytkowych uruchamianych bezpośrednio na komputerze użytkownika pobieranie plików nie jest problematyczne. Możemy stworzyć katalog, w którym będziemy trzymać informacje i liczyć, że nikt nam nie ukradnie laptopa, tak samo jak liczymy, że nikt nie ukradnie nam portfela na ulicy. Obie te naprawdę nie miłe sytuacje prowadzą do tego samego. Tracimy pieniądze. By tego nie robić, zobaczmy jak walczą z tym esekretariat. Transmisja danych HTTP jest protokołem pytania i odpowiedzi przeglądarki rki internetowej i serwera. Poniższy diagram przedstawia zapytanie do serwera o statyczną stronę w HTMLu. Diagram przedstawiający zapytanie o stronę statyczną na serwerze webowym O ile nasza strona to opis zachowań naszego ukochanego czworonoga wraz z jego zdjęciami, to nie jest groźne udostępnienie ich wszystkich światu. Jeśli mamy do czynienia z plikami poufnymi musimy zastosować jakieś algorytmy prewencji. Mając nasze wcześniej omówione algorytmy logowania i 15

16 używania sesji, nie jest problem ograniczyć dostęp do strony HTMLowej lub jakiejś podstrony naszej aplikacji użytkownikowi, który do niej praw nie ma. Np. użytkownikowi Hacker nie damy dostępu do podstrony SuperPrywatneDaneFirmyNiePrzekazywacNikomu.php?todo=print. Niemniej jednak, jeśli mamy jakieś pliki graficzne, które inni użytkownicy musza zobaczyć na stronie www, to prawa dostępu do tych plików na serwerze muszą obejmować także pozycje Read dla All users. I niestety właśnie nasz hacker zyskał dostęp do naszych tajnych plików. Mimo, że nie przeszedł strony logowania, ma dostęp do images/umowazprezydentempoufne.jpg, ponieważ jest to dostępne dla wszystkich użytkowników (musi być wysyłane przez HTTP). Dochodzimy do tego, czym tak naprawdę jest plik. Pliki webowe Dostęp do plików jest dowolny poprzez serwer webowy. Niemniej jednak nasza przeglądarka, prosząc o plik Zdjęcie.jpg nie wie jeszcze ze plik jest w formacie JPEG. Pobiera jego header, w którym są wszystkie informacje potrzebne do poprawnego otworzenia zdjęcia w oknie przeglądarki. To znaczy, że plik WyswietlZdjecie.php?id=15 także jest plikiem, którego header musi przeglądarka poznać. Jest to sposób na utajnienie informacji poprzez aplikację serverside. Oto algorytm, który wykonuje serwer z kompilatorem PHP zainstalowanym, gdy przeglądarka prosi go o plik PHP. Diagram przedstawiający dynamiczne generowanie strony www poprzez Serwer HTTP z użyciem PHP Trzeba zaznaczyć, że wygenerowana w szczególności może być strona www, niemniej jednak tak samo możemy wygenerować dowolny obrazek. Z perspektywy kodu w HTMLu nie ma znaczenia, czy znaczniki <img> pobiegają plik o rozszerzeniu. Ważne jest, jaki pobierany plik ma header. Istnieją zatem dwie realne możliwości wykorzystania opisanego algorytmu do zarządzania danymi poufnymi, przedstawia a je poniższy diagram. 16

17 Pliki na dysku Łatwa obsługa i przetwarzanie danych Prosty sposób dostępu ale tylko przez aplikacje -osobne katalogi dla różnych firm Powolny dostęp, ponieważ musi być użyty dysk twardy serwera W przypadku włamania na serwer FTP wszystkie pliki w łatwy sposób mogą zostać skradzione Bazy danych Bardziej skomplikowane przetwarzanie plików do i z bazy danych Zarządzanie wieloma bazami danych w zależności od użytkowników Znacznie szybsza komunikacja po TCP/IP z bazą danych niż odczyt z dysku twardego Dodatkowe zabezpieczenia poprzez logowanie do baz danych Włamanie na FTP nie koniecznie oznacza przejęcie kontroli nad bazą danych, więc pliki poufne zyskują dodatkowe zabezpiecznie esekretariat w trosce o dobro swoich klientów polega w pełni na Bazach danych, z których są pobierane konkretne pliki dla klienta z jego firmy. Głównym powodem wyboru takiego rozwiązania, było zwiększenie bezpieczeństwa plików poufnych, ale także szybkość działania bazy danych. Zaleta PHP w rozwiązaniach bazujących na plikach w bazach danych Dużą zaletą pracując na plikach graficznych umieszczonych w bazie danych dla formatów takich jak JPEG, GIF, PNG, BMP itp. jest obsługa biblioteki ioteki GDI+ przez PHP. Umożliwia to wygenerowanie bezpośrednio z binarnego zapisu pliku z bazy danych stworzenie na poczekaniu pełnego pliku graficznego i wyświetlenie go na stronie internetowej. Problematyka rozwiązań bazodanowych Nie należy zapominać, że dla systemów o podwyższonym poziomie zabezpieczeń takich jak esekretariat rozwiązanie tworzenia plików na poczekaniu i wysyłanie do użytkownika musi odbywać się poprzez protokół SSL. Każde inne rozwiązanie naraża firmy używające systemu na utratę poufności ich danych. Tutaj rodzi się pewna problematyka pod przeglądarką Internet Explorer. Wymagania bezpieczeństwa dla Microsoftu zawierają także dodatkowe własności dla plików, takie jak np. Cache-Control: Control: maxage, czy Pragma. Po ustawieniu dodatkowych danych pobieranie plików działa już bezbłędnie poprzez SSL. 17

18 Podsumowanie Każdego dnia miliony osób korzystają z Internetu dla rozrywki, grają w gry komputerowe, pozyskują informacje, uczą się, pracują. Wszystkie te osoby tworzą to, czym nazywamy Społeczność Internetową. Każdy z nas jest częścią tego wielkiego świata, w którym zacierają się granice między państwami, grupami społecznymi, ludźmi. W Internecie wszyscy jesteśmy równi, mamy takie same prawa i wzajemnie komunikujemy się o oddziałujemy. Wszyscy dzięki sobie dorastamy. Nasza społeczność rośnie z nami i coraz więcej firm i ludzi korzysta z Internetu do codziennej pracy, co widać wraz ze wzrostem ilości typowo webowych aplikacji biznesowych, jaką jest także esekretariat. Naszą rolą, jako architektów i inżynierów oprogramowania jest przybliżanie techniki do ludzi z różnych dziedzin życia codziennego. Każda poważna firma posiada teraz swoją stronę internetową, każda działalność publiczna stowarzyszenia, nawet kluby sportowe ma swoją witrynę. Wszyscy Ci ludzie korzystają z Internetu, reklamują się, piszą wiadomości i poszerzają zbiór światowej wiedzy, jaką jest Internet. Naszym celem jest przybliżyć im możliwości, jakie niosą ze sobą aplikacje internetowe, w tym także, esekretariat. Nie ma potrzeby by typowy człowiek przed komputerem znał się na zabezpieczeniach aplikacji internetowych. Powinien zaufać nam programistom, że dbamy o niego, o dobro jego firmy, o jego interesy. Przejmujemy się tym, by jego aplikacja działała sprawnie, przez przystanków, zawsze tak jak on by tego chciał, a przede wszystkim, by jego dokumenty, w tym i te poufne były bezpieczne. 18