OWASP TOP 10, czyli najpoważniejsze problemy bezpieczeństwa aplikacji webowych

OWASP Top 10, to ogólnodostępny raport z dziesięciu najistotniejszych kategorii problemów bezpieczeństwa w aplikacjach webowych tworzony co cztery lata przez organizację non-profit OWASP (The Open Web Application Project), która zajmuje się badaniem podatności aplikacji na zagrożenia cybernetyczne.

Dynamiczne zmiany w świecie IT każdorazowo wpływają na raporty opracowywane przez OWASP co zostało wyrażone zmianami uwidocznionymi w 2021 roku poprzez uwzględnienie aż trzech nowych kategorii podatności, czyli Insecure Design, Software and Data Integrity Failures oraz Server-Side Request Forgery (SSRF).

Ponadto podatności uwzględnione w poprzednich raportach zmieniły swoje pozycje, co świadczy o tym, iż wzrosła liczba zagrożeń związanych z kategoriami:

• Broken Access Control, która z pozycji 5, jaką zajmowała w raporcie z 2017 roku, przesunęła się na pozycję 1,
• Vulnerable and Outdated Components (w raporcie z 2017 roku nazwana Using Components With Known Vulnerabilities), która z 9 miejsca przesunęła się na miejsce 6,
• Security Logging and Monitoring Failures (w raporcie z 2017 roku nazwana Insufficient Logging & Monitoring), która zmieniła pozycję o jedną – z 10 na 9,
• Security Misconfiguration, która z pozycji 6 jaką zajmowała w raporcie z 2017 roku, przesunęła się na pozycję 5.

W czteroletnim okresie, który dzieli oba raporty, z uwagi na podejmowane działania z zakresu cyberbezpieczeńswa i nieustannie wzmacnianą ochronę cybernetyczną spadła liczba ataków z kategorii Injection (z pozycji 1 na 3) oraz z kategorii Identification and Authentication Failures (nazwane w raporcie z 2017 roku Broken Authentication), która spadła z pozycji 2 na 7.

Obecnie w raporcie z 2021 r. lista zagrożeń OWASP Top 10 prezentuje się następująco:

A01:2021 – Broken Access Control, czyli Niewłaściwa Kontrola Dostępu,

A02:2021 – Cryptographic Failures, czyli Błędy Kryptograficzne,

A03:2021 – Injection, czyli Wstrzykiwanie Kodu,

A04-2021 – Insecure Design, czyli Niezabezpieczony Projekt,

A05-2021 – Security Misconfiguration, czyli Błędna Konfiguracja Zabezpieczeń,

A06-2021 – Vulnerable and Outdated Components, czyli Podane i Przestarzałe Komponenty,

A07-2021 – Identification and Authentication Failures, czyli Błędy Identyfikacji i Uwierzytelniania,

A08-2021 – Software and Data Integrity Failures, czyli Błędy Oprogramowania i Integralności Danych,

A09-2021 – Security Logging and Monitoring Failures, czyli Błędy w Rejestrowaniu Bezpieczeństwa i Monitorowaniu Awarii,

A10-2021 – Server-Side Request Forgery (SSRF), czyli Fałszerstwo Żądania po Stronie Serwera.

Każda z wyżej wymienionych podatności jest niezwykle groźna w skutkach, gdyż może prowadzić do ominięcia lub złamania zabezpieczeń i dalszych tego konsekwencji, np. wykradzenia lub utraty danych, przejęcia kontroli nad aplikacją webową, jej dyskredytacji, itp.

Warto zaznaczyć, że przy tworzeniu raportu organizacja OWASP przy każdej kategorii zagrożeń analizuje konkretne podatności aplikacji na zagrożenia z bazy Common Weaknes Enummeration (CWE), w której można znaleźć wszystkie zaraportowane sposoby na złamanie lub ominięcie zabezpieczeń.

Broken Acess Control – najpoważniejsze zagrożenie dla aplikacji webowych

Zgodnie z raportem OWASP Top 10 2021 najpoważniejsze zagrożenie dla aplikacji webowych stanowią podatności związane z uwierzytelnianiem oraz autoryzacją, czyli Broken Access Control, które występowały w aż 94% testowanych aplikacji. Podatności z tej kategorii polegają na tym, że użytkownik może zrobić w pewnych sytuacjach więcej niż zezwalają mu na to uprawnienia.

Badane aplikacje webowe okazały się podatne na zagrożenia CWE-200 (Exposure of Sensitive Information to an Unauthorized Actor), CWE-201 (Insertion of Sensitive Information Into Sent Data) oraz CWE-352 (Cross-Site Request Forgery).

