Backend

10 najpopularniejszych według OWASP rodzajów ataków sieciowych

2 maja 2019 Kamil Piętka

Zagadnienie bezpieczeństwa aplikacji internetowych, a więc e-commerce, usług SaaS, serwisów internetowych, a nawet stron internetowych opartych na systemach CMS, staje się ostatnio coraz głośniejsze. W ostatnich latach zaobserwowaliśmy wiele wycieków danych osobowych użytkowników z popularnych serwisów. Są one bardzo groźne same w sobie, a konsekwencje spotęgowane są przez ich skalę – w przypadku niektórych Web Aplikacji możemy mówić o milionach użytkowników. Zdobyte przez cyberprzestępców dane pozwalają między innymi na przejęcie tożsamości użytkowników, wykorzystanie ich w działaniach przestępczych – lista potencjalnych zagrożeń jest bardzo długa, a wpisanie adresów e-mail użytkowników zhackowanego systemu na listę SPAMingową to jedna z mniej dotkliwych konsekwencji.

Kamil Piętka. Backend programmer w DevPark. Doświadczony programista, którego domeną jest tworzenie backendu aplikacji webowych i mobilnych. W 2018 roku zdobył certyfikat potwierdzający umiejętności programowania z wykorzystaniem frameworka Laravel. W swojej pracy posługuje się technikami TDD, DDD oraz wzorcami *programistycznymi*. Kieruje się zasadami tworzenia czystego kodu i dobrymi praktykami *programistycznymi*. Szczególną uwagę zwraca na bezpieczeństwo danych i dostępu do nich w aplikacjach, które tworzy.

Zagadnienie jest na tyle ważne i szerokie, że niedawno wprowadzona dyrektywa GDPR pozwala na nałożenie ogromnych kar na przedsiębiorców, którzy w niedostateczny sposób zabezpieczyli dane swoich użytkowników, a w przypadku dopuszczenia do wycieku, nie podjęli odpowiednich kroków w celu minimalizowania strat.

Przyczyną wycieków danych są przeważnie podatności w budowie aplikacji, które zostają wykorzystane przez hackerów do przeprowadzenia ataku. O najpopularniejszych atakach, wykorzystywanych w nich podatnościach, oraz o tym, jak się przed nimi chronić, przeczytacie w dalszej części artykułu.

Spis treści

Czym jest OWASP?

The Open Web Application Security Project to organizacja non-profit monitorującą rynek aplikacji internetowych pod kątem bezpieczeństwa. OWASP została powołana w celu zbierania informacji dotyczących ataków w sieci, ujednolicenia typów ataków i publikowania informacji na temat najczęściej występujących zagrożeń. OWASP cyklicznie publikuje listę “Top 10 Web Application Security Risks”, która pokazuje, jakie ataki są najczęściej spotykane. Ostatnia aktualizacja listy miała miejsce w 2017 roku.

Warto zapoznać się z listą, aby być świadomym przed czym powinniśmy chronić nasze aplikacje i w jaki sposób.

Injection

Problem pojawia się w przypadku interpretowania dostarczonych danych wejściowych jako część komendy lub zapytania. Dane podstawione przez hakera potrafią w sprytny sposób zmienić założenia wykonywane przez komendy lub zapytania.

Injection może występować pod postacią:

SQL – injection queries do zapytania SQL,
NoSQL – wpływa na bazy danych NoSQL,
OS – wykonanie komendy ze złośliwymi danymi wejściowymi,
LDAP – wykonanie komendy, która powinna być dozwolona jedynie po wcześniejszej autoryzacji zakończonej sukcesem.

Pamiętajmy, że Injection jest na szczycie listy ponieważ ten typ ataku jest łatwy do wykonania. Spójrzmy teraz jak się przed tym bronić na serwerze produkcyjnym.

Używajmy preare statement i parameter bindings i unikajmy Raw Query gdzie tylko możliwe

Zawsze przy tworzeniu zapytań warto się zastanowić czy możliwe jest ograniczenie zbioru danych, na który będzie miało wpływ zapytanie, wtedy ograniczymy ewentualne skutki ataku. Jednym z dobrych rozwiązań jest stosowanie dyrektywy Limit.

Wszystkie przychodzące dane powinniśmy walidować przed ich użyciem, w czym pomogą nam narzędzia walidacyjne dostarczone przez Laravel.

