Bezpečnostní audit kódu — redigovaná ukázka

Co to je. Očištěný výřez z interního auditu vlastního kódu — vlastní kód jsme prohnali svojí útočně vedenou metodou („dogfooding"). Identifikátory cíle jsou redigované; metoda, nálezy, závažnosti a trasy dat jsou doslovné. Je to reprezentativní ukázka klientské dodávky, ne marketingová maketa.

Proč „útok napřed + falsifikace" (metoda)

Většina skenerů optimalizuje na úplnost — vynesou všechno, co se shoduje se vzorem slabiny, a třídění nechají na vás. My optimalizujeme na přesnost pod protivníkem: každý kandidát musí přežít krok, jehož jediným úkolem je vyvrátit ho.

Recon ─▶ Paralelní lov ─▶ Adverzní falsifikace ─▶ Filtr proveditelnosti ─▶ Nezávislé ověření
 mapuj    mnoho hypotéz     „dokaž, že to NENÍ      „dosáhne na to           jen pro čtení,
 vstupy   současně           skutečné" (výchozí      skutečný aktér?"        jiný kontext
 a místa                     stav: vyvráceno)                                (hodnotí ≠ našel)
 užití

Při tomhle běhu falsifikační krok zabil 2 z 10 kandidátů jako plané poplachy (viz Zabití kandidáti níže). Zpráva, ve které je jen ověřené, má větší cenu než zpráva dlouhá: rozpočet na opravy padne na skutečné vady, ne na jejich třídění.

Model důvěry (tohle je to, co stropuje závažnost)

Služba naslouchá jen na 127.0.0.1 (gateway.py:475) a každou cestu kromě /health ověřuje jedním sdíleným instalačním tokenem X-Api-Token (secrets.token_urlsafe(24), porovnání v konstantním čase :273). Existuje přesně jeden principál — kterýkoli lokální proces, který ten token drží — takže žádná hranice mezi nájemníky neexistuje. To stropuje každý nález: „číst/zapsat libovolný úkol" je ověřený základní stav a dosah je jeden loopbackový počítač. Nejcennější nález (F-001) je nezávislý na principálovi (podvržení autorství + destrukce), proto Medium; všechno ostatní je Low. Poctivé vymezení poráží nafukování závažnosti.

Souhrn

Ke každému nálezu byl dodán statický důkaz a test zneužití (napsaný, nespuštěný).

Sloupce Severity a Status zůstávají v angličtině schválně — jsou to kanonické tokeny, ze kterých se počítá pečeť na konci dokumentu. Kdyby se přeložily, česká a anglická verze by daly jiný otisk a recept by nešel splnit.

Nálezy

F-001 — Podvržení odpovědi + vynucené smazání libovolného čekajícího úkolu

Oprava — nasazena a přeměřena týž den (identifikátory redigované, logika doslovná):

  # obsluha POST /answer
- # kdokoli mohl odpovědět na JAKÉKOLI id — existence nekontrolovaná, autor napevno
- append_reply(author="worker", reply_to=req["reply_to"], text=req["text"])
+ # odpověď musí odpovídat skutečnému, stále OTEVŘENÉMU požadavku — vše ostatní se odmítá
+ if read_request(reply_to) is None:      # takový otevřený požadavek není -> 404
+     return 404
+ if already_answered(reply_to):          # dvakrát odpovědět nelze     -> 409
+     return 409
+ append_reply(author="worker", reply_to=reply_to, text=text)

Přeměření po opravě: cesta podvržení teď vrací 404 a nepřipojí nic; čekající požadavek přežije úklidový průchod (útočník ho už nemůže vynuceně převést do množiny „zodpovězených"). Obě větve — podvržení autorství i vynucené smazání — se zavírají u téže pojistky. Doba od potvrzení k ověřené opravě: týž den.

F-002 — next_id() souběh TOCTOU

F-003 — Neomezené čtení těla požadavku (/submit, /upload)

F-004 — Neomezené dekódování base64 přílohy + zápis na disk (/upload)

F-005 — Neomezené čtení těla požadavku (/answer)

F-006 — Sdílený rozpočet globálního omezovače → odepření služby

F-007 — Neověřený /health spouští úklid souborů

F-008 — Ověřovací token v čitelném souboru a na výstupu

Vyřešená inventura vstupů (doklad o úplnosti)

Seznam nálezů je důvěryhodný jen tehdy, když doloží i to, co bylo prověřeno a čisté. Každý zvenku řízený vstup má přiřazenou dispozici (názvy polí redigované):

Všechny vstupy vyřešeny. Nálezy, které nejdou navázat na jediný vstup (souběžnost, globální omezovač, /health bez vstupu), jsou zachyceny jako F-002 / F-006 / F-007.

Nenalezeno / vyloučeno (prověřené a čisté třídy)

• Injektáž (SQL / příkazová / kódová / SSTI / deserializace): 0 zásahů na eval / exec / subprocess / pickle / yaml.load / os.system v produkčních cestách.
• Průchod adresářem (souborové operace): BEZPEČNÉ — čistička id odstraní oddělovače před jakýmkoli spojením cesty.
• IDOR (mezi principály): není vyjádřitelný — jeden principál se sdíleným tokenem; „číst libovolný úkol" je ověřený základní stav (tohle je důvod vyloučení, ne přehlédnutí).
• XSS / otevřené přesměrování / SSRF: žádné místo vykreslení HTML, žádný odchozí cíl řízený uživatelem, žádné místo přesměrování.
• Obejití ověření: každá cesta kromě /health vynucuje porovnání tokenu v konstantním čase; větev, která by ověření přeskočila, neexistuje.

Ověření záběru (chytili jsme každý výskyt každé kořenové příčiny?)

Každá kořenová příčina se mapuje 1:1 na nálezy — žádný osiřelý výskyt.

Kvalita kódu / obrana do hloubky (dnes nezneužitelné, ale stojí za zpevnění)

Zabití kandidáti (co jsme sami vyvrátili)

Dvě hypotézy došly do adverzního kroku a byly vyvráceny — uvádíme je schválně, protože co skener zahodí je stejně vypovídající jako to, co si nechá:

• IDOR mezi principály — planý poplach na modelu s jediným principálem; větev s průchodem adresářem byla nezávisle blokovaná čističkou id. Zabito.
• Připojení do záznamu bez zámku — přetržený zápis se sám ošetří (nečitelné řádky se při čtení přeskočí); pohlceno nálezem o souběžnosti F-002. Zabito jako samostatná položka.

Poctivé shrnutí jednou větou

Těsně vymezená lokální služba s jedinou skutečnou vadou návrhu (F-001) a hroznem běžných mezer ve zpevnění — 1 Medium, 7 Low, nulové nafukování a dva plané poplachy chycené dřív, než se dostaly do zprávy. Takhle vypadá ověřená dodávka.

Redigovaná ukázka · útočně vedený rozbor · režim jen pro čtení · kdo hodnotí ≠ kdo psal.

Náprava — co se stalo po téhle zprávě

Zpráva výše je snímek běhu z 2026-07-19 a nepřepisuje se. Tohle je dodatek: co se změnilo, kdy, a jak se ta změna přeměřila. Ověřoval ji průchod psaný proti každé opravě — kdo hodnotí ≠ kdo psal platí i na opravu.