Delte underdomene, to inngangar: kven ser kva for postar?

Klinikk A og Klinikk B deler éin kodebase, to underdomene og ei blanding av vitjande frå kontoret og via VPN. Nettverksteam har ein tendens til å konfigurere dei to inngangane kvar for seg, og det er greitt, så lenge applikasjonen ikkje gjer det. Kontrollane nedanfor høyrer heime i applikasjonen og bør oppføre seg identisk uansett kva dør førespurnaden brukte.

Fyrst: vertsnamnet namngjev berre ein leigetakar

Slå opp det førespurde vertsnamnet mot ei tilordning administratoren vedlikeheld, og avvis alt ukjent. Bruk den validerte vertsverdien til rammeverket i staden for den rå headeren, slik at ein konstruert Host ikkje kan injisere ein oppslagsnøkkel. Eit vellukka treff fortel koden kva leigetakarkonfigurasjon og kva merkevare som skal lastast. Det seier ingenting om den kallande får sjå dataa til den leigetakaren. Hald det andre spørsmålet i ein eigen funksjon med eit eige inndata.

Ein delt hjelpefunksjon som returnerer både kontekst og løyve frå eitt einaste vertsnamnoppslag, er byrjinga på feilen.

Deretter: medlemskap kjem frå økta

Slå opp dei aktive medlemskapa til den autentiserte brukaren og samanlikn dei med leigetakaren frå den fyrste kontrollen. Ein brukar som høyrer til båe klinikkane kan bytte, men byttet bør vere ei eksplisitt handling registrert i førespurnadskonteksten, ikkje ei slutning frå URL-en. Ein brukar som høyrer til éin klinikk og ber om den andre, vert avvist, også for nedlastingar og API-kall.

Test det negative tilfellet ved å endre ein postidentifikator og ein leigetakarparameter. Viss ein av endringane returnerer data, vert omfanget lese frå førespurnaden og ikkje frå det stadfesta medlemskapet.

Omfanget til informasjonskapslar og eingongsinnlogging avgjer kvar ein konto kan presenterast. Dei avgjer ikkje kva den kontoen kan lese.

For det tredje: nettverket beviser ingenting om personen

Ein VPN-gateway autentiserer ein tunnel, og ei offentleg tillatingsliste autentiserer eit adresseområde. Ingen av dei identifiserer ein person. NAT samlar mange brukarar i éi kjeldeadresse, og eit kontorområde gjer det same for alle i bygget. Handsame båe som transportfakta og hald autorisasjonen i applikasjonen, eller i ein integrasjon som uttrykkeleg hevdar identitet og vert gjennomgått som slik.

DNS er eit tredje transportfaktum. Eit privat svar krev ei privat rute, og ein offentleg frontend krev ein støtta opphavssti. Ingen av dei ber ei tillating.

Éin setning til veggen: nettverket avgjer korleis ein førespurnad kjem inn, og applikasjonen avgjer kva han kan lese.

For det fjerde: køyr matrisa på båe inngangane

Bruk kontrollerte kontoar til å prøve A hos A, B hos B, A hos B, eit ukjent vertsnamn og ein autentisert konto utan medlemskap. Den fjerde og den femte bør feile lukka og aldri falle tilbake til ein standard leigetakar. Køyr den same matrisa gjennom VPN-inngangen òg, med éi øktkrukke per konto:

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

Endre deretter ein oppføring i tillatingslista og køyr på nytt. Eit resultat som flyttar seg, tyder på at ein nettverkskontroll tek ei autorisasjonsavgjerd.

Gjenta matrisa etter kvar endring i frontend, fordi ein andre kodeveg som hoppar over kontrollen, er den vanlegaste måten denne grensa eroderer på. Det forventa resultatet er keisamt: kvar inngang gjev dei same svara.