Delte underdomener, to innganger: hvem ser hvilke poster?

Klinikk A og Klinikk B deler én kodebase, to underdomener og en blanding av besøkende fra kontoret og via VPN. Nettverksteam har en tendens til å konfigurere de to inngangene hver for seg, og det er greit, så lenge applikasjonen ikke gjør det. Kontrollene nedenfor hører hjemme i applikasjonen og bør oppføre seg identisk uansett hvilken dør forespørselen brukte.

Først: vertsnavnet navngir bare en leietaker

Slå opp det forespurte vertsnavnet mot en tilordning administratoren vedlikeholder, og avvis alt ukjent. Bruk rammeverkets validerte vertsverdi i stedet for den rå headeren, slik at en konstruert Host ikke kan injisere en oppslagnøkkel. Et vellykket treff forteller koden hvilken leietakerkonfigurasjon og merkevare som skal lastes. Det sier ingenting om hvorvidt den kallende får se den leietakerens data. Hold det andre spørsmålet i en egen funksjon med et eget inndata.

En delt hjelpefunksjon som returnerer både kontekst og tillatelse fra ett eneste vertsnavnoppslag, er begynnelsen på feilen.

Deretter: medlemskap kommer fra økten

Slå opp den autentiserte brukerens aktive medlemskap og sammenlign dem med leietakeren fra den første kontrollen. En bruker som tilhører begge klinikkene kan bytte, men byttet bør være en eksplisitt handling registrert i forespørselskonteksten, ikke en slutning fra URL-en. En bruker som tilhører én klinikk og ber om den andre, avvises, også for nedlastinger og API-kall.

Test det negative tilfellet ved å endre en postidentifikator og en leietakerparameter. Hvis en av endringene returnerer data, leses omfanget fra forespørselen og ikke fra det verifiserte medlemskapet.

Omfanget til informasjonskapsler og enkeltpålogging avgjør hvor en konto kan presenteres. De avgjør ikke hva den kontoen kan lese.

For det tredje: nettverket beviser ingenting om personen

En VPN-gateway autentiserer en tunnel, og en offentlig tillatelsesliste autentiserer et adresseområde. Ingen av dem identifiserer en person. NAT samler mange brukere i én kildeadresse, og et kontorområde gjør det samme for alle i bygget. Behandle begge som transportfakta og hold autorisasjonen i applikasjonen, eller i en integrasjon som eksplisitt hevder identitet og gjennomgås som sådan.

DNS er et tredje transportfaktum. Et privat svar trenger en privat rute, og en offentlig frontend trenger en støttet opprinnelsessti. Ingen av dem bærer en tillatelse.

Én setning til veggen: nettverket avgjør hvordan en forespørsel kommer inn, og applikasjonen avgjør hva den kan lese.

For det fjerde: kjør matrisen på begge inngangene

Bruk kontrollerte kontoer til å prøve A hos A, B hos B, A hos B, et ukjent vertsnavn og en autentisert konto uten medlemskap. Den fjerde og den femte bør feile lukket og aldri falle tilbake til en standard leietaker. Kjør den samme matrisen gjennom VPN-inngangen også, med én ø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 en oppføring i tillatelseslisten og kjør på nytt. Et resultat som flytter seg, betyr at en nettverkskontroll tar en autorisasjonsbeslutning.

Gjenta matrisen etter enhver endring i frontend, fordi en andre kodesti som hopper over kontrollen, er den vanligste måten denne grensen eroderes på. Det forventede resultatet er kjedelig: hver inngang gir de samme svarene.