MITRE publikuje listę „CWE Top 25 (2025)” – najgroźniejsze słabości systemu i co z nimi zrobić

securitybeztabu.pl 4 godzin temu

Wprowadzenie do problemu / definicja luki

MITRE opublikowało listę 2025 CWE Top 25 Most Dangerous Software Weaknesses – zestawienie klas błędów, które najczęściej i najdotkliwiej prowadzą do podatności w realnych produktach. Ranking powstaje na podstawie publicznych rekordów CVE i łączy częstość mapowań na daną CWE z średnią surowością (CVSS v3), aby wyliczyć „Danger Score” i ułożyć kolejność słabości. W 2025 r. na szczycie ponownie znalazł się CWE-79 (XSS), dalej CWE-89 (SQL Injection) i CWE-352 (CSRF).

W skrócie

  • XSS #1, SQLi #2, CSRF #3; mocne przesunięcia pozycji zaliczyły m.in. Missing Authorization (CWE-862), NULL Pointer Dereference (CWE-476) oraz Missing Authentication (CWE-306).
  • Nowe wejścia do Top 25: trzy klasyczne przepełnienia bufora (CWE-120/121/122), Improper Access Control (CWE-284), Authorization Bypass via User-Controlled Key (CWE-639) i Allocation of Resources Without Limits (CWE-770).
  • Próbka danych 2025: 39 080 rekordów CVE (okres 1 VI 2024 – 1 VI 2025), z dwoma odświeżeniami zbioru (23 VII i 17 XI 2025). Po raz pierwszy ranking wykorzystał nienormalizowane mapowania CWE oraz wspierał się LLM do sugestii mapowań dla CNAs.
  • Artykuł BleepingComputer: podsumowuje listę i rekomendacje CISA/MITRE dla zespołów dev/sec.

Kontekst / historia / powiązania

Edycja 2025 różni się metodologicznie od lat ubiegłych: zrezygnowano z „zwijania” mapowań do uproszczonego View-1003 (NVD), co pozwoliło na pojawienie się bardziej precyzyjnych, niższych poziomów CWE w rankingu (np. konkretne typy overflow). Ponadto 67% CVE w tegorocznej próbce miało mapowanie dostarczone już przez publikującego CNA (wzrost o 14 p.p. r/r), a zespół Top 25 przeanalizował i korygował mapowania we współpracy z 170 CNA.

Analiza techniczna / szczegóły luki

Top 10 (2025):

  1. CWE-79 XSS – injekcja skryptów w kontekście przeglądarki; często wynik słabego filtrowania/escapingu danych i braku CSP.
  2. CWE-89 SQL Injection – manipulacja zapytaniami do DB przy braku parametrów/bindowania.
  3. CWE-352 CSRF – nieautoryzowane akcje wykonywane w kontekście zalogowanego użytkownika; brak tokenów anty-CSRF, niepoprawne SameSite.
  4. CWE-862 Missing Authorization – brak sprawdzenia uprawnień do zasobu/operacji (również w ścieżkach „bocznych” i API).
  5. CWE-787 Out-of-Bounds Write – korupcja pamięci; typowo prowadzi do RCE/DoS.
  6. CWE-22 Path Traversal, 7) CWE-416 Use-After-Free, 8) CWE-125 OOB Read, 9) CWE-78 OS Command Injection, 10) CWE-94 Code Injection. (Pełna tabela na stronie MITRE).

Nowe i istotne akcenty 2025:

  • Powrót klasyków pamięciCWE-120/121/122 (różne formy przepełnień bufora) wskazują, iż wciąż istnieje duży zbiór kodu w C/C++ bez wystarczających mechanizmów bezpieczeństwa pamięci.
  • Autoryzacja i kontrola dostępu – wzrost pozycji CWE-862/863 oraz pojawienie się CWE-284 pokazują, iż błędy uprawnień w mikroserwisach i API są dziś tak samo krytyczne jak klasyczne injekcje.