Przyjrzyjmy się funkcji filter_var pozwalającej na walidowanie danych według założonego klucza. Warto wiedzieć, że ta metoda jest wykorzystana przez Laravel podczas walidacji adresów e-mail, gdzie jako klucz brana jest stała FILTER_VALIDATE_EMAIL.

Kolejnym ważnym procesem obróbki danych przed ich docelowym użyciem jest escapowanie. Laravel, a dokładnie silnik Blade, robi to za naszymi plecami po użyciu znaczników {{ $variable }}.

Pamiętajmy, że php oferuje nam kilka przydatnych metod chroniących przed Injection:

strip_tags,
htmlspecialchars,
htmlentities,
mysqli_real_escape_string,
escapeshellcmd.

Podsumowując, musimy zawsze pamiętać o:

sanitazacji/walidacji wszystkich przychodzących danych przed ich użyciem,
escapowaniu danych wychodzących przed przekazaniem ich do docelowego użycia.

Broken Authentication and Session Management

Zarządzanie sesjami to nieodłączna część każdej nowoczesnej aplikacji. Rejestrujemy użytkowników, weryfikujemy ich za pomocą e-mail i wtedy dajemy dostęp do kolejnych funkcjonalności w naszym systemie. W części z ograniczonym dostępem użytkownik ma dostęp do swoich danych prywatnych. Takie dane mogą być wrażliwe, więc nie możemy dopuścić do wycieku albo dostępu do danych osób nieuprawnionych. To my, jako programiści, jesteśmy odpowiedzialni za przygotowanie bezpiecznych mechanizmów sesji i uwierzytelnienia.

Korzystamy z narzędzi Laravel. Z reguły wykorzystujemy podstawową paczkę Laravel Auth, która zapewnia ochronę sesji na poziomie przeglądarki jak i API (proste tokeny). Aplikacja uwierzytelnia użytkownika za pomocą username (e-mail) i hasła, które jest hashowane z wykorzystaniem algorytmu bcrypt. Bcrypt jest jednostronny, co oznacza, że nie ma możliwości przywrócenia hasła do początkowej treści. Resetowanie hasła odbywa się poprzez proces z wysłaniem linka resetującego na adres e-mail przypisany do konta.

Zgodnie z dzisiejszymi trendami można zaoferować uwierzytelnienie poprzez portale social media takie jak facebook, github etc., z wykorzystaniem paczki Socialize od Laravela, która jest łatwa i przyjazna w użyciu oraz wspiera wszystkie popularne portale.

Budując dobrze zabezpieczone API pamiętajmy o udostępnianiu danych tylko zaufanym aplikacjom.

Implementując serwer autoryzacyjny po naszej stronie, warto korzystać z Oauth2 i paczki Passport. Passport dostarcza niezbędne narzędzia do zarządzania grantami, definiowaniem scopów oraz uwierzytelnienia za pomocą access tokena.

Widzimy, że Laravel jest odpowiednim frameworkiem do napisania nowoczesnej aplikacji, która zabezpiecza dane swoich użytkowników. Oczywiście zawsze można zrobić więcej. Jednym z rozwiązań, które możemy wprowadzić to two-factor authentication przez SMS lub aplikację 2FA Google. Kolejnym rozwiązaniem zabezpieczającym przed atakami brute force jest ograniczenie błędnych prób logowania lub zwiększenie interwału czasowego po nieudanej próbie logowania. Możemy też wymusić od użytkowników używanie silnych haseł. Z tym, że lepszym rozwiązaniem weryfikacji siły hasła będzie sprawdzenie wśród 10000 popularnych haseł niż narzucanie użytkownikowi wzorca. Wraz z releasem wersji 7.2, PHP zaczął wspierać algorytm Argon2, którego od wersji 5.6 Laravela możemy użyć do hashowania hasła.

Pamiętajmy o używaniu protokołu HTTPS, który stał się już standardem w dzisiejszym Internecie. Żaden użytkownik nie będzie czuł się bezpiecznie, jeżeli na stronie logowania zobaczy ostrzeżenie o niezabezpieczonym połączeniu.

Na koniec warto przestrzec przed trzymanim sesji po stronie przeglądarki z wykorzystaniem cookie driver. Pamiętajmy, że nie możemy ufać danym, których nie mamy pod kontrolą. Nigdy nie mamy pewności, czy ktoś nie próbował przy nich manipulować.

Sensitive Data Exposure (including General Data Protection Regulation)

