Kolejnymi zagrożeniami na liscie OWASP 2017 są:
A3. Sensitive Data Exposure
Powszechne zagrożenie dla aplikacji internetowych - wyciek danych. Dane te to np. numery PESEL, karty kredytowe etc. Najczęstszą przyczyną wycieków tych danych są słabe zabezpieczenia bazy danych, brak szyfrowania danych czy też użycie słabych algorytmów szyfrowania.
W jaki sposób zapobiec wyciekowi poufnych danych?
- ogranicz ilość przechowywanych danych. Być może nie potrzebujesz ich w ogóle w aplikacji? Jeżeli jednak są wymagane do poprawnego działania systemu sprawdź regulacje prawne
- szyfruj dane oraz użyj bezpiecznych protokołów (TLS)
- szyfruj hasła używając silnych algorytmów (Argon2, PBKDF2). Unikaj stosowania MD5, SHA1, SHA256. Bądź na bieżąco z obecnymi standardami - algorytmy zmieniają się, wymyślane są nowe
- kiedy przeglądarka wyświetla poufne dane dodaj dyrektywy, które zapobiegną użycia cache dla poufnych informacji
A4. XML External Entities (XXE)
External Entities to elementy pozwalające budować XML w sposób dynamiczny. Podczas przetwarzania XMLa umożliwiają wstrzykiwanie definicji elementów z zewnętrznych źródeł.
Kiedy aplikacja jest narażona na ten typ ataku?
- aplikacja jako dane wejściowe przyjmuje bezpośrednio XML
- użycie SOAP < 1.2
- SOAPowy serwis używa DTD (document type definitions)
A5. Broken access control
Atakujący uzyskuje dostęp do funkcjonalności, do których normalnie nie miałby dostępu. Może się to odbyć np. poprzez modyfikację adresu url strony i uzyskanie dostępu do panelu administracyjnego, bądź też funkcji która jest normalnie widoczna tylko dla moderatora/administratora.
W jaki sposób bronić się przed tym typem ataku?
- warstwa autoryzacji powinna być zaimplementowana w jednym komponencie i reużywana przez wszystkie inne składowe systemu
- domyślnie zawsze zabraniamy dostępu do danego zasobu
- logujemy błędne próby logowania i analizujmy incydenty związane z wieloma próbami zalogowania się przy użyciu błędnych uwierzytelnień
- sesja użytkownika powinna być prawidłowo kończona po jego wylogowaniu z systemu
A6. Security misconfiguration
Ten typ zagrożenia wynika z stosowania domyślnych kont administratora, pozostawianiu niezabezpieczonych folderów na serwerze itp. Atakujący może w ten sposób dowiedzieć się więcej o systemie i poznać jego słabe punkty. Zagrożenia tego typu możemy spodziewać się na każdym poziomie: sieć, system, framework, aplikacja.
W jaki sposób zapobiegać tego typu atakom?
- automatyzacja manualnej konfiguracji (zwłaszcza powtarzalnej konfiguracji)
- środowiska (testowe, dweloperskie i produkcyjne) powinny mieć taka samą konfigurację
- nie instalujemy na serwerach zbędnego oprogramowania
- cyklicznie aktualizujemy system serwera i oprogramowanie na nim zainstalowane
A7. Cross-Site Scripting (XSS)
Atak ten polega na umieszczeniu niebezpiecznego kodu w treści strony. Nieświadomy użytkownik wchodząc na stronę uruchamia niepożądany kod infekując swój komputer. XSS dzielimy na trzy typy: Reflected XSS, Stored XSS, DOM based XSS.
Jak się zabezpieczyć przed tego typu atakiem?
- używajmy gotowych narzędzi w frameworkach
- poznajmy słabe strony frameworka, który używamy
- sprawdzamy dane pochodzące od użytkownika
- unikamy pracy z czystym HTMLem/JSptem
A8. Insecure deserialization
Zagrożenie to polega na wprowadzeniu do zserializowanej wiadomości nieuprawnionej treści. Treść ta może wpłynąć na sposób przetwarzania kodu, wywołać funkcje, których w normalnym procesowaniu byśmy nie wywołali.
Najlepszym sposobem obrony przed tym typem ataku jest nie przyjmowanie zserialozowanej treści z nieznanych źródeł. Innym sposobem walki jest deserializacja obiektów w odizolowanym środowisku z bardzo niskimi uprawnieniami. Nawet jeżeli do naszego systemu przedostanie się niechciany pakiet danych nie będzie on miał uprawnień do wykonania niebezpiecznych operacji. Monitorowania i logowanie błędów deserializacji - bardzo często da nam to informacje z jakiego źródła pochodzą podejrzane wiadomości.
A9. Using components with known vulnerabilities
Tu sprawa wydaje się dosyć prosta. Oprogramowanie zmienia się. Frameworki zmieniaja się. Wykrywane są nowe błędu i publikowane poprawki do nich. Uruchamiając aplikację w środowisku produkcyjnym musimy mieć świadomość, że po pewnym czasie będziemy musieli uaktualnić działające na nim oprogramowanie, framworki, bazy danych itp.
Dobrym sposobem zabezpieczenia jest także ograniczenie ilości oprogramowania uruchomionego na środowisku produkcyjnym - instalujemy tylko to co jest niezbędne. Warto także prowadzić i przestrzegać harmonogramu uaktualniania oprogramowania co pozwoli być na bieżąco ze wszystkimi aktualizacjami. Jeżeli instalujemy oprogramowanie - używajmy oficjalnych kanałów. Warto także monitorować serwisy poświęcone tematyce bezpieczeństwa np. https://www.cvedetails.com/version-search.php.
A10. Insufficient logging and monitoring
To przykład w jaki sposób pominięcie dobrego monitorowania i logowania może zagrozić naszemu systemowi. Atakujący wręcz liczy, że przez źle zaimplementowany monitoring zyska czas potrzebny do przeprowadzenia skutecznego ataku. Można też pójść w drugą stronę - logować zbyt wiele co prowadzi do kompletnego chaosu i uniemożliwia analizę logów.
Dobre logowanie przechwyci z pewnością wszelkie próby logowania do systemu z błędnymi poświadczeniami (dane te następnie możemy wykorzystać i zablokować potencjalnego atakującego). Logowanie powinno być spójne i przechowywane w centralnym miejscu umożliwiającym analizę danych. Możemy na przykład skorzystać z ELK bądź Splunk w celu magazynowania i przetwarzania logów. Oprócz logowania musimy zadbać też o odpowiednie powiadamianie.