Warto zaznaczyć, że właściwie funkcjonująca kontrola dostępu wprowadza zasady, dzięki którym użytkownicy mogą działać jedynie w granicach posiadanych uprawnień. Błędy zwykle prowadzą do nieautoryzowanego ujawnienia informacji, modyfikacji lub zniszczenia wszystkich danych lub wykonywania funkcji biznesowych przez użytkownika wykraczających poza przyznane mu uprawnienia. W ramach tej kategorii podatności do typowych luk bezpieczeństwa możemy zaliczyć:

• pełen dostęp do aplikacji udzielony każdemu użytkownikowi, co narusza zasadę najmniejszych uprawnień lub domyślnej odmowy, zgodnie z którą dostęp powinien być przyznawany tylko określonym użytkownikom, posiadającym jasno określone uprawnienia dostępu,
• umożliwienie omijania: kontroli dostępu poprzez modyfikację adresu URL (manipulowanie parametrami lub wymuszanie przeglądania), stanu aplikacji wewnętrznej lub strony HTML, albo użycie narzędzia do ataku modyfikującego żądania API,
• zezwolenie na przeglądanie lub edytowanie cudzego konta poprzez podanie jego unikalnego identyfikatora z uwagi na niezabezpieczenie bezpośredniego odniesienia do obiektów w kodzie aplikacji,
• umożliwienie dostępu do API bazy danych ze względu na brak kontroli dostępu dla żądań SQL: POST, PUT i DELETE,
• umożliwienie podniesienia przywilejów, czyli działania jako użytkownik bez bycia zalogowanym lub działanie jako administrator po zalogowaniu się jako użytkownik,
• umożliwienie manipulowania metadanymi, np. odtwarzanie lub manipulowanie tokenem kontroli dostępu JSON Web Token (JWT) lub plikiem cookie, albo manipulowane ukrytym polem w celu podniesienia uprawnień lub nadużycia unieważniania tokenu JWT,
• błędną konfigurację mechanizmu CORS, która umożliwia dostęp do interfejsu API z nieautoryzowanych lub niezaufanych źródeł,
• umożliwienie wymuszenia przeglądania stron wymagających uwierzytelnienia jako użytkownik nieuwierzytelniony lub stron uprzywilejowanych jako użytkownik standardowy (nieuprzywilejowany).

Należy zaznaczyć, że prawidłowa kontrola dostępu uniemożliwia atakującemu jej modyfikację, jak również uniemożliwia modyfikację metadanych.

Cryptographic Failures – drugie z kolei najpoważniejsze zagrożenie dla aplikacji webowych

Błędy kryptograficzne, wcześniej zwane ekspozycją danych wrażliwych, koncentrują się na błędach związanych z kryptografią (lub ich brakiem). Badane aplikacje webowe w ramach tej kategorii okazały się podatne na zagrożenia CWE-259 (Use of Hard-coded Password), CWE-327 (Broken or Risky Crypto Algorithm) oraz CWE-331 (Insufficient Entropy). Błędy te często prowadzą do ujawnienia danych wrażliwych lub naruszenia systemu, dlatego aby im zapobiec w pierwszej kolejności należy określić potrzeby w zakresie kompleksowej ochrony danych. Na przykład hasła, numery kart kredytowych, dokumentacja zdrowotna, dane osobowe i tajemnice handlowe wymagają dodatkowej ochrony, głównie, jeśli dane te podlegają przepisom dotyczącym prywatności, np. ogólnemu rozporządzeniu o ochronie danych (RODO) lub przepisom np. dotyczącym ochrony danych finansowych takich jak standard bezpieczeństwa danych PCI (PCI DSS).

Najczęściej błędy kryptograficzne występują, jeśli:

• dane przesyłane są w postaci zwykłego tekstu, w szczególności protokołami takimi jak HTTP, SMTP, FTP, również korzystających z aktualizacji TLS, np. STARTTLS, a zewnętrzny ruch sieciowy nie jest weryfikowany lub nie jest wystarczająco weryfikowany,
• w starszym kodzie lub domyślnie używane są stare lub słabe algorytmy szyfrowania albo protokoły kryptograficzne,
• domyślne używane są słabe klucze kryptograficzne lub brakuje odpowiedniego zarządzania kluczami, albo ich rotacji,
• szyfrowanie jest wymuszane, np. brakuje jakichkolwiek nagłówków HTTP (przeglądarki), dyrektyw bezpieczeństwa lub innych nagłówków,
• otrzymany certyfikat serwera i łańcuch zaufania nie są prawidłowo zweryfikowane,
• wektory inicjujące są ignorowane, ponownie używane lub generowane niewystarczająco bezpieczne dla kryptograficznego trybu działania, używany jest niepewny tryb działania, taki jak EBC, używane jest szyfrowanie zwykłe w miejscu, gdzie bardziej odpowiednie jest szyfrowanie uwierzytelnione,
• do celów kryptograficznych wykorzystywana jest losowość, która nie została zaprojektowana w celu spełnienia wymagań kryptograficznych,
• przy haszowaniu używane są przestarzałe funkcje skrótu, takie jak MD5 lub SHA1, albo używane są niekryptograficzne funkcje skrótu, w przypadku gdy potrzebne są kryptograficzne funkcje skrótu,
• używane są przestarzałe metody wypełniania kryptograficznego, np. takie jak PKCS numer 1 v1.5,
• komunikaty o błędach kryptograficznych lub informacje o kanale bocznym można wykorzystać, na przykład w formie ataków typu padding oracle.