W związku z prowadzeniem nowych regulacji dotyczących ochrony danych osobowych, wielu z nas musiało zastanowić się jak zabezpieczyć dane użytkownika przed potencjalnymi atakami. Pamiętajmy o zabezpieczaniu danych zarówno w miejscu składowania (najczęściej jest to baza danych), jak i w transmisji, co zapewni nam wdrożenie HTTPS.

Wycieki danych mają dwa potencjalne źródła: wewnętrzne (wewnątrz organizacji) i zewnętrzne.

Wewnętrzne wycieki pojawiają się, jeżeli korporacja niewystarczająco zadba o zarządzanie dostępami do systemów i serwerów. Zalecane jest przeprowadzanie okresowych audytów w swoim zespole, którego celem jest upewnienie się, że żadne dane nie wyciekły. Odpowiedzialna osoba, z reguły manager lub team leader, przeprowadza szkolenia wśród swoich pracowników o tematyce wycieku danych, zabezpieczeniu danych i udostępnianiu ich poprzez social media. Oczywiście najlepszym podejściem jest uruchomienie VPN (Virtual Private Network) wraz z dostępami LDAP, wtedy zarządzanie dostępami jest zdecydowanie łatwiejsze.

Tworzenie oprogramowania składa się z kilku etapów, warto zaangażować w ten proces więcej niż jedną osobę, z wyraźnym podziałem ról. W tym momencie odpowiedni proces wytwarzania oprogramowania buduje się w naturalny sposób. Programista tworzy kod, otwiera pull request w repozytorium, osoba odpowiedzialna za code review sprawdza kod i prawdopodobnie już na tym etapie wykryje w kodzie luki, narażające aplikację na ataki. Dopiero zatwierdzenie PR i złączeniu do repozytorium, DevOps publikuje na serwerze, wiedząc, że kod jest poprawny.

Wspomnieliśmy, że występują również zewnętrzne przyczyny wycieku danych użytkowników. Dlatego każdy serwer powinien być poprawnie skonfigurowany, a osoba zajmująca się serwerem musi posiadać odpowiednią wiedzę i podejmować świadome kroki. Słaba ochrona serwerów, gdzie trzymamy kopie zapasowe baz danych może być przyczyną wycieku bardzo dużej ilość danych, stąd powinniśmy szyfrować wszystkie maszyny. Wtedy nawet w przypadku wycieku danych będą one bezużyteczne dla potencjalnego hakera. Nasze usługi możemy przenieść do chmury. Dostawcy usług chmurowych są świadomi potencjalnych zagrożeń i dbają o jakość swoich usług. Weźmy za przykład usługi Amazon, gdzie dostawca szyfruje swoje instancje w standardzie AES-256.

Dodatkowo możemy szyfrować dane w własnym zakresie wykorzystując narzędzie Laravel Encryption. Pamiętajmy, żeby nigdy nie próbować budować własnego szyfrującego narzędzia.

XML External Entities (XXE)

Ataki XXE są przeprowadzane w momencie parsowania XML dostarczonego z zewnętrznego źródła. Jest to atak podobny do Injection, ponieważ ma miejsce w momencie przetwarzania XML zawierającego referencje do zewnętrznych źródeł, które zostaną załadowane do treści XML. Z przetwarzaniem plików XML spotykamy się w technikach, takich jak: SOAP, RSS, SAML.

Budując parser XML musimy mieć na uwagę zagrożenia pojawiające się w atakach XXE. Zanim XML zostanie sparsowany przeprowadźmy walidacje i sanitacje po stronie serwera. W większości zastosowań znamy schemat XML a priori, ta wiedza pozwoli na zdecydowanie czy potrzebujemy wczytywać dane z zewnętrznych źródeł. Jeżeli uważamy, że nie jest to nam potrzebne, wyłączmy możliwość ładowania z zewnętrznych źródeł na poziomie biblioteki za pomocą funkcji libxml_disable_entity_loader (libxml2).

Przy pracy z protokołem SOAP przeprowadźmy aktualizację przynajmniej do wersji 1.2.

Broken Access Control

W przypadku aplikacji, kontrola dostępu polega na zidentyfikowaniu czy użytkownik ma dostęp do funkcjonalności lub zasobu. W aplikacji część funkcjonalności jest przewidziana jedynie dla roli super admin. Może to być związane z danymi do jakich ma dostęp, bądź wpływać na pozostałą część aplikacji. Jeżeli haker uzyska dostęp do kont użytkownika, zobaczy ich dane wrażliwe, może mieć też możliwość modyfikacji ról dostępu.

