Premenenie jedného kliknutia na dočasné pravidlo firewallu je pohodlné a zároveň to buduje autorizačný systém, ktorý rozhoduje, kto sa smie dostať k službe. Vydáva adresu, nie osobu, a tento rozdiel je dôležitý v okamihu, keď dvaja ľudia zdieľajú jeden NAT. Vymedzte rozsah povolenia, potvrďte ho vedome a dajte vypršaniu zmysel skôr, než sa odkaz vytvorí. Rozhodnutie pred vami je, kam umiestniť hranicu, nie či má vôbec existovať.

Určte, na ktorú otázku povolenie odpovedá

Začnite od požiadavky. Ak sa má k službe dostať konkrétna osoba a aplikácia túto osobu už autentifikuje, autentifikovaná brána udrží identitu v mieste presadzovania a vôbec nepotrebuje pripustenie adresy. Ak je cieľom build agent, administratívny jump port alebo zariadenie, ktoré sa nemôže zúčastniť prihlasovania používateľa, povolenie adresy s vymedzeným rozsahom môže byť jedinou praktickou kontrolou.

Voľba pripustenia podľa adresy pre aplikáciu obrátenú na používateľov presúva skutočný problém autorizácie inam a portál potom zdedí vinu za medzeru, ktorú nikdy neuzavrel.

Ohraničte požiadavku na serveri

Prehliadač nesmie voliť cieľ, port ani prefix. Portál rozlíši službu z vlastných záznamov a overí nárok testom na strane servera, čo je ten istý princíp, ktorý usmernenia OWASP k autorizácii uplatňujú na každú požiadavku. Odvodzovanie adresy patrí tiež k chránenej hranici: keď reverzný proxy hlási adresu klienta, prijmite iba nakonfigurovanú reťaz proxy a jeho zdokumentované zaobchádzanie s hlavičkami. Hlavička preposielania, ktorú dodá návštevník, je tvrdenie o pôvode, nie jeho dôkaz.

Potom overte, či portál a služba vidia ten istý zdroj. Rozdelený tunel, jeden skok cez proxy a IPv4 proti IPv6 môžu dvom cieľom dať dve rôzne adresy, takže povolenie aktivované jednou cestou nemusí pokryť nasledujúcu požiadavku.

Ukážte povolenie skôr, než ho nainštalujete

Otvorenie odkazu by malo zobraziť navrhovanú službu, pozorovaný zdroj a trvanie a zatiaľ nič nemeniť. Ten jediný krok mení odkaz z e-mailu z akcie na návrh a bráni robotovi náhľadu alebo skeneru pošty udeliť prístup iba tým, že ho stiahne.

Potvrdenie by malo byť požiadavkou meniacou stav s obvyklými obranami proti medzistránkovým útokom a proti cudziemu pôvodu. Token by mal byť jednorazový a spotrebovať sa atomicky v okamihu inštalácie pravidla a záznam by mal zachytiť vlastníka, službu, adresu, identifikátor povolenia a vypršanie bez toho, aby kedy zaprotokoloval surový token.

Doručenie tokenu si zaslúži rovnakú starostlivosť ako pravidlo samo. Vypršaný alebo už spotrebovaný odkaz, ktorý stále vytvorí pravidlo, sú druhé dvere osadené tým istým kľúčom.

Adresa je zdieľaná aj vtedy, keď povolenie žije

Kancelársky NAT, NAT operátora a zdieľaný výstup VPN stavajú každý niekoľko ľudí za jednu adresu. Pripustiť túto adresu znamená pripustiť všetkých za ňou — pokiaľ ide o ďalšiu hranicu služby —, a pritom nepreukázať nič o tom, kto drží účet, ktorý služba očakáva.

Odstránenie pravidla tiež nie je univerzálne odpojenie. Nadviazané spojenia, tokeny aplikácií v medzipamäti a dlho žijúce relácie môžu pravidlo prežiť o minúty alebo oveľa dlhšie, takže zvolená životnosť by mala odrážať, čo služba robí po pripustení, a nie len ako dlho pravidlo existuje.

Otestujte štyri prípady a obe rodiny adries

Povolenie je len také dobré, ako štyri prípady, ktoré prežije: nová povolená požiadavka, neschválený žiadateľ, opakovanie toho istého odkazu a tá istá požiadavka po vypršaní.

Potom otestujte každú rodinu zvlášť, pretože zdrojová adresa, ktorú služba pozoruje, sa medzi nimi môže líšiť.

dig +short A service.example.com
dig +short AAAA service.example.com
curl -4 -sS -o /dev/null -w "%{http_code}\n" https://service.example.com
curl -6 -sS -o /dev/null -w "%{http_code}\n" https://service.example.com

Užitočným výsledkom je dočasné, auditovateľné rozhodnutie o pripustení pod bežnou autorizáciou používateľa, a nie trvalé otvorenie nesúce meno toho, kto klikol prvý.

Súvisiace články