W celu zobrazowania tej podatności, można posłużyć się kilkoma przykładami.

• Aplikacja szyfruje numery kart kredytowych w bazie danych przy użyciu automatycznego szyfrowania. Jednak te dane są automatycznie deszyfrowane po pobraniu, dzięki czemu wykorzystanie luki wstrzyknięcia SQL (atak typu SQL Injection) może doprowadzić do uzyskania numerów kart kredytowych w postaci zwykłego tekstu.
• Witryna nie używa ani nie wymusza protokołu TLS (Transport Layer Security) dla wszystkich stron lub obsługuje słabe szyfrowanie. W takim przypadku atakujący monitorując ruch sieciowy (np. w niezabezpieczonej sieci bezprzewodowej), obniża jakość połączeń z HTTPS na HTTP, przechwytuje żądania i kradnie plik cookie sesji użytkownika. Następnie odtwarza on przedmiotowy plik cookie i przechwytuje (uwierzytelnioną) sesję użytkownika, uzyskując dostęp lub modyfikując prywatne dane użytkownika, albo zmienia wszystkie przesyłane dane, np. odbiorcę przelewu.
• Baza danych, w której przechowywane są hasła, używa niesolonych lub prostych skrótów do przechowywania haseł wszystkich użytkowników. Błąd przesyłania pliku umożliwia atakującemu pozyskanie bazy danych z hasłami, ale w takim przypadku wszystkie niesolone hasze można wyeksponować za pomocą tabeli wstępnie obliczonych haszy. Warto zaznaczyć, że skróty generowane przez proste lub szybkie funkcje skrótu mogą zostać złamane przez procesory graficzne, nawet jeśli skróty te zostały posolone.

Injection – słabnące na popularności, ale wciąż istotne zagrożenie dla aplikacji webowych

Wstrzykiwanie kodu pomimo utraty pozycji lidera wciąż utrzymało się na podium. Jest to cały czas bardzo niebezpieczna i szeroko wykorzystywana przez hakerów kategoria podatności aplikacji webowych. Badane aplikacje w ramach tej kategorii okazały się podatne na zagrożenia CWE-79 (Cross-site Scripting), CWE-89 (SQL Injection) i CWE-73 (External Control of File Name or Path).

Aplikacje webowe są podatne na wstrzykiwanie kodu wówczas gdy:

• dane dostarczone przez użytkownika nie są sprawdzane, filtrowane ani oczyszczane przez aplikację,
• zapytania dynamiczne lub wywołania niesparametryzowane są używane bezpośrednio w interpreterze,
• złośliwe dane używane są w parametrach wyszukiwania mapowania obiektowo-relacyjnego (ORM) w celu wyodrębnienia dodatkowych, poufnych rekordów,
• złośliwe dane są bezpośrednio wykorzystywane lub łączone z innymi danymi.

Warto zaznaczyć, że niektóre z bardziej powszechnych wstrzyknięć to: wstrzykiwanie kodu SQL, NoSQL, poleceń systemu operacyjnego, mapowania relacyjnego obiektów (ORM), LDAP i języka wyrażeń (EL) lub biblioteki nawigacji obiektów grafów (OGNL).

Insecure design – nowa kategoria podatności z wciąż rosnącą popularnością

Insecure design to nowa kategoria zawarta w raporcie z 2021 r. skupiająca się na ryzyku związanym z błędami projektowymi i architektury aplikacji. Pojawienie się tego zagrożenia wymusza większe wykorzystanie modelowania zagrożeń, bezpiecznych wzorców projektowych i architektur referencyjnych. Badane aplikacje webowe w ramach tej kategorii okazały się podatne na zagrożenia CWE-209 (Generation of Error Message Containing Sensitive Information), CWE-256 (Unprotected Storage of Credentials), CWE-501 (Trust Boundary Violation) oraz CWE-522 (Insufficiently Protected Credentials).

