Zdieľané subdomény, dva vstupy: kto vidí ktoré záznamy?

Klinika A a Klinika B zdieľajú jednu kódovú základňu, dve subdomény a mix návštevníkov z kancelárie a cez VPN. Sieťové tímy zvyčajne konfigurujú oba vstupy oddelene, a to je v poriadku, kým to aplikácia nerobí. Nižšie uvedené kontroly patria do aplikácie a mali by sa správať rovnako bez ohľadu na to, ktorými dverami požiadavka prišla.

Po prvé: názov hostiteľa pomenúva len nájomcu

Preložte požadovaný názov hostiteľa podľa mapovania, ktoré spravuje administrátor, a čokoľvek neznáme odmietnite. Použite overenú hodnotu hostiteľa z frameworku namiesto surovej hlavičky, aby podvrhnutý Host nemohol vložiť vyhľadávací kľúč. Úspešná zhoda povie kódu, ktorú konfiguráciu nájomcu a ktorý branding načítať. Nič nehovorí o tom, či volajúci smie vidieť údaje tohto nájomcu. Druhú otázku držte v samostatnej funkcii so samostatným vstupom.

Spoločná pomocná funkcia, ktorá z jedného vyhľadania názvu hostiteľa vracia kontext aj oprávnenie, je začiatok chyby.

Po druhé: členstvo prichádza z relácie

Vyhľadajte aktívne členstvá overeného používateľa a porovnajte ich s nájomcom z prvej kontroly. Používateľ, ktorý patrí do oboch kliník, môže prepínať, ale prepnutie musí byť výslovná akcia zaznamenaná v kontexte požiadavky, nie odvodenie z URL. Používateľ, ktorý patrí do jednej kliniky a žiada druhú, je odmietnutý, vrátane stiahnutí a volaní API.

Otestujte negatívny prípad úpravou identifikátora záznamu a parametra nájomcu. Ak ktorákoľvek zmena vráti údaje, rozsah sa číta z požiadavky, nie z overeného členstva.

Rozsah cookies a jednotné prihlásenie rozhodujú, kde sa dá účet prezentovať. Nerozhodujú, čo tento účet smie čítať.

Po tretie: sieť nepreukazuje o človeku nič

VPN brána autentifikuje tunel a verejný zoznam povolených adries autentifikuje rozsah adries. Ani jedno neidentifikuje osobu. NAT zlučuje mnohých používateľov do jednej zdrojovej adresy a kancelársky rozsah robí to isté pre všetkých v budove. Berte oboje ako fakty o preprave a autorizáciu držte v aplikácii alebo v integrácii, ktorá identitu výslovne tvrdí a je ako taká posudzovaná.

DNS je tretí fakt o preprave. Súkromná odpoveď potrebuje súkromnú trasu a verejný frontend potrebuje podporovanú cestu k originu. Žiadny z nich nenesie oprávnenie.

Jedna veta na stenu: sieť rozhoduje, ako požiadavka dorazí, a aplikácia rozhoduje, čo smie čítať.

Po štvrté: spustite maticu na oboch vstupoch

Použite kontrolované účty na precvičenie A na A, B na B, A na B, neznámeho názvu hostiteľa a overeného účtu bez členstiev. Štvrtý a piaty musia zlyhať zatvorene a nikdy nesmú skĺznuť k predvolenému nájomcovi. Spustite rovnakú maticu aj cez VPN vstup, s jedným pohárom relácie pre 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 zmeňte položku zoznamu povolených adries a spustite znova. Výsledok, ktorý sa pohne, znamená, že sieťová kontrola rozhoduje o autorizácii.

Maticu opakujte po každej zmene frontendu, pretože druhá cesta kódu, ktorá kontrolu preskakuje, je najbežnejší spôsob, akým táto hranica eroduje. Očakávaný výsledok je nudný: každý vstup dáva rovnaké odpovede.