Słownik
IDOR
IDOR (Insecure Direct Object Reference) - co to jest, jak wygląda na przykładzie żądania HTTP, jak go testować i naprawić oraz czym różni się od BOLA w API.
Słownik
CVSS (Common Vulnerability Scoring System) to otwarty standard oceny powagi podatności w skali 0-10, od braku do krytycznej. Ocena wynika m.in. ze sposobu ataku, wymaganych uprawnień i skutków dla poufności, integralności i dostępności, a w raportach z pentestów stosuje się wersję 3.1 albo 4.0.
CVSS to wspólny język do opisu powagi podatności. Zamiast słów „poważna” czy „drobna”, które każdy rozumie inaczej, standard każe opisać podatność kilkoma metrykami - jak można ją wykorzystać i co się stanie, gdy ktoś to zrobi - i wylicza z nich wynik od 0.0 do 10.0. Standard rozwija organizacja FIRST; w użyciu są dziś wersje 3.1 i 4.0.
Wynik CVSS znajdziesz w raportach z pentestów, komunikatach producentów i bazach podatności przy identyfikatorach CVE. Liczbie powinien zawsze towarzyszyć wektor, czyli zapis wartości wszystkich metryk - z niego widać, skąd wziął się wynik.
Wynik liczbowy przekłada się na pięć poziomów powagi. Ta sama skala obowiązuje w wersjach 3.1 i 4.0:
| Wynik | Poziom | Znaczenie |
|---|---|---|
| 0.0 | None | brak |
| 0.1-3.9 | Low | niski |
| 4.0-6.9 | Medium | średni |
| 7.0-8.9 | High | wysoki |
| 9.0-10.0 | Critical | krytyczny |
Podstawą są metryki bazowe (Base), które opisują samą podatność:
Wynik bazowy można uzupełnić o metryki czasowe (Temporal, np. dojrzałość exploita) i środowiskowe (Environmental, dla konkretnego wdrożenia).
Wersja 4.0, opublikowana przez FIRST 1 listopada 2023 r., zmienia kilka rzeczy:
Wersja 4.0 wprowadza też nazwy dla wyników z różnych grup metryk: CVSS-B (tylko bazowe), CVSS-BT (bazowe i zagrożenia), CVSS-BE (bazowe i środowiskowe) oraz CVSS-BTE (wszystkie trzy grupy).
Przykład demonstracyjny - podatność IDOR w aplikacji do faktur: zalogowany klient zmienia numer faktury w adresie żądania i pobiera fakturę innego klienta. W CVSS 3.1 jej wektor wygląda tak:
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
| Metryka | Wartość | Co oznacza w tym przykładzie |
|---|---|---|
| AV:N | Network | atak przez internet |
| AC:L | Low | bez szczególnych warunków - wystarczy zmienić numer |
| PR:L | Low | potrzebne jest zwykłe konto klienta |
| UI:N | None | ofiara nie musi nic robić |
| S:U | Unchanged | skutki w obrębie tej samej aplikacji |
| C:H | High | dostęp do faktur wszystkich klientów |
| I:N, A:N | None | bez zmiany danych i bez wpływu na dostępność |
Wynik bazowy tego wektora to 6.5, czyli Medium. Gdyby faktury dało się pobrać bez logowania (PR:N), wynik wzrósłby do 7.5, czyli High.
Ten sam przypadek w CVSS 4.0:
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N
Wynik dla wektora 4.0 wylicza się w kalkulatorze FIRST. W tej wersji nie powstaje on z prostego wzoru, tylko z tabeli wartości przypisanych grupom podobnych wektorów (MacroVector), dlatego wyników 3.1 nie przelicza się ręcznie na 4.0.
Jak oceniamy ryzyko w testach, opisujemy w części o metodyce testów penetracyjnych, a pełny opis przykładowej podatności z wektorem CVSS pokazujemy na stronie testów penetracyjnych aplikacji webowych. Na co patrzeć, porównując raporty i oferty różnych firm, wyjaśniamy w artykule jak porównać oferty na testy penetracyjne.
Wynik 9.8 mieści się w przedziale 9.0-10.0, czyli w kategorii Critical. Taką ocenę w CVSS 3.1 dostaje np. podatność wykorzystywana zdalnie przez sieć, bez uprawnień i bez udziału użytkownika, z wysokim wpływem na poufność, integralność i dostępność - wektor CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H.
Nie wprost. Wersje mają inne metryki i inny sposób wyliczania wyniku, więc ta sama podatność może dostać w nich różne oceny. Dlatego przy każdym wyniku podaje się wersję i pełny wektor, który zaczyna się od CVSS:3.1 albo CVSS:4.0.
Standard rozwija organizacja FIRST (Forum of Incident Response and Security Teams). Oceny znanych podatności z identyfikatorem CVE publikują m.in. producenci oprogramowania i bazy podatności, a podatność znalezioną w teście penetracyjnym ocenia tester - w raporcie dla konkretnego systemu.
Słownik
IDOR (Insecure Direct Object Reference) - co to jest, jak wygląda na przykładzie żądania HTTP, jak go testować i naprawić oraz czym różni się od BOLA w API.
Cyberbezpieczeństwo · Testy penetracyjne
Testy penetracyjne aplikacji webowych i mobilnych, API, infrastruktury, chmury i kodu. OWASP, PTES, raport z dowodami i retest po naprawach.
Testy penetracyjne · Aplikacje webowe
Testy penetracyjne aplikacji webowych według OWASP WSTG v4.2 - uwierzytelnianie, uprawnienia, logika biznesowa i API. Raport z dowodami, CVSS i retest.
Opisz krótko, czego potrzebujesz - wrócimy z propozycją kolejnych kroków.
lub zadzwoń pod numer +48 575 621 877