Insecure design to szeroka kategoria reprezentująca różne podatności wyrażona jako „brakujący lub nieskuteczny projekt kontroli”. Podatność ta opiera się na wadach implementacji tworzących luki, które mogą być wykorzystane w niezaplanowany przez deweloperów sposób. Jednym z czynników, które przyczyniają się do powstania podatności Insecure design, jest brak profilowania ryzyka biznesowego nieodłącznie związanego z opracowywanym oprogramowaniem lub systemem, a tym samym brak określenia jaki poziom projektowania zabezpieczeń jest wymagany.

Aby zapobiec podatności Insecure design należy wdrożyć mechanizm „bezpiecznego projektowania” czyli kultury i metodologii stale oceniającej zagrożenia i zapewniającej, że kod jest solidnie zaprojektowany i przetestowany pod kątem zapobiegania znanym metodom ataków. W związku z tym modelowanie zagrożeń powinno być zintegrowane z sesjami dopracowującymi (lub podobnymi działaniami) oraz wyszukiwaniem zmian w przepływach danych i kontroli dostępu lub wykonywaniem innych kontroli bezpieczeństwa. Ponadto, w ramach „bezpiecznego projektowania” powinno się określić prawidłowy przepływ danych i stany błędów, jednocześnie upewniając się, że są one uzgodnione i dobrze zrozumiane. Dodatkowo, należy poddać analizie założenia i warunki dotyczące oczekiwanych i błędnych przepływów, aby upewnić się, że są one nadal prawidłowo określone.

W celu lepszego zobrazowania tej podatności, można posłużyć się kilkoma przykładami.

• Odzyskiwanie poświadczeń opiera się tylko na odpowiedziach na wybrane przez użytkownika pytania, co jest zabronione przez NIST 800-63b, OWASP ASVS i OWASP Top 10. Pytania i odpowiedzi nie mogą być traktowane jako dowód potwierdzenia tożsamości, ponieważ nie tylko jedna osoba może znać odpowiedzi, dlatego takie odzyskiwanie poświadczeń jest zabronione. Taki kod należy zastąpić bezpieczniejszym, umożliwiającym bezpieczne odzyskiwanie poświadczeń.
• Sieć kin oferuje zniżki na bilety grupowe dla maksymalnie piętnastu widzów. Bilety można zarezerwować przed dokonaniem zapłaty. Atakujący mają możliwość przetestowania, czy będą mogli zarezerwować sześćset miejsc we wszystkich kinach naraz za pomocą kilku rezerwacji, powodując ogromną utratę dochodów dla tej sieci kin.
• Witryna e-commerce sieci detalicznej nie ma ochrony przed botami zarządzanymi przez skalperów kupujących wysokiej klasy karty wideo w celu ich odsprzedaży na portalach aukcyjnych. Stwarza to antyreklamę producentom kart graficznych i właścicielom sieci handlowych (detalicznych) oraz psuje krew entuzjastom, którzy nie mogą zakupić kart poprzez witrynę. Staranne projektowanie antybotów i reguły logiki domeny, takie jak zakupy dokonywane w ciągu kilku sekund od dostępności, mogą identyfikować nieautentyczne zakupy i odrzucać tego typu transakcje.

Security Misconfiguration – niezwykle niebezpieczna i popularna kategoria podatności

Błędna konfiguracja zabezpieczeń została wykryta w aż 90% przetestowanych aplikacji webowych, co jest wynikiem zwiększającej się liczby zmian w wysoce konfigurowalnym oprogramowaniu. Badane aplikacje w ramach tej kategorii okazały się podatne na zagrożenia CWE-16 (Configuration) i CWE-611 (Improper Restriction of XML External Entity Reference).

Błędna konfiguracja zabezpieczeń może wystąpić wówczas, gdy aplikacja webowa:

• nie posiada odpowiedniego wzmocnienia zabezpieczeń w dowolnej części stosu lub zawiera nieprawidłowo skonfigurowane uprawnienia w usługach w chmurze,
• posiada włączone lub zainstalowane niepotrzebne funkcje, np. niepotrzebne porty, usługi, strony, konta lub uprawnienia,
• posiada włączone i niezmienione konta domyślne i ich hasła,
• w obsłudze błędów ujawnia użytkownikom ślady stosu lub inne zbyt szczegółowe komunikaty o błędach,
• w przypadku zaktualizowanych systemów posiada wyłączone najnowsze funkcje zabezpieczeń lub nie są one bezpiecznie skonfigurowane,
• nie ma ustawionych na bezpieczne zabezpieczeń chroniących serwery aplikacji, frameworki aplikacji (np. Struts, Spring, ASP.NET), biblioteki, bazy danych, itp.,
• jest zamieszczona na serwerze, który nie wysyła nagłówków ani dyrektyw bezpieczeństwa lub nie są one ustawione na bezpieczne wartości,
• posiada nieaktualne lub podatne na ataki oprogramowanie,
• nie posiada skoordynowanego, powtarzalnego procesu konfiguracji zabezpieczeń aplikacji, przez co systemy są bardziej zagrożone.

