Subdominis compartits, dues entrades: qui veu quins registres?

La Clínica A i la Clínica B comparteixen una base de codi, dos subdominis i una barreja de visitants d’oficina i de VPN. Els equips de xarxa solen configurar les dues entrades per separat, i això està bé, sempre que l’aplicació no ho faci. Les comprovacions següents pertanyen a l’aplicació i han de comportar-se igual sigui quina sigui la porta que ha fet servir la petició.

Primer: el nom d’amfitrió només anomena un llogater

Resoleu el nom d’amfitrió sol·licitat contra un mapatge que manté l’administrador i rebutgeu qualsevol cosa desconeguda. Feu servir el valor d’amfitrió validat pel marc de treball en lloc de la capçalera crua, perquè un Host fabricat no pugui injectar una clau de consulta. Una coincidència correcta diu al codi quina configuració de llogater i quina imatge de marca ha de carregar. No diu res sobre si el sol·licitant pot veure les dades d’aquell llogater. Manteniu aquest segon interrogant en una funció separada amb una entrada separada.

Una funció auxiliar compartida que retorna alhora el context i el permís a partir d’una sola consulta de nom d’amfitrió és el començament de l’error.

Segon: la pertinença ve de la sessió

Cerqueu les pertinences actives de l’usuari autenticat i compareu-les amb el llogater de la primera comprovació. Un usuari que pertany a les dues clíniques pot canviar, però el canvi ha de ser una acció explícita enregistrada en el context de la petició, no una inferència de l’URL. Un usuari que pertany a una clínica i en demana l’altra és denegat, també per a baixades i crides d’API.

Proveu el cas negatiu editant un identificador de registre i un paràmetre de llogater. Si qualsevol dels dos canvis retorna dades, l’abast es llegeix de la petició i no de la pertinença verificada.

L’abast de les galetes i l’inici de sessió únic decideixen on es pot presentar un compte. No decideixen què pot llegir aquest compte.

Tercer: la xarxa no demostra res sobre la persona

Una passarel·la VPN autentica un túnel, i una llista d’adreces permeses pública autentica un rang d’adreces. Cap de les dues identifica una persona. El NAT ajunta molts usuaris en una sola adreça d’origen, i un rang d’oficina fa el mateix amb tothom de l’edifici. Tracteu els dos com a fets de transport i manteniu l’autorització a l’aplicació, o en una integració que afirmi la identitat explícitament i es revisi com a tal.

DNS és un tercer fet de transport. Una resposta privada necessita una ruta privada, i un frontal públic necessita un camí d’origen suportat. Cap d’ells no porta un permís.

Una frase per penjar a la paret: la xarxa decideix com arriba una petició, i l’aplicació decideix què pot llegir.

Quart: executeu la matriu a les dues entrades

Feu servir comptes controlats per exercitar A a A, B a B, A a B, un nom d’amfitrió desconegut i un compte autenticat sense pertinences. El quart i el cinquè han de fallar tancats i no han de recórrer mai a un llogater per defecte. Executeu la mateixa matriu també per l’entrada VPN, amb un pot de sessió per compte:

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

Després canvieu una entrada de la llista d’adreces permeses i torneu a executar. Un resultat que es mou vol dir que un control de xarxa està prenent una decisió d’autorització.

Repetiu la matriu després de qualsevol canvi al frontal, perquè un segon camí de codi que omet la comprovació és la manera més habitual com s’erosiona aquesta frontera. El resultat esperat és avorrit: cada entrada produeix les mateixes respostes.