OWASP Top: 10 2021-2025

Co się zmieniło w OWASP Top 10

W edycji 2021 pojawiły się trzy zupełnie nowe kategorie, cztery zmieniły nazwę lub zakres, a niektóre wcześniejsze połączono. Nazwy aktualizowano tam, gdzie trzeba było podkreślić przyczynę źródłową — zamiast jedynie objawu.

1. A01:2021 – Uszkodzona kontrola dostępu
   Awans z pozycji 5. na 1. miejsce jako najpoważniejsze ryzyko dla aplikacji webowych. Średnio 3,81 % testowanych aplikacji miało co najmniej jeden CWE z tej grupy, a 34 powiązane CWE odnotowano ponad 318 000 razy.
2. A02:2021 – Błędy kryptograficzne
   Wzrost o jedną pozycję (poprzednio A3:2017 – Ujawnienie wrażliwych danych). Skupiono się na samych błędach w kryptografii, które często prowadzą do wycieku danych lub kompromitacji systemu.
3. A03:2021 – Wstrzykiwanie
   Spadek na 3. miejsce. 94 % aplikacji testowano pod kątem różnych form injection; maksymalna wykrywalność sięgnęła 19 %, średnia 3,37 %. Do tej kategorii włączono teraz Cross-Site Scripting.
4. A04:2021 – Niebezpieczny projekt
   Całkowicie nowa kategoria koncentrująca się na błę­dach koncepcyjnych. Nawet perfekcyjna implementacja nie zrekompensuje braku odpowiednich zabezpieczeń zaplanowanych już na etapie projektowania.
5. A05:2021 – Błędy konfiguracji bezpieczeństwa
   Awans z 6. miejsca. 90 % aplikacji zawierało co najmniej jedną formę błędnej konfiguracji; odnotowano ponad 208 000 wystąpień CWE. Dawna kategoria XXE (A4:2017) została tu wchłonięta.
6. A06:2021 – Podatne i nieaktualne komponenty
   (Wcześniej „Using Components with Known Vulnerabilities”) – skok z 9. na 6. miejsce. Jedyna kategoria bez mapy CVE, dlatego w ocenach przyjęto domyślne wagi exploita i wpływu = 5,0.
7. A07:2021 – Błędy identyfikacji i uwierzytelniania
   Poprzednio „Broken Authentication” (pozycja 2.). Zawiera teraz CWE związane również z identyfikacją. Popularność frameworków uwierzytelniania zmniejszyła częstość tych błędów.
8. A08:2021 – Błędy integralności oprogramowania i danych
   Nowa kategoria skupiona na braku weryfikacji integralności aktualizacji, artefaktów CI/CD i danych krytycznych. Dawna „Insecure Deserialization” (A8:2017) stała się jej podzbiorem.
9. A09:2021 – Błędy rejestrowania i monitorowania bezpieczeństwa
   (Poprzednio A10:2017 – Insufficient Logging & Monitoring). Rozszerzono zakres o inne typy awarii, które ograniczają widoczność zdarzeń, alertowanie i analizę incydentów.