W celu lepszego zobrazowania tej podatności, można posłużyć się kilkoma przykładami.

• Serwer zawiera przykładowe aplikacje, które nie zostały usunięte z serwera produkcyjnego. Aplikacje te mają znane luki w zabezpieczeniach, których atakujący używają do złamania zabezpieczeń serwera. Załóżmy, że jedną z tych aplikacji jest konsola administracyjna, a domyślne konta nie zostały zmienione. W takim przypadku atakujący loguje się przy użyciu domyślnych haseł i przejmuje kontrolę jako administrator.
• Lista katalogów nie jest wyłączona na serwerze. Atakujący odkrywa, że ​​może po prostu wyświetlić listę katalogów, co też czyni znajdując i pobierając skompilowane klasy Java, które dekompiluje i odtwarza, aby wyświetlić ich kod, dzięki czemu znajduje poważną lukę w kontroli dostępu do aplikacji.
• Konfiguracja serwera aplikacji umożliwia zwracanie użytkownikom szczegółowych komunikatów o błędach, np. śladów stosu. Potencjalnie ujawnia to poufne informacje lub podstawowe wady, takie jak wersje składników, o których wiadomo, że są podatne na ataki.
• Dostawca usług w chmurze (CSP) ma domyślne uprawnienia udostępniania otwarte w Internecie przez innych użytkowników CSP. Umożliwia to dostęp do wrażliwych danych przechowywanych w chmurze.

Vulnerable and Outdated Components – ta podatność stwarza coraz większe zagrożenia

Podatne i nieaktualne komponenty to jedyna kategoria podatności, w której nie ma żadnych wspólnych luk w zabezpieczeniach i ekspozycji (CVE) zmapowanych do CWE. Jednakże badane aplikacje w ramach tej kategorii okazały się podatne na zagrożenia CWE-1104 (Use of Unmaintained Third-Party Components).

Aplikacje webowe narażone są na wystąpienie przedmiotowej podatności, poprzez:

• nieznajomość wersji wszystkich używanych składników (zarówno po stronie klienta, jak i po stronie serwera), co obejmuje zarówno komponenty, które są używane bezpośrednio, jak i zagnieżdżone zależności,
• zainstalowane oprogramowanie, które jest podatne na ataki, nieobsługiwane lub nieaktualne; obejmuje to system operacyjny, serwer WWW/aplikacji, system zarządzania bazami danych (DBMS), aplikacje, interfejsy API oraz wszystkie komponenty, środowiska wykonawcze i biblioteki,
• brak regularnego skanowania w poszukiwaniu luk bezpieczeństwa,
• zaniechanie napraw i aktualizacji podstawowej platformy, struktur i zależności we właściwym czasie; zdarza się to często w środowiskach, w których przeprowadzanie aktualizacji jest zadaniem comiesięcznym lub kwartalnym,
• zaniechanie przeprowadzenia testów zgodności zaktualizowanych lub poprawionych bibliotek przez twórców oprogramowania,
• brak zabezpieczenia konfiguracji komponentów.

W celu lepszego zobrazowania tej podatności, można posłużyć się poniższym przykładem:

Komponenty zazwyczaj działają z tymi samymi uprawnieniami, co sama aplikacja, więc wady w dowolnym komponencie mogą mieć poważne konsekwencje. Takie wady mogą być przypadkowe (np. błąd kodowania) lub celowe (np. backdoor w komponencie). Niektóre przykładowe wykryte luki w zabezpieczeniach komponentów, które można wykorzystać, to:

• CVE-2017-5638, czyli luka w zabezpieczeniach Struts 2 umożliwiająca zdalne wykonanie kodu na serwerze, co prowadzi do poważnego naruszenia bezpieczeństwa,
• luki w zabezpieczeniach Internetu rzeczy (IoT), które są często trudne lub niemożliwe do załatania, co jest szczególnie niebezpieczne w przypadku np. urządzeń biomedycznych.

Warto zaznaczyć, że istnieją zautomatyzowane narzędzia, które pomagają atakującym znaleźć niezałatane lub źle skonfigurowane systemy. Na przykład wyszukiwarka Shodan IoT może pomóc w znalezieniu urządzeń, które nadal cierpią na lukę Heartbleed załataną w kwietniu 2014 roku.

