Delade underdomäner, två ingångar: vem ser vilka poster?

Klinik A och Klinik B delar en kodbas, två underdomäner och en blandning av besökare från kontoret och via VPN. Nätverksteam brukar konfigurera de två ingångarna separat, och det är okej, så länge applikationen inte gör det. Kontrollerna nedan hör hemma i applikationen och bör bete sig identiskt oavsett vilken dörr begäran använde.

Först: värdnamnet namnger bara en hyresgäst

Slå upp det begärda värdnamnet mot en mappning som administratören underhåller, och avvisa allt okänt. Använd ramverkets validerade värdvärde i stället för den råa headern, så att en konstruerad Host inte kan injicera en söknyckel. En lyckad matchning berättar för koden vilken hyresgästkonfiguration och vilket varumärke som ska laddas. Den säger ingenting om huruvida anroparen får se den hyresgästens data. Håll den andra frågan i en separat funktion med en separat indata.

En delad hjälpfunktion som returnerar både kontext och behörighet från en enda värdnamnssökning är början på felet.

Sedan: medlemskap kommer från sessionen

Slå upp den autentiserade användarens aktiva medlemskap och jämför dem med hyresgästen från den första kontrollen. En användare som tillhör båda klinikerna får byta, men bytet bör vara en uttrycklig handling som registreras i begärans kontext, inte en slutsats från URL:en. En användare som tillhör en klinik och begär den andra nekas, även för nedladdningar och API-anrop.

Testa det negativa fallet genom att ändra en postidentifierare och en hyresgästparameter. Om någon av ändringarna returnerar data läses omfattningen från begäran och inte från det verifierade medlemskapet.

Omfattningen för cookies och enkel inloggning avgör var ett konto kan presenteras. De avgör inte vad det kontot får läsa.

För det tredje: nätverket bevisar ingenting om personen

En VPN-gateway autentiserar en tunnel, och en offentlig tillåtelselista autentiserar ett adressområde. Ingen av dem identifierar en person. NAT samlar många användare i en enda källadress, och ett kontorsområde gör samma sak för alla i byggnaden. Behandla båda som transportfakta och håll auktoriseringen i applikationen, eller i en integration som uttryckligen hävdar identitet och granskas som sådan.

DNS är ett tredje transportfaktum. Ett privat svar kräver en privat rutt, och en offentlig frontend kräver en stödd ursprungsväg. Ingen av dem bär en behörighet.

En mening till väggen: nätverket avgör hur en begäran kommer in, och applikationen avgör vad den får läsa.

För det fjärde: kör matrisen på båda ingångarna

Använd kontrollerade konton för att pröva A hos A, B hos B, A hos B, ett okänt värdnamn och ett autentiserat konto utan medlemskap. Den fjärde och den femte bör misslyckas stängt och får aldrig falla tillbaka på en standardhyresgäst. Kör samma matris genom VPN-ingången också, med en sessionsburk 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

Ändra sedan en post i tillåtelselistan och kör igen. Ett resultat som flyttar sig betyder att en nätverkskontroll fattar ett auktoriseringsbeslut.

Upprepa matrisen efter varje ändring i frontend, eftersom en andra kodväg som hoppar över kontrollen är det vanligaste sättet denna gräns eroderas. Det förväntade resultatet är tråkigt: varje ingång ger samma svar.