Koduj bezpiecznie w języku Java

Czasami maszyna wirtualna Javy się myli, a czasami nasz kod sprawia, że aplikacja jest mniej bezpieczna niż nam się wydaje. Zastanówmy się, czy naprawdę jesteśmy dobrymi programistami i czy potrafimy pisać wydajny i bezpieczny kod dla maszyn wirtualnych. Przejdziemy sobie przez przykładowy kod podstawowych ataków hakerskich w języku Java, zgodnie z OWASP Top 10, a następnie poznamy narzędzia, które pozwolą zminimalizować elementy ryzyka.

Po zakupie biletu wysyłamy lnik do dwugodzinnego spotkania online.

Dlaczego luki w Javie są tak niebezpieczne

Duża część naszego życia odbywa się w Internecie. Tak się składa, że wiele z tego jest napisane w Javie. Tradycyjnie aplikacje Java były duże i monolityczne. W nowoczesnych aplikacjach Java widać wyraźny trend w kierunku architektur mikroserwisowych, które są połączone za pomocą internetowych API (głównie REST API). W przeciwieństwie do aplikacji C/C++ wyzwaniem w testowaniu bezpieczeństwa aplikacji Java nie jest zabezpieczenie dostępu do pamięci, ale ogromna złożoność wynikająca z łączności między modułami i łączącymi je interfejsami API.

Jeśli zostaną wykorzystane luki w zależnościach aplikacji Java, można je wykorzystać do złośliwego szybkiego rozprzestrzeniania danych w wielu mikrousługach. Ponieważ wiele mikrousług w pełni ufa dane wejściowe ze źródeł wewnętrznych, osoby atakujące często mogą uzyskać dostęp do dużych części całego zaplecza internetowego za pośrednictwem małego punktu wejścia. Ostatnio pokazało to RCE znalezione w popularnej bibliotece Java log4j, która wpłynęła na tysiące aplikacji Java na całym świecie.
Chociaż nowoczesne architektury mikrousług są łatwiejsze w utrzymaniu i bardziej odporne na awarie, ich złożoność pozostawia niewiele miejsca na błędy. W związku z tym aplikacje Java muszą być dokładnie testowane i przy użyciu narzędzi testowych, które poradzą sobie z ich złożonością.

Czy Java jest bezpieczniejsza niż C/C++?

Języki bezpieczne dla pamięci, takie jak Java, Go lub Python, mają swoje nazwy od mechanizmów zapobiegania błędom w czasie wykonywania. W porównaniu z C/C++, to w zasadzie sprawia, że języki bezpieczne w pamięci są odporne na uszkodzenia pamięci. W połączeniu z faktem, że luki w zabezpieczeniach pamięci stanowią dużą część wszystkich luk (np. 90% luk w systemie Android), może to prowadzić do wrażenia, że Java jest znacznie bezpieczniejsza niż C/C++. Jednak to stwierdzenie musi być traktowane ostrożnie. Chociaż gęstość luk w Javie jest znacznie mniejsza niż w C/C++, luki w Javie mogą mieć katastrofalne konsekwencje, takie jak przestoje lub kradzież danych.

Typowe luki w Javie

Podczas gdy luki w C/C++ są częste, ale generalnie łatwiejsze do znalezienia, luki w Javie są często bardziej złożone. Fundacja OWASP utrzymuje listę dziesięciu najbardziej niebezpiecznych luk w zabezpieczeniach sieci. Aplikacje Java są podatne na większość z nich ...

Wstrzyknięcia SQL

Podczas wstrzyknięcia SQL (SQLi) lub podobnego ataku polegającego na wstrzyknięciu kodu, atakujący wprowadzają do systemu złośliwe instrukcje SQL za pomocą pola wejściowego (np. nazwy użytkownika lub hasła). Jeśli aplikacja nie oczyści takich danych wejściowych, zostanie wykonana instrukcja, która umożliwi atakującym dostęp do bazy danych.
Termin wstrzykiwanie SQL można podzielić na kilka podkategorii, w tym SQLis w paśmie, poza pasmem, oparte na błędach i oparte na Unii. Jednym z najlepszych sposobów zapobiegania wstrzykiwaniu SQL jest dokładne sprawdzanie danych wejściowych użytkownika, używanie filtrów i testowanie pod kątem luk, które mogłyby narazić bazę danych na działanie dowolnych poleceń.

Zdalne wykonanie kodu

Zdalne wykonanie kodu (RCE) to atak programowy, podczas którego atakujący wykorzystują luki w oprogramowaniu, aby przejąć kontrolę nad czyimś urządzeniem komputerowym, zwykle przez nakłanianie ofiar do pobrania złośliwego oprogramowania. Dzięki temu atakujący mogą kraść dane, monitorować urządzenia, przekierowywać fundusze i wykonywać inne złośliwe działania. Aby zapobiec RCE, za najlepszą praktykę uważa się wdrożenie zapór ogniowych, systemów ostrzegania i środków testowania bezpieczeństwa, które mogą wykryć potencjalnie szkodliwe luki w zabezpieczeniach.

Cross-Site-Scripting

Cross-site scripting (XSS) to szeroko rozpowszechniona luka w zabezpieczeniach aplikacji Java. Gdy zostanie wykorzystany, umożliwia atakującym wstrzyknięcie złośliwego kodu na strony internetowe. Kod jest następnie wykonywany w przeglądarce internetowej klienta. Korzystając z XSS, atakujący nie celują bezpośrednio w ofiarę, ale raczej w lukę w witrynie lub aplikacji internetowej, którą ofiara odwiedza lub z której korzysta. W ten sposób zagrożona strona internetowa zasadniczo służy jako kanał, w którym atakujący może wysłać złośliwy skrypt do przeglądarki ofiary. Skryptom między witrynami można zapobiec, unikając i sprawdzając dane wejściowe użytkownika oraz testując aplikacje internetowe pod kątem luk, które można wykorzystać.

Najbardziej spektakularny błąd Java stulecia: Log4j

Przykładem pokazującym znaczenie testowania bezpieczeństwa aplikacji Java jest RCE (CVE-2021-44228), który został znaleziony w bibliotece log4j o otwartym kodzie źródłowym w grudniu 2021 r. Ponieważ log4j jest bardzo popularnym narzędziem do rejestrowania, ujawnienie RCE dotyczyło niezliczonych aplikacji i ponad 3 miliardów urządzeń końcowych. Na początku stycznia w log4j wykryto kolejną lukę RCE, chociaż ta nie była tak poważna jak CVE-2021-44228.