Identification and Authentication Failures – groźna podatność, która coraz rzadziej występuje

Błędy identyfikacji i uwierzytelniania pomimo znaczącego spadku w rankingu są nadal bardzo niebezpieczną i szeroko wykorzystywaną przez hakerów kategorią podatności aplikacji webowych. Badane aplikacje w ramach tej kategorii okazały się podatne na zagrożenia CWE-297 (Improper Validation of Certificate with Host Mismatch), CWE-287 (Improper Authentication) oraz CWE-384 (Session Fixation).

Potwierdzenie tożsamości użytkownika, uwierzytelnianie i zarządzanie sesjami mają kluczowe znaczenie dla ochrony przed atakami związanymi z uwierzytelnianiem. Podatność ta może wystąpić, jeśli aplikacja:

• umożliwia przeprowadzenie zautomatyzowanych ataków, takich jak uzupełnianie poświadczeń, w przypadku których atakujący ma listę prawidłowych nazw użytkowników i haseł,
• pozwala na atak typu „brute-force” lub inne zautomatyzowane ataki,
• zezwala na używanie domyślnych, słabych lub dobrze znanych haseł, takich jak „Hasło1” lub „admin/admin”,
• używa słabych lub nieefektywnych procesów odzyskiwania poświadczeń i zapomnianych haseł, takich jak „odpowiedzi oparte na wiedzy”, które nie są bezpieczne,
• wykorzystuje magazyny danych z hasłami w postaci zwykłego tekstu, niewłaściwie lub słabo zaszyfrowane,
• nie posiada lub posiada nieskuteczne uwierzytelnianie wieloskładnikowe,
• udostępnia identyfikator sesji w adresie URL,
• po pomyślnym zalogowaniu ponownie używa tego samego identyfikatora sesji,
• nieprawidłowo unieważnia identyfikatory sesji, tzn. jeśli sesje użytkownika lub tokeny uwierzytelniania (głównie tokeny logowania jednokrotnego (SSO)) nie są prawidłowo unieważniane podczas wylogowania lub po upływie wyznaczonego okresu braku aktywności.

W celu lepszego zobrazowania tej podatności, można posłużyć się kilkoma przykładami:

• Uzupełnianie poświadczeń czyli używanie list znanych haseł jest powszechnym atakiem. Załóżmy, że aplikacja nie implementuje zautomatyzowanej ochrony przed zagrożeniami lub uzupełnianiem poświadczeń. W takim przypadku aplikacja może służyć do ustalenia, czy poświadczenia są ważne.
• Większość ataków związanych z uwierzytelnianiem ma miejsce z powodu ciągłego używania haseł jako jedynego czynnika uwierzytelniającego. Wymagania dotyczące rotacji haseł i ich złożoności, które kiedyś zostały uznane za najlepsze praktyki, zachęcają użytkowników zarówno do używania, jak i ponownego używania słabych haseł. OWASP zaleca, aby organizacje zaprzestały stosowania przedmiotowych wymagań, zgodnie z NIST 800-63 i korzystały z uwierzytelniania wieloskładnikowego.
• Limity czasu sesji aplikacji nie są ustawione poprawnie. Użytkownik korzysta z publicznego komputera, aby uzyskać dostęp do aplikacji. Zamiast wybierać „wyloguj”, po prostu zamyka kartę przeglądarki i odchodzi. Atakujący używa tej samej przeglądarki godzinę później, a użytkownik nadal pozostaje uwierzytelniony.

Software and Data Integrity Failures – nowa i niebezpieczna kategoria podatności

Błędy oprogramowania i integralności danych to nowa kategoria zawarta w raporcie z 2021 roku skupiająca się na dokonywaniu założeń związanych z aktualizacjami oprogramowania, danymi krytycznymi i potokami CI/CD bez weryfikacji integralności. Badane aplikacje webowe w ramach tej kategorii okazały się podatne na zagrożenia CWE-829 (Inclusion of Functionality from Untrusted Control Sphere), CWE-494 (Download of Code Without Integrity Check) oraz CWE-502 (Deserialization of Untrusted Data).

Niniejsza kategoria podatności dotyczy kodu i infrastruktury, które nie chronią przed naruszeniami integralności. Przykładem tego jest sytuacja, w której aplikacja opiera się na wtyczkach, bibliotekach lub modułach z niezaufanych źródeł, repozytoriów i sieci dostarczania treści (CDN). Niezabezpieczony potok CI/CD może stwarzać możliwość nieautoryzowanego dostępu, wstrzyknięcia złośliwego kodu lub doprowadzić do naruszenia bezpieczeństwa systemu. Ponadto, wiele aplikacji zawiera funkcję automatycznej aktualizacji, dzięki której aktualizacje są pobierane bez wystarczającej weryfikacji integralności. W takim przypadku osoby atakujące mogą przesyłać własne aktualizacje, które będą rozpowszechniane i uruchamiane we wszystkich instalacjach. Innym przykładem jest sytuacja, w której obiekty lub dane są kodowane lub serializowane w strukturze, którą osoba atakująca może zobaczyć i zmodyfikować, wobec czego aplikacja jest podatna na niezabezpieczoną deserializację.

