ARK. 1Słownik pojęćPodatności i klasy błędów
skoordynowane ujawnianie podatności
Praktyka, w której badacz najpierw zgłasza podatność producentowi (lub zespołowi CERT jako stronie zaufanej), a szczegóły publikuje dopiero po wydaniu poprawki lub po upływie ustalonego terminu — CERT Polska publikuje wpisy CVE po 90 dniach od przekazania szczegółów producentowi.
TAB. 1Nazwaobie formy
| Po angielsku | coordinated vulnerability disclosure (CVD) |
|---|---|
| Po polsku | skoordynowane ujawnianie podatności |
| Którą formą pisać | obie formy Obie formy są w obiegu. Przy pierwszym wystąpieniu pisz „polski termin (english term)”, dalej sam polski. |
| Inne formy | koordynowane ujawnianie podatności · zgłaszanie i obsługa podatności · CVD |
| Odmiana | to skoordynowane ujawnianie podatności, tego skoordynowanego ujawniania podatności; skrót CVD nieodmienny („program CVD”, „w ramach CVD”) |
TAB. 2Jak to nazywająprasa vs urząd
| Prasa branżowa | angielskie „responsible disclosure”, zwykle z sygnałem „tzw.” (niebezpiecznik) |
|---|---|
| Urząd i ustawa | trzy różne etykiety w jednej instytucji: „Skoordynowane Ujawnianie Podatności” (tytuł strony wiedza.cert.pl), „proces koordynowanego ujawniania podatności (CVD, ang. Coordinated Vulnerability Disclosure)” (treść tamże) oraz „Zgłaszanie i obsługa podatności (CVD)” (tytuł cert.pl/cvd) |
TAB. 3Źródła5
| Forma | Cytat | Skąd |
|---|---|---|
| PL (EN) | „Proces koordynowanego ujawniania podatności (CVD, ang. Coordinated Vulnerability Disclosure) został wprowadzony do europejskiego porządku prawnego poprzez zapisy dyrektywy NIS 2.” | wiedza.cert.pl |
| PL | „Skoordynowane Ujawnianie Podatności” | wiedza.cert.pl |
| PL (EN) | „Zgłaszanie i obsługa podatności (CVD)” | cert.pl |
| PL | „Prosimy o niepublikowanie informacji o podatności przed zakończeniem procesu jej obsługi.” | cert.pl |
| EN | „…i dopiero wtedy publikować o tym informację (tzw. responsible disclosure)” | niebezpiecznik.pl |
TAB. 4Obok w tej dziedzinie6
| security through obscurity | security through obscurity | Opieranie ochrony na tym, że napastnik nie zna szczegółów systemu (ukryty adres logowania, zmieniony prefiks tabel, ukryta wersja WordPressa). Jako jedyna warstwa jest zawodne; jako dodatek do aktualizacji i silnego uwierzytelniania odsiewa część automatycznych ataków. |
| security.txt | security.txt | Plik tekstowy /.well-known/security.txt (standard RFC 9116) z danymi kontaktowymi do zgłaszania podatności: adres e-mail lub formularz, klucz PGP, polityka ujawniania i data ważności (pole Expires). Na WordPressie można go dodać ręcznie w katalogu strony albo wtyczką. |
| session fixation | session fixation | Atak, w którym napastnik narzuca ofierze znany sobie identyfikator sesji (np. w linku), a gdy ofiara się zaloguje, przejmuje jej uwierzytelnioną sesję. Ochroną jest wydawanie nowego identyfikatora po zalogowaniu (w PHP session_regenerate_id(true)); rdzeń WordPressa nie opiera logowania na sesji PHP, więc ryzyko dotyczy głównie wtyczek, które same używają $_SESSION. |
| SQL injection | SQL injection | Podatność pozwalająca wpleść własne polecenia w zapytanie do bazy danych i odczytać, zmienić lub usunąć dane, do których atakujący nie ma prawa. |
| SSRF (Server-Side Request Forgery) | server-side request forgery (SSRF) | Podatność, w której atakujący zmusza serwer aplikacji do wysłania żądania pod wskazany przez siebie adres, sięgając do zasobów wewnętrznych niedostępnych z internetu. |
| SSTI | server-side template injection (SSTI) | Podatność, w której dane od użytkownika trafiają do szablonu renderowanego po stronie serwera (Twig, Jinja2, Smarty) jako kod szablonu, a nie jako tekst — zwykle kończy się wykonaniem kodu na serwerze (RCE). W WordPressie przykładem jest WPML (CVE-2024-6386): shortcode renderowany przez Twig pozwalał autorowi z rolą Contributor wykonać kod na serwerze. |