Laravel dostarcza dwa narzędzia ułatwiające implementacje polityki dostępowej, tj. gates i policies.

Gates decydują czy użytkownik na dostęp do wykonania danej akcji. Jeżeli aplikacja składa się funkcjonalności dostępnych do różnych ról, gates poradzą sobie z tym. Dodatkową zaletą jest separacja componentów na poziomie kodu. Po zdefiniowaniu gate pod nazwą super-admin, w pliku routingu możemy posłużyć się aliasem can:super-admin, co widać w kodzie poniżej.

Drugim aspektem, który musimy rozważyć, jest dostęp do danych osób trzecich. Wgląd do danych może mieć jedynie ich właściciel. Na poziomie aplikacji zapewni nam to narzędzie Policies. Policy pozwala pokazać zasoby tylko właścicielowi i odrzucić nieautoryzowane próby dostępu.

Policy duplikuje nazwy kontrolerów

Aplikacja autoryzuje dane zanim udostępni zasoby

Security Misconfiguration

Poprawna konfiguracja serwera wydaje się sprawą oczywistą. Niestety nie zawsze tak jest. Nie każdy z nas musi się na tym znać. Warto wtedy skorzystać z usług specjalistów – czy to będzie usługodawca czy specjalista DevOps. Zakładając, że nasz serwer jest skonfigurowany poprawnie, to i tak nie gwarantuje nam tego, że nie pojawią się problemy. Tym bardziej, że z reguły naszym doradcą jest pośpiech co sprawia, że o aspektach bezpiecznej konfiguracji często nawet nie myślimy.

Prosty scenariusz: budujemy nową aplikację, testujemy na serwerze developerskim i jeżeli nie ma żadnych błędów wrzucamy na serwer produkcyjny w chmurze, gdzie nie została zdefiniowana konfiguracja dostępów lub zapomnimy wyłączyć renderowania błędów. W rezultacie użytkownicy widzą cały stack naszej aplikacji i może to później zostać wykorzystane przeciwko nam.

Dzisiejsze aplikacje już na starcie są wyposażone w zewnętrzne serwisy, które są niepotrzebne naszej aplikacji. Warto się na tym zastanowić i wyłączyć lub usunąć nieużywane biblioteki.

Dla usystematyzowania budowania dobrego środowiska produkcyjnego warto się odpowiednio przygotować. Po pierwsze wybierzmy narzędzia, które będą nam pomagać przy deploy’ach. Część czynności będą wykonywać automatycznie, bez naszego wysiłku. Może to być Jenkins. Powtarzalne procesy są szybkie i proste w automatyzacji. Jeżeli proces publikowania jest na serwerze i mamy zautomatyzowane procesy, postarajmy się zastosować ten sam schemat na wszystkich instancjach., tj. develop, staging, production. Dzięki temu nasze instancje będą różnić się jedynie konfiguracją zmiennych środowiskowych (np. dostępy) a to uchroni nas przed niespodziankami na produkcji, których nie zaobserwowaliśmy na innych serwerach. Starajmy się również przeprowadzać audyt narzędzi, których używamy, choć na tym aspekcie skupimy się w 9-tym punkcie omawianej listy.

Cross-Site Scripting (XSS)

Ataki XSS pojawiają się, kiedy aplikacja wyśle dane pochodzące z nieznanego źródła do przeglądarki, bez wcześniejszej walidacji i escapowania. W rezultacie haker może przejąć sesję, zmienić treści na tronie lub przekierować użytkownika na inną stronę.

Ataki XSS mają dwie formy:

Store XSS – atak ma miejsce, kiedy haker podaje swój kod do bazy danych i przy odczycie dane nie zostaną odpowiednio escapowane przed przekazaniem do przeglądarki ofiary.
Reflect XSS – atak ma miejsce, kiedy niezwalidowane dane użytkownika zostaną załadowane do renderowanej strony. Może mieć to miejsce, jeżeli ofiara wykona zapytanie za pomocą podmienionego linka wysłanego w e-mailu.

Istnieją proste reguły, których przestrzeganie zabezpieczy naszych użytkowników przed atakiem XSS:

Zawsze walidujmy dane wejściowe.
Escapowanie danych zanim zostaną przekazane użytkownikowi.
Oczyść dane użytkownika przed zapisem.

