k0nsult.cloud / ai-truth / ipIII / orchestrator / pentest-self

Raport z wewnętrznego pentestu — ćwiczenie purple-team na własnym serwisie

Zrobiliśmy sobie pentesty na ipIII (RED — 9 wektorów read-only) i poprosiliśmy niezależnego pentestera (r0xk0n) o drugą rundę. Ta strona pokazuje CO testowano i JAKA obrona zadziałała — bez payloadów ofensywnych, bez instrukcji ataku. Wynik i mitigacje poniżej, jawnie z odróżnieniem tego, co naprawiono.

Orchestrator Roadmap dev Status matrix Znane ograniczenia Security architecture Pentest self ← ipIII hub

Ramy tego ćwiczenia. Raport z wewnętrznego ćwiczenia purple-team na własnym serwisie K0NSULT ipIII (po pisemnych Rules of Engagement, autoryzowane). Wyłącznie defensywny opis — pokazuje CO testowano i JAKA obrona zadziałała, bez payloadów ofensywnych i bez instrukcji ataku. Dane/wyniki syntetyczne z analizy własnego kodu i konfiguracji, nie z testu na cudzej infrastrukturze. Status strony: exercise-log, noindex — to log ćwiczenia, nie oferta handlowa.

9 wektorów read-only + niezależny pentest r0xk0n. Zero potwierdzonych krytycznych dziur na zbadanych wektorach.

Metodologia: każdy wektor testowany read-only lub niedestrukcyjnym probe, wynik weryfikowany przez adwersaryjny werdykt (druga rola próbuje obalić ustalenie), zanim trafi do tego rejestru jako „broni się" albo jako finding do naprawy. To NIE jest deklaracja nieprzenikalności systemu — to raport z konkretnego, ograniczonego zakresu testów na dzień weryfikacji.

PRZEPŁYW: wektor→test read-only→dowód (log/kod)→werdykt adwersaryjny→naprawa albo false-positive

1. Zakres ćwiczenia — 9 wektorów

Wyłącznie read-only i niedestrukcyjne probe na własnym środowisku. Bez ofensywnych payloadów, bez prób obejścia mechanizmów obronnych na cudzej infrastrukturze. Data weryfikacji: 2026-07-05.

1. Auth-bypass

Próby ominięcia uwierzytelniania (brak tokenu, zmanipulowany token, algorithm-confusion).

2. IDOR / BOLA

Dostęp do zasobu innego tenanta/organizacji przez zmianę identyfikatora w żądaniu.

3. Injection (SQL/CSV/XXE)

Próby wstrzyknięcia w zapytania SQL, formuły CSV, parsowanie XML.

4. Secrets-exposure

Szukanie sekretów zaszytych w kodzie, logach, odpowiedziach błędów.

5. CSP / nagłówki

Sprawdzenie polityki CSP, obecności inline JS, kompletu nagłówków bezpieczeństwa.

6. Rate-limit

Test limitów żądań, zachowania za proxy, ochrony przed pętlami.

7. Parser-safety

Fuzzing parserów importu (skanery, CSV, XML) losowymi/zniekształconymi danymi.

8. Input-validation

Walidacja pól wejściowych, limity długości, typy danych.

9. Info-leak

Sprawdzenie, czy błędy/odpowiedzi ujawniają stack-trace, wersje, ścieżki serwera.

2. Wynik: tabela wektor → obrona

Kolumna „Obrona" opisuje wyłącznie CO chroni (mechanizm), nie jak go obejść. Zero szczegółów ofensywnych.

Wektor	Obrona zaobserwowana	Wynik
Auth-bypass	Fail-closed: brak `JWT_SECRET` → proces zatrzymuje start (`process.exit`), nie uruchamia się w trybie niedomyślnie otwartym. OIDC RS256 wymuszony dwukrotnie (walidacja algorytmu w dwóch miejscach) — bez podatności typu algorithm-confusion. RBAC granularny per rola.	broni się
IDOR / BOLA	`tenantGuard` zwraca 404 dla zasobu spoza kontekstu żądającego (nie ujawnia nawet istnienia obcego zasobu) — fail-closed zamiast fail-open.	broni się
Injection (SQL/CSV/XXE)	Zapytania SQL wyłącznie parametryzowane (`$1..$N`, brak konkatenacji stringów). Parsery XML oparte o regex (brak silnika XML z zewnętrznymi encjami — XXE nieegzekwowalny w tej architekturze). Eksport CSV z formula-guard (prefiks neutralizujący przed `=`/`+`/`-`/`@`).	broni się
Secrets-exposure	`git grep` po wzorcach sekretów w repo — pusty wynik. `.env` w `.gitignore`. W trybie PROD błędy zwracają generyczny `safeError` bez stack-trace i bez szczegółów implementacji.	broni się
CSP / nagłówki	Nonce 128-bit generowany per-request, `strict-dynamic`, brak dopuszczonego inline JS bez nonce, HSTS z preload, komplet standardowych nagłówków bezpieczeństwa (X-Content-Type-Options, X-Frame-Options, Referrer-Policy).	broni się
Rate-limit	Wielowarstwowe limity (globalny + per-endpoint), `trust proxy` skonfigurowany poprawnie (limit liczony po realnym IP, nie po adresie proxy), watcher wykrywający pętle żądań.	broni się
Parser-safety	Limit rozmiaru body (body-cap) przed parsowaniem, zestaw testów fuzz 30/30 przechodzących bez crasha procesu, guardy wejścia przed przekazaniem do logiki biznesowej.	broni się
Input-validation	Walidacja typu/długości/formatu na wejściach API przed zapisem do bazy; odrzucenie zamiast próby „naprawienia" złych danych.	broni się
Info-leak	Odpowiedzi błędów w PROD generyczne (bez ścieżek serwera, wersji zależności, stack-trace); szczegóły trafiają wyłącznie do logów serwerowych.	broni się

