W tym wpisie chciałbym przyjrzeć się jednej z podatności bezpieczeństwa, którą odkryłem w jednym z projektów wykorzystując plugin do mavena skanujący zależności - org.owasp:dependency-check-maven . Narzędzie to pomaga wychwycić znane podatności, które dotyczą naszej aplikacji tylko dlatego, że korzystamy z konkretnej wersji zależności (biblioteki, frameworka), która zawiera błąd bezpieczeństwa. Błędy te zaliczają się do kategorii A06 (przed 09.2021 - A09) z listy OWASP TOP 10 ( https://owasp.org/www-project-top-ten/ ). Swoją drogą polecam każdemu przeskanowanie swoich projektów takim skanerem aby zobaczyć jak wiele niebezpieczeńsw pociąga za sobą beztroskie korzystanie z mnóstwa bibliotek. Względne bezpieczeństwo daje nam tylko przypadek spowodowany tym, że akurat nie korzystamy z jakiejś konkretnej funkcjonalności. Tak będzie i w moim przypadku :). CVE-2021-22119 Dokładny opis błędu można znaleźć m.in. tu https://nvd.nist.gov/vuln/detail/CVE-2021-22119 . Dlaczego skupiłem się n
Czy spotkałeś kiedyś się z kodem takim jak poniższy? if (logger.isDebugEnabled()) { logger.debug("Request: " + requestObject); } Ja tak. Jakiś czas temu napotkałem na mnóstwo takich fragmentów w kodzie, który analizowałem. Zastanowiło mnie po co została wykorzystana tutaj instrukcja warunkowa - a jako, że if-y uwazam za zło konieczne postanowiłem to zbadać. Czy nie do tego właśnie służą biblioteki do logowania i udostępniane przez nie metody jak debug żeby właśnie sterowane konfiguracją decydowały co zalogować a co nie? Co więcej, okazało się, że instrukcję warunkową wprowadził ktoś w ramach większej akcji. I jak się okazuje, prawdopodobnie znacznie zwiększył dzieki temu wydajność aplikacji. W dzisiejszym wpisie postaram się wyjaśnić jak korzystać z loggera aby nie zaszkodziło to wydajności. Po co if-y? Na początek wyjaśnić trzeba czemu ten if tak na prawdę służy. Korzystamy z biblioteki do logowania i spodziewamy się, że wykorzystujac wybraną metodę, zostanie