Dobrą praktyką jest użycie metod POST i PUT do zapisu danych, Laravel dostarcza mechanizm ochrony przed Cross-Site Request Forgery.

Insecure Deserialization

Serializacja obiektów jest operacją stosowaną w naszych aplikacjach bez głębszego zastanowienia. Pełnoprawne obiekty po deserializacji dają nam więcej możliwości niż JSON czy XML, niestety może to powodować problemy i luki w zabezpieczeniach.

Procesy deserializacji są nieodłączną częścią wymienionych usług:

Remote- and inter-process communication (RPC/IPC),
Web services, Micro services,
Message brokers (Pusher),
Caching/Persistence,
Bazy danych, cache servery, file systems,
HTTP cookies, HTML form parameters.

Następstwem ataku może być DDoS, złamanie kontroli dostępu czy wykonanie zewnętrznego kodu. Haker zmienia dane w taki sposób, aby zakłócić procesy w aplikacji lub wprowadzić swoją logikę mając na celu zmianę zachowania aplikacji.

Powinniśmy starać się minimalizować ryzyko ataku poprzez akceptację deserializacji danych wyłącznie z zaufanych źródeł. Część aplikacji, na którą będzie miał wpływ deserializowany obiekt, powinna być odizolowana od reszty aplikacji a sam fragment kodu ograniczony w działaniu jak to tylko możliwe.

Logowanie przychodzących zapytań i monitorowanie wyjątków pomoże nam w blokowaniu ewentualnych ataków.

Using Components With Known Vulnerabilities

Wcześniej wspomnieliśmy o zewnętrznych paczkach, których używany w aplikacji. W dzisiejszych czasach, w erze composera, każda aplikacja współpracuje z zewnętrznym kodem, stąd pojawią się ryzyko, że któraś z zewnętrznych paczek będzie podatna na ataki.

Jak się przed tym ochronić?

Istnieje kilka zasad, których warto przestrzegać. Korzystajmy wyłącznie z paczek z oficjalnych źródeł. W procesie utrzymania kodu uwzględniajmy przegląd zewnętrznych bibliotek pod kątem aktualnych wersji, zarówno po stronie serwera jak i po stronie aplikacji klienckiej. To pozwoli utrzymać aktualność naszych paczek oraz wyizolować biblioteki, których przestaliśmy używać i możemy je usunąć z projektu.

Proces znajdywania componentów podatnych na ataki można zautomatyzować poprzez użycie dedykowanego narzędzia, jakim jest sensiolabs/security-checker.

To narzędzie zwróci nam raport zawierający komponenty, które zostały zgłoszone jako podatne na ataki. Następnie możemy sami zdecydować co zrobić – z reguły update takich paczek powinien rozwiązać problem.

Insufficient Logging & Monitoring

Możemy sobie wyobrazić, że poprawna polityka logowania i monitoringu systemu sprawi, że próba ataku zostanie wykryta, zanim zostanie on przeprowadzony. Ataki DDoS powodują zatrzymanie aplikacji, ale są też ataki, które są przeprowadzane równolegle z normalną pracą systemu. Takie ataki mogą pozostać niezauważone przez długi czas. Dlatego warto mieć CSP (Content Security Policy), która przewidzi takie scenariusze. Przy dużych aplikacjach, każdy komponent działa niezależnie, stąd też wymaga różnego podejścia do kwestii polityki bezpieczeństwa. Jeżeli równocześnie powstaje CSP możemy zbierać potencjalne słabości na bieżąco.

Laravel udostępnia nam Monolog. Wszechstronne narzędzie proste w użyciu (helper i facade), generujące przy okazji logi w przystępnym formacie. Monolog udostępnia kilka poziomów logowania błędów, od DEBUG, przez NOTICE aż do EMERGENCY.

Może się zdarzyć, że będzie nam zależeć na wysyłaniu logów na różne kanały (plik, slack), co jest możliwe w Laravel od wersji 5.6, kiedy to została dodana możliwość agregacji wielu kanałów logowania w jeden zmultiplikowany kanał.

Podsumowanie

Nasze aplikacje są narażone na wiele ataków. Powyższa lista nie zawiera wszystkich rodzajów ataków. Top 10 to te najczęściej spotykane w aplikacjach produkcyjnych. Powyższą listę traktujmy jako podstawę do stworzenia dobrze zabezpieczonej aplikacji.

Warto śledzić społeczność OWASP, aby być na bieżąco z aktualnymi trendami w bezpieczeństwie aplikacji.

Zobacz też