Potrzeba dostarczenia bezpiecznego serwisu, któremu można zaufać, jest akceptowana bez zastrzeżeń przez organizacje, lecz jak to osiągnąć?
Bezpieczeństwo serwisu to złożona kwestia, która obejmuje różnorodne dyscypliny i wymaga wyrafinowanego, strategicznego podejścia, z zaangażowaniem na wszystkich poziomach, nie tylko w wymiarze technologicznym.
Następstwem niewłaściwego podejścia do bezpieczeństwa witryny może być natychmiastowa strata finansowa powstała na skutek kradzieży, wypłata odszkodowania lub sprawa sądowa. Inne straty nie są bezpośrednie i trudno je zakwalifikować. Pomijanie kwestii bezpieczeństwa może zaowocować brakiem zaufania ze strony partnerów i klientów, którzy mniej chętnie będą powierzać nam swoje dane oraz angażować się z nami w transakcje. Od czego jednak zacząć? Ważne jest, by wyważyć skalę zagrożeń, zanim zaczniemy zastanawiać się, z której techniki skorzystać.
Rozpoznać wroga
Zanim zagłębimy się w mechanizm obronny naszego serwisu, pomyślmy, przed kim się bronimy. Niezaprzeczalnie istnieje ryzyko ataku osób postronnych (zwanych hakerami) narażających nasz serwis lub kradnących dane. Może być jednak i tak, że wywierająca presję kwestia bezpieczeństwa może mieć źródło wcale nie na zewnątrz – zagrożeniem mogą okazać się nasi pracownicy lub koledzy, zarówno wskutek popełnianych błędów, jak też aktów sabotażu.
Wiele firm inwestuje w zewnętrzne zapory ogniowe, pozostawiając swoje serwery całkowicie dostępne dla komputerów wewnątrz intranetu. Często zdarza się, że pracownicy, tacy jak twórcy stron, mogą znać hasła do tych produkcyjnych serwerów i baz danych. Taka pokusa może przekształcić niezadowolonego pracownika w duże zagrożenie dla bezpieczeństwa. Nawet jeśli nie jest on umotywowany, by kraść dane dla siebie, może to zrobić pod wpływem przestępców. Także pracownik, który przez przypadek gubi laptop lub przenośną pamięć z danymi i hasłami, może spowodować duże szkody.
Tym niemniej haker (samotny, wyalienowany geniusz komputerowy, niosący spustoszenie na niezabezpieczonych serwerach) naprawdę czyha w internecie. Od wprawnych hakerów więcej jest mniej wyrobionych, ale także niebezpiecznych \”skryptowych dzieci\” – stosunkowo słabo wyedukowanych programistów (często młodych), którzy wykorzystują spreparowane skrypty do wyszukiwania i wykorzystywania niezabezpieczonych komputerów. Rosnące zagrożenie jest związane z pecetami \”zombie\” – komputerami, które raz zainfekowane, poszukują innych niezabezpieczonych komputerów, które zostają w podobny sposób zarażone.
Zabezpieczyć infrastrukturę
Bezpieczny serwis wymaga wsparcia bezpiecznej infrastruktury. To oznacza, że cała infrastruktura sieci: zapory ogniowe, systemy operacyjne, serwery sieciowych aplikacji i baz danych, muszą być zabezpieczone na wypadek ataków. Podatność na atak któregokolwiek z tych elementów naraża na szwank bezpieczeństwo całego serwisu.
ZASOBY: Standardy bezpieczeństwa
|
|
|
|
Center for Internet Security |
The Cult of the Dead Cow (cDc) |
|
|
|
|
Hacktivismo |
XSS – Cross-site scripting |
Zabezpieczyć naszą sieć
Najbardziej podstawowe i efektywne kroki, jakie można podjąć w celu uniknięcia naruszania bezpieczeństwa na poziomie sieci wiążą się z zainstalowaniem zapory ogniowej ze skutecznymi regułami.
Pierwszym krokiem jest zablokowanie wszystkich sieciowych protokołów, za wyjątkiem niezbędnych do działania naszego serwisu, który powinien wymagać jedynie TCP/ IP. Udostępnijmy tylko te serwery, które aktualnie są niezbędne, by serwis był widziany w internecie. Jeśli mamy osobne serwery WWW i baz danych, jedynie te pierwsze powinny być zmapowane za pośrednictwem zapory ogniowej. To oznacza, że regułę NAT (Network Address Translation) trzeba utworzyć jedynie dla serwera WWW, przez co damy mu zewnętrzny adres IP i umożliwimy klientom łączenie się z nim przez internet.
Dla serwerów, które są \”zNATowane\”, powinniśmy udostępnić jedynie potrzebne porty TCP/IP. To oznacza port 80 (domyślny port dla serwerów WWW) oraz port 443, o ile korzystamy z warstwy transportowej oraz cyfrowych certyfikatów dla naszego serwisu.
Wszystkie pozostałe porty powinny być zablokowane. Jeśli twórcy stron korzystają z FTP-a do zarządzania serwisem, rozważmy jego zablokowanie, a w jego miejsce utworzenie wirtualnej sieci prywatnej (VPN). FTP jest słabo zaprojektowanym protokołem i często może być źródłem nadużyć. Zważywszy na fakt, że większość komercyjnych zapór ogniowych (oraz oczywiście niektóre opensource\’owe zapory ogniowe, takie jak FreeSwan) umożliwiają połączenia VPN, zdecydowanie warto rozważyć tę opcję. Gdy już raz ją ustawimy, twórcy stron będą mogli bezpiecznie łączyć się zdalnie z serwerem, tak jakby znajdował się na lokalnej maszynie. To będzie znaczący postęp ze wszystkich punktów widzenia!
Jeśli nie możemy utworzyć VPN-a, a konieczny jest zdalny dostęp, powinniśmy przynajmniej użyć SSH FTP (http://en.wikipedia. org/wiki/SSH_file_transfer_protocol) zamiast zwykłego FTP-a, gdyż jest on mniej podatny na ataki. Podobnie zabrońmy korzystania z Telnetu zamiast SSH, który szyfruje ruch między klientem i serwerem.
Dodatkowe zabezpieczenia sieciowe można uzyskać w środowisku wieloserwerowym, przy wykorzystaniu serwera \”odwrotnego proxy\”. Obsługuje on wszystkie sieciowe żądania i w tle przesyła je do aktualnego serwera, który obsługuje żądanie. To oznacza, że klient sieciowy ma jedynie do czynienia z proxy i nie ma wiedzy na temat architektury naszej sieci i serwerów aplikacji. W efekcie trudniej jest wykorzystać potencjalne dziury w zabezpieczeniach. Takie podejście niesie ze sobą jeszcze inne korzyści, gdyż może umożliwić serwisom obsługę przez wiele serwerów i technologii, tak jakby pochodziły z jednej domeny, bez potrzeby uciekania się do dodatkowych poddomen. Zarówno Microsoft ISA Server, jak i Apache\’a można skonfigurować w taki sposób, by działały jako \”odwrotne proxy\”.
Zastanówmy się też nad korzystaniem z systemów wykrywania intruzów, takich jak Snort (http://www.snort.org). Snort oferuje więcej niż potrafi większość prostych zapór ogniowych i wchodzi głębiej w sieciowy ruch, dokonując analizy protokołów, wyszukiwania/porównywania treści.
Można go użyć do wykrywania różnych ataków i sond, takich jak przepełnienie bufora, skanowanie portów, ataki CGI, sondy SMB, OS fingerprint i wiele innych. Snort jest w pewien sposób podobny do systemu antywirusowego ze względu na obecność bazy reguł, która jest stale aktualizowana o nowe metody obrony przed exploitami i lukami w bezpieczeństwie. Snort jest produktem opensource\’owym, toteż bezpłatnie można go pobrać i zainstalować na linuksowych serwerach.
Aktualizować
Podczas gdy opinie co do wartości systemów operacyjnych Windows i Linuksa w kwestiach bezpieczeństwa różnią się, warto zaznaczyć, że ostatnie wersje Windows i różne odmiany Linuksa znacznie poprawiono w stosunku do ich poprzednich wersji. Prawdą jest też, że obydwa systemy mają luki bezpieczeństwa, jednak luki windowsowe są lepiej nagłośnione, gdyż dotyczą większej populacji użytkowników.
Jednak bez względu na to, na jakim systemie operacyjnym działa nasz serwis, najważniejszym zabezpieczeniem jest regularne aktualizowanie go o najnowsze łaty bezpieczeństwa. Z reguły to proste zadanie – Microsoft dostarcza mechanizm Microsoft Update, który można pobrać i za jego pomocą prosto instalować łaty. Dystrybucje Linuksa oferują podobne narzędzia – chociażby APT (Advanced Package Tool) w Debianie.
Wykorzystajmy paranoję dla dobra bezpieczeństwa
Pip Thorne – Technophobia
Myślmy o danych! Dlaczego to pole znalazło się w moim formularzu, jak mam być pewien, że dane są aktualne i co zrobię z danymi, gdy je otrzymam?
Najprostszym sposobem zabezpieczenia danych użytkownika jest niezamieszczanie ich w naszym serwisie. Jeśli jednak informacje są ważne, w jaki sposób je przechowywać, by być pewnym, że nikt trzeci nie uzyska do nich dostępu? Jakie środki należy przedsięwziąć, by mieć pewność, że osoba po drugiej stronie połączenia internetowego jest tą, za którą się podaje, zanim udostępnimy jej jakiekolwiek dane?
Im więcej zamieścimy na stronie rzucających się w oczy i ciekawych elementów, tym więcej możliwości oddamy komuś, kto będzie chciał znaleźć i wykorzystać braki w zabezpieczeniach. Dzieje się tak, gdy sami tworzymy kod (im większa baza kodu, tym więcej wymaga testów), a zwłaszcza jeśli korzystamy z bibliotek tworzonych przez osoby trzecie. Jeśli nie dysponujemy czasem, by napisać cały kod, czy znajdziemy czas, by sprawdzić go od podstaw?
Poddajmy się paranoi
Nie ufajmy nikomu. Żadna część naszego systemu nie daje gwarancji, że jest bezbłędna, toteż przez cały czas pamiętajmy o możliwościach wystąpienia błędów w technologii serwera, języku programowania, bazach danych itd. Trzymając się zdrowej paranoi przez cały czas, będziemy trzymać rękę na pulsie, co być może pomoże nam uniknąć katastrofy.
Stosujmy algorytmy haszujące do ochrony ważnych danych, jednak dobierajmy je starannie, gdyż wiele z nich łatwo złamać.
Nigdy nie ufajmy przeglądarce. Jakiekolwiek dane otrzymane za pomocą przeglądarki mogą bowiem być zmanipulowane przez hakerów. Przykładowo, nie zakładajmy, że łańcuch UserAgent nie będzie zawierać JavaScriptu tylko dlatego, że tak jest ustawione w przeglądarce. Może być złamany przez dysponującego odpowiednią wiedzą hakera.
Wprowadźmy kontrolę poprawności do każdej linijki kodu, JavaScriptu, skryptów serwerowych, interfejsu bazy danych i tworzenia stron.
Jeśli jest coś, co pomogło mi zrozumieć subtelności zabezpieczania internetowych serwisów, to był to cross-site scripting (XSS). Najlepiej go zrozumieć poprzez wyobrażenie sobie następującego scenariusza. Serwis banku online jest podatny na atak cross-site scripting, za pośrednictwem którego można umieścić JavaScript na stronie banku. Haker Henry wysyła e-mail do Briana, klienta banku, który korzysta z serwisu online, prosząc go o zalogowanie się do serwisu na swoje konto bankowe poprzez kliknięcie linku zamieszczonego w e-mailu. Brian naiwnie robi to. Link, który wysłał Henry zawiera porcje JavaScriptu, który wysyła ciasteczka sesji Briana na komputer Henry\’ego (za pomocą specjalnie przygotowanego serwera). Ten serwer uzyskał teraz informacje o tożsamości Briana i automatycznie wysyła wszystkie pieniądze Briana do Nigerii.
Oczywiście to bardzo uproszczony scenariusz, przed którym banki online potrafią się zabezpieczyć. Jednakże jego główne założenia mają zastosowanie w stosunku do wszystkich serwisów przechowujących dane swoich klientów.
WYWIAD: Dave Barter
Dave Barter dzieli się doświadczeniem zdobytym podczas tworzenia bezpiecznych serwisów
Imię i nazwisko: Dave Barter
Stanowisko: dyrektor i założyciel
Firma: Legatio Technologies
URL: http://www.legatio.com
Dla świeżo upieczonych twórców stron kuszące może być poświęcenie godzin na poszukiwanie eliksiru, który sprawi, że tworzone przez nich serwisy w magiczny sposób staną się bezpieczne. Zamiast tego odkryjemy, że będziemy grzebać przy różnych rodzajach produktów zabezpieczających w złudnej nadziei, że w jakiś sposób zabezpieczą nasze aplikacje.
Próba uczynienia serwisu bezpiecznym bez sprawdzonej metody lub struktury jest bezproduktywna, gdyż tracimy cenny czas grzęznąć w zawiłościach śledzenia, instalacji i łat. Serwis z zainstalowanymi produktami zabezpieczającymi, które nie spełniają swojej roli jest tak samo niezabezpieczony, jak serwis bez nich.
Gdy zabezpieczamy serwis, niczym nie da się zastąpić doświadczenia. Jednak nawet jeśli jesteśmy nowicjuszami w kwestiach bezpieczeństwa, kilka prostych zasad może nam pomóc w zmniejszeniu ryzyka ataku hakera.
Wiele bezpiecznych aplikacji zostało złamanych z powodu dziur bezpieczeństwa środowiska, w którym funkcjonowały. Zanim zdecydujemy się na udostępnienie aplikacji w internecie, musimy być pewni środowiska, w którym będą działać.
Często nie mamy nad tym kontroli, gdyż środowisko dostarcza dostawca usług internetowych lub dział IT.
Toteż zadajmy im kilka pytań:
- Jak kontrolowany jest dostęp do tego środowiska?
- Czy działają w nim aktualne wersje oprogramowania (serwery, bazy danych itp.)?
- Czy na wypadek pojawienia się problemów z bezpieczeństwem, istnieje właściwy proces aktualizacji komponentów systemu?
- Czy moje aplikacje są chronione przed innymi?
- Czy opracowano politykę bezpieczeństwa, plan tworzenia kopii zapasowych i plan ratunkowy na wypadek katastrof?
Wymienione pytania są także ważne w przypadku, gdy sami dostarczamy środowisko. Musimy mieć zaufanie do naszego środowiska, zanim wgramy tam choć jedną linijkę kodu HTML.
WYWIAD: Sean Gardiner – Precedent Communications
Trudno nie wpaść w obsesję na temat bezpieczeństwa serwisu, gdy mrożące krew w żyłach historie o tym, jak można zniszczyć ludzkie życie codzienne pojawiają się w prasowych doniesieniach. Moim zdaniem główny problem z bezpieczeństwem serwisów leży w wykorzystaniu luk w kodzie serwisu i słabych hasłach zabezpieczających.
Wykorzystanie kodu serwisu
Większość serwisów i sieciowych aplikacji została opracowana przede wszystkim po to, by ułatwić ludziom wykonanie jakiegoś zadania, np. kupowania online lub zarządzania serwisem. Niestety ostatnią kwestią, nad którą się zastanawiamy, gdy planujemy serwis, jest to, jak hakerzy mogą wykorzystać serwis do swoich celów. Unikanie sytuacji, w których można wykorzystać nasz kod w większości przypadków jest dosyć proste.
Hakerzy zazwyczaj będą się starać dobrać się do naszej bazy danych lub skorzystać z funkcjonalności poczty elektronicznej. Obrona przed takimi atakami jest dobrze udokumentowana. Pamiętajmy, że hakerzy będą zawsze próbować czegoś nowego, więc wskazane jest regularnie przeglądanie zabezpieczeń serwisu.
Ochrona za pomocą słabego hasła
Najprostszym sposobem spustoszenia serwisu jest uzyskanie dostępu do panelu kontrolnego systemu. Pierwszą rzeczą, którą musi zrobić haker jest odgadnięcie lub zapytanie o hasło. Choć brzmi to nieprawdopodobnie, niektóre systemy zostały ominięte przez hakerów, którzy zadzwonili do działu obsługi i poprosili o podanie hasła! Można przedsięwziąć dodatkowe zabezpieczenia w rodzaju zezwolenia na dostęp do systemu jedynie z określonych adresów IP.
PORADY EKSPERTÓW: Mog, Mike Cherin i Dave Barter
Zawsze bądźmy świadomi potencjalnych zagrożeń SQL. Nigdy nie dopuszczajmy do sytuacji, w której niedoświadczony użytkownik wprowadza kod SQL.
(Mog, http://www.mogmachine.com)
Samozadowolenie to wróg większości reguł bezpieczeństwa. Powinniśmy stale przyglądać się operacjom naszych aplikacji i ich środowisku oraz poszukiwać sposobów poprawy obszarów, które uważamy za słabe.
(Dave Barter, http://www.legatio.com)
Nigdy nie udostępniajmy światu struktury plików w naszej domenie. Trzymajmy ją pod kluczem. Jeśli nie wiemy, jak to zrobić, nauczmy się. Eksperymentowanie to w tej sytuacji niewybaczalny błąd. Pliki z publicznym dostępem są słabym punktem, ale nie muszą nim być. Prawa własności można przekazać aplikacji, która wymaga dostępu, gdzie dostęp można usunąć dla wszystkich innych.
(Mike Cherim, http://GreenBeast.com)
Nie ufajmy jakimkolwiek danym wejściowym. Wiele aplikacji jest narażonych na ataki hakerów, włączając w to nieoczekiwane dane wprowadzone w formularzach służących do zapisywania się lub w uploadowanych danych. Zawsze musimy zakładać, że wraz z danymi wejściowymi może przyjść najgorsze, bez względu na to skąd pochodzą dane. Sprawdźmy to, by upewnić się, że odpowiadają one formatowi, którego oczekiwaliśmy (przykładowo, numery telefonów to dane numeryczne) i wyrzućmy je natychmiast, jeśli okażą się być czymś innym.
(Dave Barter, http://www.legatio.com)
Zawsze weryfikujmy i filtrujmy dane wprowadzane przez użytkowników: czy to są formularze czy jest to wyszukiwanie – nie ma znaczenia. Filtrujmy wszystko.
(Mike Cherim, http://GreenBeast.com)
Ograniczmy przywileje. Nasza aplikacja powinna jedynie zezwalać na dostęp do danych i zasobów, które są niezbędne do wykonania danych zadań.
(Dave Barter, http://www.legatio.com)
Na podstawie monitoringu logów można zebrać mnóstwo informacji o błędach, dostępie, przekierowaniach i plikach, do których był dostęp. Wszystko to może nam ujawnić dziury. Dobrze jest przyjrzeć się fizycznej strukturze plików w poszukiwaniu anomalii – np. plików, których nie rozpoznajemy, bądź plików z datami aktualizacji późniejszymi niż były aktualizowane.
(Mike Cherim, http://GreenBeast.com)
Wyłapujmy i raportujmy błędy. Zbyt prosto jest założyć, że nasz program będzie działać tak, jak tego oczekujemy. Wiele najgroźniejszych wadliwych zabezpieczeń pojawia się wskutek słabej procedury obsługi wyjątku w kodzie. Powinniśmy stale przeglądać kod, dzięki czemu nabierzemy pewności, że wyłapaliśmy wszystkie błędy.
(Dave Barter, http://www.legatio.com)
Przygotujmy plan odpowiednich testów dla naszych aplikacji i przeprowadźmy go. Rozważmy skorzystanie z osobnego serwera testowego. Dzięki temu umożliwimy naszym aplikacjom i środowisku pracę w prawdziwym środowisku, zanim udostępnimy je światu.
(Dave Barter, http://www.legatio.com)
UNIKANIE NIEBEZPIECZEŃSTW: Peter Hammans – Precedent Communications
Każdy twórca stron zdaje sobie sprawę, że bezpieczeństwo serwisu to sprawa ważna, ale tylko nieliczni poświęcają swój czas i się tym zajmują. Zadziwiające jest, jak często klienci biznesowi nawet nie wymawiają słowa \”bezpieczeństwo\” w czasie prac nad projektem. Jako twórca stron często spotykałem się z kwestiami zabezpieczeń. Choć są to sprawy poważne, zaskakująco prosto ich uniknąć.
Szyfrowanie danych formularzy i żądań HTTPS
Około połowa systemów płatności online, z którymi się spotkałem, nie korzysta z SSL i HTTPS do zabezpieczania danych. To oznacza, że osobiste dane, hasła oraz, na przykład, dane kart kredytowych są przesyłane zwykłym tekstem. To w oczywisty sposób ułatwia hakerom oglądanie i kolekcjonowanie osobistych informacji.
Zastrzyk SQL
Kwerendy SQL bardzo często umożliwiają manipulowanie lub przeglądanie danych w tabelach baz danych. Zazwyczaj odbywa się to za pomocą formularza (lub kilku formularzy) – czegokolwiek od prostego zapytania po wielowarstwowe sieciowe aplikacje. Hakerzy mogą zmieniać tabele informacji, wychodząc poza zamierzony zakres zapytania poprzez proste zdefiniowanie dodatkowych parametrów wejściowych użytkownika. To prawdopodobnie jeden z najpowszechniejszych i najprostszych sposobów, w jaki hakerzy mogą wchodzić w interakcje z serwisem i zarazem jest to jedna z podstawowych kwestii bezpieczeństwa, którą należy uwzględnić.
Bezpieczeństwo hasła i personalizacja
Kilka firm wprowadziło politykę stosowania haseł, która mogłaby pomóc użytkownikom zabezpieczyć ich własne konta. Niepowodzenie w sprawieniu, by użytkownicy byli bezpieczni, to efekt ogólnego braku bezpieczeństwa serwisu.
PORADY EKSPERTA: Wyprowadzić w pole spamboty
Problemem, z którym boryka się wiele stron jest przerażający spam – a konkretnie spamboty, które wędrują po serwisach i zbierają adresy e-mailowe lub wykorzystują funkcjonalności społecznościowe w rodzaju forów do wysyłania postów.
Niestety, unikanie wydobywania przez nie adresów e-mailowych jest czymś w rodzaju wyścigu zbrojeń. W jakikolwiek sposób będziemy starać się zakodować adres e-mailowy, to i tak twórcy spambotów ominą to.
Techniki służące do dynamicznego wprowadzania adresów e-mailowych za pomocą JavaScriptu lub Ajaksa wydają się obecnie działać, gdyż spamboty nie uruchamiają JavaScriptu (jeszcze).
Dzięki temu otrzymamy user@domain.com
Alternatywnie możemy użyć techniki CSS:
.email:user { content: \"user@\"; }
.email:domain { content: \"domain.com\"; }
Możemy to umieścić na stronie HTML, jak poniżej:
Rezultat będzie taki sam, jak wyżej.
Bez względu na to, jakiej techniki użyjemy, twórcy spambotów odkryją ją i obejdą.
Techniki JavaScript mają jeszcze jedną wadę – nie działają, gdy JavaScript jest zablokowany lub gdy użytkownicy znajdują się za firmowymi zaporami ogniowymi, które nie pozwalają na uruchomienie JavaScriptu. Taka sytuacja narusza podstawową zasadę sieciowej dostępności.
Ochrona przed botami, a nawet uporczywymi użytkownikami, którzy na forum wysyłają spam może być trudna. Popularna technika polega na użyciu obrazków CAPTCHA. Zostały one celowo zniekształcone w taki sposób, by utrudnić ich odczytanie robotom.
Użytkownik jest w stanie odczytać prezentowaną na nich informację, zarejestrować się i umieścić posta na forum. Są skuteczne w walce z botami. Stwarzają jednak problemy z dostępnością. Użytkownik, który ma problemy ze wzrokiem, nie będzie w stanie odczytać obrazka i nie wyśle posta na forum. Najprostsza technika wymaga rejestracji użytkownika za pomocą prawdziwego adresu e-mailowego. Nie może on wysyłać postów, dopóki nie potwierdzi rejestracji, odpowiadając na wysłanego do niego e-maila. Wiele pakietów forów zawiera tę i inne funkcje bezpieczeństwa. Więcej informacji na temat technik czynienia spambotów nieskutecznymi można znaleźć pod adresem http://tinyurl.com/2oo822.