3. Niezależny pentest — r0xk0n (rundy R1/R2)

Poza wewnętrznym ćwiczeniem RED, zewnętrzny pentester (r0xk0n) przeprowadził dwie rundy testów. Znalazł realne findingi — zostały naprawione, nie ukryte. To dowód, że ćwiczenie wewnętrzne nie zastępuje niezależnej weryfikacji, a wyniki obu razem dają pełniejszy obraz.

Runda	Finding	Naprawa
R2	Izolacja multi-tenant: zapytania po organizacjach nie były w pełni scope'owane per tenant.	Scoping `/orgs` per-tenant + test IDOR cross-tenant weryfikujący fix.
R1/R2	Pinning algorytmu w walidacji JWT.	Pin `HS256` jawnie w walidatorze wewnętrznego JWT v1 (osobny mechanizm od OIDC/RS256 z wiersza Auth-bypass — każdy walidator przypięty do jednego algorytmu, brak algorithm-confusion między nimi).
R1	Eksport CSV podatny na wstrzyknięcie formuł w arkuszu odbiorcy.	Formula-guard: prefiksowanie komórek zaczynających się od `=`/`+`/`-`/`@`.
R1	Dowód (evidence) bez faktycznej treści mógł być traktowany jak zweryfikowany.	Dowód bez treści → status `UNVERIFIED` zamiast domyślnego zaliczenia.

Wszystkie cztery pozycje: naprawione i domknięte w kodzie (commity powiązane z audytem R2 tenant-evidence). Rejestr nie ukrywa, że coś znaleziono — przeciwnie, to dowód działającego procesu evidence-first.

4. Metodologia evidence-first

finding→dowód (kod/log/test)→werdykt adwersaryjny (próba obalenia)→naprawa albo false-positive

Werdykt adwersaryjny oznacza, że każde ustalenie „broni się" jest kontrolowane przez rolę, która aktywnie próbuje je obalić — nie zapisujemy „zielonego" wyniku na słowo. Jeśli próba obalenia się nie powiodła (finding jest realny), trafia do naprawy jak w sekcji 3. Jeśli próba obalenia się powiodła (ustalenie było błędne albo dotyczyło warunku niemożliwego do wywołania w tej architekturze), oznaczamy to jako false-positive, nie jako „lukę zamkniętą".

Realna dziura vs. dziura latentna. Rozróżniamy defekt aktywny (wywoływalny dziś, na tej konfiguracji) od defektu latentnego — teoretycznie możliwego dopiero po zmianie flagi/konfiguracji, która dziś jest wyłączona. Latentne ograniczenia trafiają na rejestr znanych ograniczeń, nie do tego raportu jako „potwierdzona dziura".

5. Uczciwie: co „zero dziur" znaczy, a czego nie

„Zero potwierdzonych krytycznych dziur" odnosi się wyłącznie do 9 zbadanych wektorów w tym ćwiczeniu, na dzień weryfikacji 2026-07-05. To NIE jest deklaracja nieprzenikalności systemu ani twierdzenie, że wszystkie możliwe wektory zostały sprawdzone. „100%" w naszej doktrynie znaczy pokrycie dowodowe (9/9 wektorów z tego zakresu ma dowód), nie brak jakiegokolwiek ryzyka rezydualnego.

Drobny hardening do rozważenia (jawnie, nie ukrywamy): miejscami porównania sekretów/tokenów mogłyby być bardziej konsekwentnie timing-safe (stałoczasowe) zamiast standardowego porównania stringów — kandydat do kolejnej iteracji, nie potwierdzony dziś jako wykorzystywalny finding.

6. Symulacje ataków — osobna warstwa

Ten raport to log ćwiczenia obronnego (co broni system). Symulacje scenariuszy ataku/obrony i metodologii reagowania na incydent to osobna, dedykowana warstwa — wyraźnie oznaczona jako SYMULACJA, noindex:

/sztab-obrony — model dowództwa i stanów gotowości (BASELINE/ELEVATED/FULL).
/matcher-incydent — dopasowanie scenariusza incydentu do playbooka.
/symulacja-pl-wschod — symulacja metodologii reagowania w scenariuszu regionalnym.

9/9

wektorów zbadanych

read-only + niedestrukcyjne probe

potwierdzonych krytycznych dziur

na zbadanym zakresie, dziś

findingi r0xk0n R1/R2

wszystkie naprawione

hardening do rozważenia

timing-safe compare, nie potwierdzony finding

Powiązane strony. Architektura bezpieczeństwa → /security-architecture · rejestr ograniczeń jeszcze niedomkniętych → /known-limitations · macierz statusów wszystkich elementów → /status-matrix · zasady zaangażowania (RoE) → /engagement.

Granica etyczna i prawna. Ten raport opisuje wyłącznie ćwiczenie defensywne na własnym środowisku, po pisemnych RoE, dane syntetyczne. Nie zawiera payloadów, exploitów ani instrukcji ofensywnych. Nie jest to test na cudzej infrastrukturze i nie zastępuje niezależnej weryfikacji przez zewnętrznego pentestera ani formalnego przeglądu bezpieczeństwa.