Subdomenii partajate, două intrări: cine vede ce înregistrări?

Clinica A și Clinica B partajează o singură bază de cod, două subdomenii și un amestec de vizitatori din birou și prin VPN. Echipele de rețea tind să configureze cele două intrări separat, și este în regulă, atâta timp cât aplicația nu o face. Verificările de mai jos aparțin aplicației și ar trebui să se comporte identic indiferent de ușa folosită de cerere.

În primul rând: numele de gazdă doar numește un chiriaș

Rezolvați numele de gazdă solicitat față de o mapare întreținută de administrator și respingeți orice este necunoscut. Folosiți valoarea de gazdă validată de framework în loc de antetul brut, astfel încât un Host falsificat să nu poată injecta o cheie de căutare. O potrivire reușită spune codului ce configurație de chiriaș și ce branding să încarce. Nu spune nimic despre dacă apelantul poate vedea datele acelui chiriaș. Țineți acea a doua întrebare într-o funcție separată cu o intrare separată.

O funcție auxiliară partajată care returnează atât contextul, cât și permisiunea dintr-o singură căutare de nume de gazdă este începutul defectului.

În al doilea rând: calitatea de membru vine din sesiune

Căutați calitățile de membru active ale utilizatorului autentificat și comparați-le cu chiriașul din prima verificare. Un utilizator care aparține ambelor clinici poate comuta, dar comutarea ar trebui să fie o acțiune explicită înregistrată în contextul cererii, nu o deducție din URL. Un utilizator care aparține unei clinici și o solicită pe cealaltă este respins, inclusiv pentru descărcări și apeluri API.

Testați cazul negativ editând un identificator de înregistrare și un parametru de chiriaș. Dacă oricare dintre modificări returnează date, domeniul este citit din cerere și nu din calitatea de membru verificată.

Domeniul cookie-urilor și autentificarea unică decid unde poate fi prezentat un cont. Ele nu decid ce poate citi acel cont.

În al treilea rând: rețeaua nu dovedește nimic despre persoană

O poartă VPN autentifică un tunel, iar o listă publică de permisiuni autentifică un interval de adrese. Niciuna nu identifică o persoană. NAT adună mulți utilizatori într-o singură adresă sursă, iar un interval de birou face același lucru pentru toți din clădire. Tratați ambele ca fapte de transport și păstrați autorizarea în aplicație, sau într-o integrare care afirmă explicit identitatea și este revizuită ca atare.

DNS este un al treilea fapt de transport. Un răspuns privat necesită o rută privată, iar un frontend public necesită o cale de origine acceptată. Niciunul nu poartă o permisiune.

O propoziție pentru perete: rețeaua decide cum ajunge o cerere, iar aplicația decide ce poate citi.

În al patrulea rând: rulați matricea pe ambele intrări

Folosiți conturi controlate pentru a exersa A la A, B la B, A la B, un nume de gazdă necunoscut și un cont autentificat fără calități de membru. Al patrulea și al cincilea ar trebui să eșueze închis și să nu cadă niciodată pe un chiriaș implicit. Rulați aceeași matrice și prin intrarea VPN, cu un borcan de sesiune pe cont:

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

Apoi modificați o intrare din lista de permisiuni și rulați din nou. Un rezultat care se mișcă înseamnă că un control de rețea ia o decizie de autorizare.

Repetați matricea după orice modificare în frontend, deoarece o a doua cale de cod care sare peste verificare este cea mai comună modalitate prin care această graniță erodează. Rezultatul așteptat este plictisitor: fiecare intrare produce aceleași răspunsuri.