Praktyczne konsekwencje / ryzyko

  • Pełne przejęcie systemu / RCE – w wyniku OOB Write/Use-After-Free/Command Injection.
  • Masowe wycieki danych – przez błędy kontroli dostępu (CWE-284, CWE-862/863) i ekspozycję informacji (CWE-200).
  • Ataki na łańcuchy dostaw – z wykorzystaniem uploadu niebezpiecznych plików (CWE-434) i deserializacji (CWE-502).
  • Ataki na interfejsy webowe i mobilne – XSS/CSRF przez cały czas realnie monetyzowane w phishingu przeglądarkowym i oszustwach transakcyjnych. (Zob. opis ryzyk i listę w źródłach).

Rekomendacje operacyjne / co zrobić teraz

Dla zespołów deweloperskich:

  • Eliminacja injekcji: wszędzie używaj zapytania parametryzowane, ORM, walidację białych list, escaping kontekstowy; zabroń konkatenacji inputu w SQL/OS/LDAP.
  • Ochrona front-endu: CSP, HttpOnly/SameSite/secure dla ciasteczek; tokeny synchronizowane lub Double Submit Cookie dla CSRF; sanitizacja i escaping dla XSS.
  • Bezpieczeństwo pamięci: preferuj języki memory-safe (Rust/Go/Java) dla nowych komponentów; dla C/C++ włącz ASLR/DEP/CFI, hardening kompilatora (Fortify, UBSan, ASan) i fuzzing.
  • Autoryzacja i dostęp: model ABAC/RBAC z weryfikacją uprawnień na każdym endpointcie (również „read-only”/list); testuj scenariusze IDOR (CWE-639).
  • Upload plików: whitelist MIME/rozszerzeń, zapis poza webroot, skan AV/sandbox, transkodowanie treści (np. obrazów/PDF).
  • SDLC: SAST + DAST + IAST + fuzzing, skany SCA (licencje/CVE), testy IaC (misconfig), Code Review z checklistą CWE, threat modeling.

Dla zespołów security / platform / AppSec:

  • Mapuj wyniki na CWE i priorytetyzuj według listy Top 25 + wpływu biznesowego.
  • Bloki pre-commit/CI: brak merge, jeżeli testy bezpieczeństwa nieprzechodzą (policy-as-code).
  • Telemetria: WAF/RASP z regułami na XSS/SQLi/OS cmd, monitorowanie anomalii uprawnień, limity i throttling (rate-limit – CWE-770).
  • Program bounty i red teaming ukierunkowane na Top 25.
  • Uzgodnij definicję „done”: ticket niezamykany bez remediacji/kompensacji.
  • Komunikacja z vendorami: w zgłoszeniach proś o dokładne mapowanie CVE→CWE, co ułatwia priorytetyzację i trendowanie, zgodnie z praktykami MITRE.

Różnice / porównania z innymi przypadkami (jeśli dotyczy)

  • Zmiana metodologii 2025 (rezygnacja z normalizacji do View-1003) spowodowała spadek pozycji abstrakcyjnych CWE i wzrost szczegółowych klas (np. konkretne overflow), co lepiej oddaje rzeczywiste przyczyny podatności w kodzie.
  • Zestawienie potwierdza utrzymującą się dominację błędów wejścia/wyjścia (XSS/SQLi/CSRF) – mimo lat edukacji i frameworków. To argument za wymuszaniem ochron w linterach, generatorach kodu i warstwach platformowych, a nie tylko w recenzjach.

Podsumowanie / najważniejsze wnioski

  • Top 25 (2025) to praktyczna mapa na najczęstsze i najgroźniejsze klasy błędów w produkcyjnym kodzie.
  • Pamięć wraca na świecznik (CWE-120/121/122), a kontrola autoryzacji staje się krytyczna w architekturach API/mikroserwisów.
  • Wdrożenie zabezpieczeń jako domyślnych (parametryzacja, CSP, limity zasobów, kontrola uprawnień) + automatyzacja testów powinny stać się normą, nie „best effort”.

Źródła / bibliografia

  • MITRE: 2025 CWE Top 25 – tabela i ranking. (CWE)
  • MITRE: 2025 Methodology (zakres danych, daty, re-mapowanie, LLM, scoring). (CWE)
  • MITRE: 2025 Key Insights (nowości, największe wzrosty/spadki, wnioski dot. mapowań). (CWE)
  • BleepingComputer: MITRE shares 2025’s Top 25 (przegląd i rekomendacje dla zespołów). (BleepingComputer)
Idź do oryginalnego materiału