Sdílené subdomény, dva vstupy: kdo vidí které záznamy?

Klinika A a Klinika B sdílejí jednu kódovou základnu, dvě subdomény a mix návštěvníků z kanceláře a přes VPN. Síťové týmy obvykle konfigurují oba vstupy odděleně, což je v pořádku, dokud to nedělá aplikace. Níže uvedené kontroly patří do aplikace a musí se chovat stejně bez ohledu na to, kterými dveřmi požadavek přišel.

Za prvé: název hostitele pojmenovává jen nájemce

Přeložte požadovaný název hostitele podle mapování, které spravuje administrátor, a cokoli neznámého odmítněte. Použijte ověřenou hodnotu hostitele z frameworku místo surové hlavičky, aby podvržený Host nemohl vložit klíč pro vyhledání. Úspěšná shoda řekne kódu, kterou konfiguraci nájemce a který branding načíst. Nic neříká o tom, zda volající smí vidět data tohoto nájemce. Druhou otázku držte v samostatné funkci se samostatným vstupem.

Společná pomocná funkce, která z jednoho vyhledání názvu hostitele vrací kontext i oprávnění, je začátek chyby.

Za druhé: členství přichází z relace

Vyhledejte aktivní členství ověřeného uživatele a porovnejte je s nájemcem z první kontroly. Uživatel, který patří do obou klinik, může přepínat, ale přepnutí musí být výslovná akce zaznamenaná v kontextu požadavku, ne odvození z URL. Uživatel, který patří do jedné kliniky a žádá druhou, je odmítnut, včetně stahování a volání API.

Otestujte negativní případ úpravou identifikátoru záznamu a parametru nájemce. Pokud některá změna vrátí data, rozsah se čte z požadavku, nikoli z ověřeného členství.

Rozsah cookies a jednotné přihlášení rozhodují, kde lze účet prezentovat. Nerozhodují, co tento účet smí číst.

Za třetí: síť neprokazuje o člověku nic

VPN brána autentizuje tunel a veřejný seznam povolených adres autentizuje rozsah adres. Ani jedno neidentifikuje osobu. NAT slučuje mnoho uživatelů do jedné zdrojové adresy a kancelářský rozsah dělá totéž pro všechny v budově. Berte obojí jako fakta o přenosu a autorizaci držte v aplikaci nebo v integraci, která identitu výslovně tvrdí a je jako taková posuzována.

DNS je třetí fakt o přenosu. Soukromá odpověď potřebuje soukromou trasu a veřejný frontend potřebuje podporovanou cestu k originu. Žádný z nich nenese oprávnění.

Jedna věta na zeď: síť rozhoduje, jak požadavek dorazí, a aplikace rozhoduje, co smí číst.

Za čtvrté: spusťte matici na obou vstupech

Použijte kontrolované účty k procvičení A na A, B na B, A na B, neznámého názvu hostitele a ověřeného účtu bez členství. Čtvrtý a pátý musí selhat zavřeně a nikdy nesmí sklouznout k výchozímu nájemci. Spusťte stejnou matici i přes VPN vstup, s jedním úložištěm cookies relace pro každý účet:

curl -s -o /dev/null -w '%{http_code}' -b jar.txt https://clinic-b.example.com/records/42
curl -s -o /dev/null -w '%{http_code}' -b jar.txt https://clinic-a.example.com/records/42

Potom změňte položku seznamu povolených adres a spusťte znovu. Výsledek, který se pohne, znamená, že síťová kontrola rozhoduje o autorizaci.

Matici opakujte po každé změně frontendu, protože druhá cesta kódu, která kontrolu přeskakuje, je nejběžnější způsob, jak tato hranice eroduje. Očekávaný výsledek je nudný: každý vstup dává stejné odpovědi.