10. A10:2021 – Fałszerstwo żądań po stronie serwera (SSRF)
    Nowość wskazana przez społeczność (#1 w ankiecie). Mimo relatywnie rzadkiego występowania, wysoka podatność na exploit i poważne skutki uzasadniają uwzględnienie w Top 10.

Metodologia

Ta edycja OWASP Top 10 opiera się na danych bardziej niż kiedykolwiek wcześniej, ale nie przyjmuje ich bezkrytycznie. Spośród dziesięciu kategorii osiem wybraliśmy na podstawie przekazanych zbiorów danych, a dwie na podstawie ankiety społeczności Top 10. Robimy to z prostego powodu: analiza danych zawsze patrzy w przeszłość. Badaczom bezpieczeństwa aplikacji potrzeba czasu, aby wykryć nowe podatności i opracować metody ich testowania; kolejne miesiące (a nawet lata) zajmuje wdrożenie tych testów do narzędzi i procesów. Zanim więc daną słabość da się wiarygodnie sprawdzać na dużą skalę, mijają lata. Aby zrównoważyć to podejście, prosimy w ankiecie ekspertów AppSec i programistów z pierwszej linii, jakie słabości uważają za kluczowe, nawet jeśli jeszcze nie są widoczne w danych.

W tej edycji przyjęliśmy również kilka istotnych zmian, które pomagają dalszemu rozwojowi listy Top 10.

Jak zbudowane są kategorie

Kilka kategorii uległo zmianom w porównaniu z poprzednią edycją OWASP Top Ten. Poniżej znajduje się podsumowanie tych zmian na wysokim poziomie.

Poprzednie zbiory danych skupiały się na określonej liście około 30 CWE, z dodatkowym polem na inne znaleziska. Okazało się, że organizacje koncentrowały się głównie na tych 30 CWE i rzadko dodawały nowe. W tej edycji poprosiliśmy po prostu o dane, bez żadnych ograniczeń co do CWE. Prosiliśmy o liczbę aplikacji przebadanych w danym roku (począwszy od 2017) oraz liczbę aplikacji, w których znaleziono co najmniej jedno wystąpienie CWE.

Taki format pozwala śledzić, jak powszechne jest każde CWE w populacji aplikacji. Częstotliwość (ile razy dane CWE występuje w jednej aplikacji) pomijamy; choć bywa istotna w innych analizach, tu zaciemniłaby obraz. Nieważne, czy w aplikacji występują cztery instancje CWE czy cztery tysiące – dla Top 10 liczy się fakt, że CWE w ogóle występuje. Liczba analizowanych słabości wzrosła więc z ~30 do prawie 400; planujemy jeszcze dodatkowe analizy. Tak duży przyrost wymusił zmianę struktury kategorii.

Przez kilka miesięcy grupowaliśmy i kategoryzowaliśmy CWE – i moglibyśmy robić to dalej, ale w pewnym momencie trzeba było zakończyć. CWE opisują albo przyczynę źródłową (np. „Cryptographic Failure”, „Misconfiguration”), albo objaw (np. „Sensitive Data Exposure”, „Denial of Service”). Gdzie tylko to możliwe, skupiamy się na przyczynie, bo daje to lepsze wskazówki naprawcze. Nie jest to nowość – wcześniejsze edycje Top 10 także mieszały objawy i przyczyny – lecz teraz robimy to bardziej świadomie. Średnio na kategorię przypada 19,6 CWE, od jednego (A10:2021 – SSRF) do czterdziestu (A04:2021 – Insecure Design). Taka struktura pomaga w szkoleniach: zespoły mogą skupić się na CWE pasujących do konkretnego języka czy frameworka.

Jak dane są wykorzystywane przy wyborze kategorii

W 2017 roku kategorie wybierano głównie według wskaźnika występowania (incidence rate), który określał prawdopodobieństwo, a następnie układano ich kolejność podczas dyskusji zespołu, uwzględniając dziesięciolecia doświadczeń w trzech wymiarach: Exploitability (łatwość wykorzystania), Detectability (również element prawdopodobieństwa) oraz Technical Impact (skutki techniczne).

W 2021 roku postanowiliśmy – tam, gdzie to tylko możliwe – oprzeć się na twardych danych również dla Exploitability i Technical Impact.

Zbieranie metryk CVSS

• Pobranie danych
  Z użyciem narzędzia OWASP Dependency Check wyekstrahowaliśmy z bazy CVE wartości Exploit Score i Impact Score (CVSS) dla każdego CWE.

• CVSSv2 vs CVSSv3

  • Wszystkie wpisy CVE mają oceny CVSSv2, które jednak mają znane wady.
  • Od pewnego momentu każdemu CVE przypisywana jest także ocena CVSSv3.
  • Skale i wzory obliczeń zmieniono między wersjami:
    • W CVSSv2 teoretyczne maksimum wynosiło 10,0, lecz końcowa formuła sprowadzała Exploit do 60 % tej wartości, a Impact do 40 %.
    • W CVSSv3 maksima ograniczono odpowiednio do 6,0 (Exploit) i 4,0 (Impact).
    • W praktyce średni Impact w CVSSv3 wzrósł o ok. 1,5 pkt, a Exploitability spadło przeciętnie o 0,5 pkt względem v2.
• Zakres danych
  • Zależność CVE → CWE występuje w ok. 125 000 rekordów NVD, obejmujących 241 unikalnych CWE.
  • Około 62 000 tych mapowań ma ocenę CVSSv3 – to mniej więcej połowa całej próbki.

Obliczanie średnich punktacji

Dla Top 10 2021 obliczyliśmy średnie Exploit Score i Impact Score następująco:

1. Grupowaliśmy wszystkie CVE z ocenami CVSS wg CWE.
2. Każdy z dwóch komponentów (Exploit i Impact) ważono udziałem rekordów z CVSSv3 oraz pozostałych z CVSSv2, by uzyskać uśrednioną wartość.
3. Te średnie przypisano do odpowiednich CWE w głównym zbiorze danych i wykorzystano jako składowe ryzyka po stronie Exploitability i Technical Impact.

Dlaczego nie tylko czyste dane statystyczne?

Rezultaty widoczne w przekazanych zbiorach danych pokazują głównie to, co da się zautomatyzować. Zapytaj doświadczonego specjalistę bezpieczeństwa aplikacji, a usłyszysz o podatnościach i trendach, których narzędzia jeszcze nie wychwytują. Przyczyny:

1. Czas – opracowanie metody testowania nowej słabości i dopracowanie jej wymaga miesięcy, czasem lat.
2. Automatyzacja – zanim test trafi do komercyjnych lub open-source’owych narzędzi, mija kolejny okres.
3. Widoczność – w czasie zbierania danych sektor mógł już wykryć nowy problem, lecz nie zdążył wdrożyć masowych testów.

Dlatego wybieramy tylko osiem kategorii czysto „z danych”, a kolejne dwie pochodzą z ankiety społeczności. W ten sposób praktycy z pierwszej linii mogą wskazać ryzyka, które ich zdaniem są najważniejsze, choć w statystykach (jeszcze) ledwie się zaznaczają.

Dlaczego wskaźnik występowania zamiast częstotliwości?

Mamy trzy główne rodzaje źródeł danych:

1. Tooling – pełna automatyzacja.
2. Human-assisted Tooling (HaT) – narzędzia kierowane przez człowieka.
3. Tool-assisted Human (TaH) – audyt manualny wspomagany narzędziami.

Tooling i HaT generują bardzo wysoką liczbę znalezisk dla podatności, które łatwo wykryć automatem. Klasyczny przykład: XSS. Kiedy błąd jest systemowy, liczba wykryć może pójść w tysiące dla jednej aplikacji i całkowicie „zagłuszyć” pozostałe wyniki.

Natomiast TaH wykrywa szersze spektrum słabości, lecz przy dużo mniejszej liczbie zgłoszeń (brakuje czasu na ręczne „kopiowanie-wklejanie” setek identycznych błędów).

Gdybyśmy zsumowali oba zbiory po liczbie wykryć, zalew automatycznych raportów XSS zdominowałby ranking. Dlatego w 2017 r. wprowadziliśmy wskaźnik występowania: jaki procent aplikacji miał co najmniej jedno CWE z danej kategorii. Nie obchodzi nas, czy było to jedno czy tysiąc wystąpień – liczy się fakt, że aplikacja jest podatna.

Proces zbierania i analizy danych

Sformalizowaliśmy proces zbierania danych do OWASP Top 10 podczas Open Security Summit w 2017 r. Liderzy projektu oraz społeczność spędzili dwa dni na stworzeniu przejrzystej, udokumentowanej procedury. Wydanie 2021 to drugi raz, gdy korzystamy z tej metody.

1. Ogłoszenie zbiórki danych
   Wysyłamy „call for data” przez wszystkie dostępne kanały społecznościowe – zarówno projektowe, jak i ogólno-OWASP-owe.

   • Na stronie projektu publikujemy listę wymaganych pól danych i opisaną strukturę ich dostarczania.
   • W repozytorium GitHub umieszczamy przykładowe pliki-szablony.
   • W razie potrzeby pomagamy organizacjom zmapować dane na odpowiednie CWE.

2. Źródła

   • Firmy zajmujące się testami bezpieczeństwa (komercyjni dostawcy usług).
   • Platformy bug-bounty.
   • Organizacje udostępniające własne (wewnętrzne) wyniki testów.

3. Scalenie i normalizacja
   Po zebraniu wszystkiego ładujemy dane do jednego zbioru i przypisujemy poszczególne CWE do kategorii ryzyka.

   • Niektóre CWE nakładają się na siebie, inne są bardzo blisko spokrewnione (np. różne błędy kryptograficzne).
   • Wszelkie decyzje normalizacyjne dokumentujemy i publikujemy, aby proces był w pełni transparentny.

4. Selekcja kategorii

   • Wybieramy osiem kategorii o najwyższym wskaźniku występowania do Top 10.
   • Sprawdzamy wyniki ankiety społecznościowej: dwie kategorie z największą liczbą głosów, które nie występują jeszcze w danych, dopełniają listę.
   • Gdy mamy komplet dziesięciu pozycji, przykładamy uogólnione wagi exploitability oraz impact, aby nadać finalną – opartą na ryzyku – kolejność.

Czynniki danych