Přeměnit jedno kliknutí na dočasné pravidlo firewallu je pohodlné a zároveň to buduje autorizační systém, který rozhoduje, kdo se smí dostat ke službě. Vydává adresu, nikoli osobu, a tento rozdíl je důležitý ve chvíli, kdy dva lidé sdílejí jeden NAT. Vymezte rozsah povolení, potvrďte je vědomě a dejte vypršení smysl dřív, než se odkaz vytvoří. Rozhodnutí před vámi je, kam umístit hranici, ne zda má nějaká existovat.

Určete, na kterou otázku povolení odpovídá

Začněte od požadavku. Pokud se má ke službě dostat konkrétní osoba a aplikace tuto osobu už autentizuje, autentizovaná brána udrží identitu v místě vynucení a nepotřebuje vůbec žádné připuštění adresy. Pokud je cílem build agent, administrativní jump port nebo zařízení, které se nemůže účastnit přihlašování uživatelů, může být povolení adresy s vymezeným rozsahem jedinou praktickou kontrolou.

Volba připuštění podle adresy u aplikace obrácené na uživatele přesouvá skutečný problém autorizace jinam a portál pak zdědí vinu za mezeru, kterou nikdy neuzavřel.

Ohraničte požadavek na serveru

Prohlížeč nesmí volit cíl, port ani prefix. Portál rozliší službu z vlastních záznamů a ověří nárok testem na straně serveru, což je stejný princip, který pokyny OWASP k autorizaci uplatňují na každý požadavek. Odvozování adresy patří rovněž k chráněné hranici: když reverzní proxy hlásí adresu klienta, přijměte pouze nakonfigurovaný řetězec proxy a jeho dokumentované zacházení s hlavičkami. Hlavička předávání dodaná návštěvníkem je tvrzení o původu, nikoli jeho důkaz.

Pak ověřte, že portál a služba vidí stejný zdroj. Rozdělený tunel, jeden skok přes proxy a IPv4 proti IPv6 mohou dvěma cílům předat dvě různé adresy, takže povolení aktivované jednou cestou nemusí pokrýt následující požadavek.

Ukažte povolení dřív, než ho nainstalujete

Otevření odkazu by mělo vykreslit navrhovanou službu, pozorovaný zdroj a dobu trvání a zatím nic neměnit. Tento jediný krok mění odkaz z e-mailu z akce na návrh a brání robotovi náhledu nebo skeneru pošty udělit přístup tím, že odkaz prostě načte.

Potvrzení by mělo být požadavkem měnícím stav s obvyklými obranami proti mezistránkovým útokům a proti cizímu původu. Token by měl být jednorázový a spotřebovat se atomicky v okamžiku instalace pravidla a záznam by měl zachytit vlastníka, službu, adresu, identifikátor povolení a vypršení, aniž by kdy zalogoval surový token.

Doručení tokenu si zaslouží stejnou péči jako pravidlo samo. Vypršený nebo už spotřebovaný odkaz, který stále vytvoří pravidlo, jsou druhé dveře osazené stejným klíčem.

Adresa je sdílená, i když povolení žije

Kancelářský NAT, NAT operátora a sdílený výstup VPN stavějí každý několik lidí za jednu adresu. Připustit tuto adresu znamená připustit všechny za ní — pokud jde o další hranici služby —, a přitom neprokázat nic o tom, kdo drží účet, který služba očekává.

Odebrání pravidla také není univerzální odpojení. Navázaná spojení, tokeny aplikací v mezipaměti a dlouho žijící relace mohou pravidlo přežít o minuty nebo mnohem déle, takže zvolená životnost by měla odrážet, co služba dělá po připuštění, a ne jen jak dlouho pravidlo existuje.

Otestujte čtyři případy a obě rodiny adres

Povolení je jen tak dobré jako čtyři případy, které přežije: nový povolený požadavek, neschválený žadatel, opakování stejného odkazu a stejný požadavek po vypršení.

Pak otestujte každou rodinu zvlášť, protože zdrojová adresa, kterou služba pozoruje, se mezi nimi může lišit.

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žitečným výsledkem je dočasné, auditovatelné rozhodnutí o připuštění pod běžnou autorizací uživatele, nikoli trvalé otevření nesoucí jméno toho, kdo klikl první.

Související články