W celu lepszego zobrazowania tej podatności, można posłużyć się kilkoma dodatkowymi przykładami.

• Aktualizacja bez podpisywania: wiele routerów domowych, przystawek STB, oprogramowania układowego urządzeń i innych nie weryfikuje aktualizacji za pomocą podpisanego oprogramowania układowego. Niepodpisane oprogramowanie układowe jest coraz częstszym celem atakujących, a ilość takich ataków niebezpiecznie wzrasta. Stanowi to poważny problem, ponieważ często nie ma innego mechanizmu naprawczego niż naprawienie przyszłej wersji i oczekiwanie na łatki w kolejnych wersjach oprogramowania.
• Złośliwa aktualizacja SolarWinds: Wiadomo, że państwa atakują mechanizmy aktualizacji, a ostatnim godnym uwagi atakiem był atak SolarWinds Orion. Firma, która opracowuje oprogramowanie, miała bezpieczne procesy tworzenia i aktualizacji integralności. Mimo to udało się je przełamać i przez kilka miesięcy firma rozprowadzała wysoce ukierunkowaną szkodliwą aktualizację do ponad 18 000 organizacji, z których około 100 zostało zaatakowanych. To jeden z najdalej idących i najpoważniejszych ataków tego rodzaju w historii.
• Niebezpieczna deserializacja: aplikacja React wywołuje zestaw mikrousług Spring Boot. Deweloperzy odpowiadający za tą aplikację, będąc programistami funkcjonalnymi, starali się zapewnić niezmienność kodu. Rozwiązanie, które wymyślili, polega na serializacji stanu użytkownika i przekazywaniu tego stanu tam i z powrotem przy każdym żądaniu. W tym przypadku atakujący może zauważyć sygnaturę obiektu Java „rO0” (w base64) i użyć narzędzia Java Serial Killer, aby uzyskać zdalne wykonanie kodu na serwerze aplikacji.

Security Logging and Monitoring Failures – podatność, która stopniowo zyskuje popularność

Błędy rejestrowania i monitorowania zabezpieczeń mają duży wpływ na odpowiedzialność, widoczność oraz ostrzeganie o incydentach i kryminalistykę. Badane aplikacje webowe w ramach tej kategorii okazały się podatne na zagrożenia CWE-117 (Improper Output Neutralization for Logs), CWE-223 (Omission of Security-relevant Information) oraz CWE-532 (Insertion of Sensitive Information into Log File).

Podatność ta opierająca się na niewystarczającym rejestrowaniu, wykrywaniu, monitorowaniu i aktywnej reakcji, może wystąpić w dowolnym momencie. Aplikacja webowa jest podatna na występowanie błędów rejestrowania i monitorowania zabezpieczeń, wówczas, gdy:

• zdarzenia podlegające kontroli, takie jak logowania, nieudane logowania i transakcje o wysokiej wartości, nie są rejestrowane,
• ostrzeżenia i błędy generują nieodpowiednie lub niejasne komunikaty w dzienniku lub nie generują ich wcale.
• dzienniki aplikacji i interfejsów API nie są monitorowane pod kątem podejrzanej aktywności,
• dzienniki aplikacji są przechowywane tylko lokalnie,
• odpowiednie progi alarmowe i procesy eskalacji odpowiedzi nie zostały wprowadzone lub nie są skuteczne,
• testy penetracyjne i skany za pomocą narzędzi do dynamicznego testowania bezpieczeństwa aplikacji (DAST), np. OWASP ZAP, nie wywołują alertów,
• aplikacja nie może wykrywać, eskalować ani ostrzegać o aktywnych atakach w czasie rzeczywistym lub w czasie zbliżonym do rzeczywistego,
• ujawnianie zdarzeń rejestrowania i alarmowania dla użytkownika lub atakującego jest podatne na wyciek informacji.

Warto zaznaczyć, że istnieją komercyjne i otwarte struktury ochrony aplikacji, takie jak OWASP ModSecurity Core Rule Set i oprogramowanie do korelacji dzienników typu open source, takie jak Elasticsearch, Logstash, Kibana (ELK), które zawierają niestandardowe pulpity nawigacyjne i alerty, dzięki czemu znacząco ułatwione jest zapobieganie wystąpieniu tej kategorii podatności.

W celu lepszego zobrazowania tej podatności, można posłużyć się kilkoma przykładami:

• Operator witryny internetowej dostawcy planu opieki zdrowotnej dla dzieci nie mógł wykryć naruszenia z powodu braku monitorowania i rejestrowania. Podmiot zewnętrzny poinformował dostawcę planu zdrowotnego, że osoba atakująca uzyskała dostęp i zmodyfikowała tysiące poufnych danych dotyczących zdrowia ponad 3,5 miliona dzieci. Przegląd po incydencie wykazał, że twórcy stron internetowych nie usunęli znaczących luk w zabezpieczeniach. Ponieważ nie było logowania ani monitorowania systemu, naruszenie danych wykryte w roku 2020 mogło trwać od 2013 roku czyli od siedmiu lat.
• W dużej indyjskiej linii lotniczej doszło do naruszenia danych dotyczących zbieranych od ponad dziesięciu lat danych osobowych milionów pasażerów, w tym danych dotyczących paszportów i kart kredytowych. Do przedmiotowego naruszenia doszło u zewnętrznego dostawcy hostingu w chmurze, który po pewnym czasie powiadomił linię lotniczą o naruszeniu.
• Duża europejska linia lotnicza doznała istotnego naruszenia przepisów RODO, które należało zgłosić. Naruszenie to było podobno spowodowane lukami w zabezpieczeniach aplikacji płatniczych, które zostały wykorzystane przez atakujących, dzięki czemu przechwycili ponad 400 000 rekordów płatności klientów. W rezultacie organ regulujący ochronę prywatności ukarał linię lotniczą grzywną w wysokości 20 milionów funtów.

Server-Side Request Forgery – nowa i niebezpieczna podatność

Fałszerstwo żądania po stronie serwera to nowa kategoria podatności zawarta w raporcie z 2021 roku.

Błędy SSRF występują, gdy aplikacja internetowa pobiera zdalny zasób bez sprawdzania poprawności adresu URL podanego przez użytkownika, przez co umożliwia atakującemu zmuszenie aplikacji do wysłania spreparowanego żądania do nieoczekiwanego miejsca docelowego, nawet jeśli aplikacja jest chroniona przez zaporę sieciową, VPN lub inny rodzaj listy kontroli dostępu do sieci (ACL).

Ponieważ nowoczesne aplikacje internetowe zapewniają użytkownikom końcowym wygodne funkcje, pobieranie adresu URL staje się powszechnym scenariuszem. W rezultacie częstość występowania ataków SSRF wzrasta. Ponadto waga tych ataków staje się coraz większa ze względu na rozwój usług chmurowych i złożoność architektur.

Atakujący mogą używać SSRF do atakowania systemów chronionych za WAF (Web Application Firewall), zaporami sieciowymi lub listami ACL sieci, co można zaprezentować na poniższych przykładach.

• Wewnętrzne serwery skanowania portów — jeśli architektura sieci nie jest podzielona na segmenty, osoby atakujące mogą mapować sieci wewnętrzne i na podstawie wyników połączenia lub czasu jaki upłynął do nawiązania połączenia lub odrzucenia połączeń ładunku SSRF określić, czy porty na serwerach wewnętrznych są otwarte czy zamknięte.
• Narażenie poufnych danych — atakujący mogą uzyskać dostęp do lokalnych plików lub usług wewnętrznych, aby uzyskać poufne informacje, takie jak file:///etc/passwd</span> i http://localhost:28017/.
• Dostęp do magazynu metadanych usług w chmurze — większość dostawców usług w chmurze ma magazyn metadanych, taki jak http://169.254.169.254/. Atakujący może odczytać metadane, aby uzyskać poufne informacje.
• Naruszanie usług wewnętrznych — osoba atakująca może nadużywać usług wewnętrznych w celu przeprowadzenia dalszych ataków, takich jak zdalne wykonanie kodu (RCE) lub odmowa usługi (DoS).

Podsumowując raport OWASP Top 10 zawiera 10 najbardziej groźnych i niebezpiecznych podatności aplikacji webowych, które mogą zostać wykorzystane przez hakerów do włamania się do systemu, przejęcia konta użytkownika lub konta administratora, wykradzenia danych, zablokowania serwera, dyskredytacji danej aplikacji webowej, czy przejęcia kontroli nad aplikacją lub serwerem. Dzięki zawartym opisom zagrożeń oraz wykazaniem możliwych zabezpieczeń przed wystąpieniem opisanych podatności, staje się on poradnikiem i zbiorem dobrych praktyk z dziedziny cyberbezpieczeństwa.

Autor: Michał Mamica