Gedeelde subdomeine, twee ingange: wie sien watter rekords?

Kliniek A en Kliniek B deel een kodebasis, twee subdomeine en ’n mengsel van kantoor- en VPN-besoekers. Netwerkspanne is geneig om die twee ingange afsonderlik op te stel, en dit is heeltemal reg, solank die toepassing dit nie doen nie. Die kontroles hieronder hoort in die toepassing en moet identies werk, ongeag watter deur die versoek gebruik het.

Eerste: die hostnaam benoem net ’n huurder

Los die gevraagde hostnaam op teen ’n kartering wat die administrateur onderhou, en verwerp enigiets onbekend. Gebruik die raamwerk se gevalideerde hostwaarde in plaas van die rou kop, sodat ’n vervaardigde Host nie ’n opsoeklysleutel kan inspuit nie. ’n Suksesvolle passing sê vir die kode watter huurderkonfigurasie en handelsmerk om te laai. Dit sê niks oor of die beller daardie huurder se data mag sien nie. Hou daardie tweede vraag in ’n aparte funksie met ’n aparte inset.

’n Gedeelde helper wat beide konteks en toestemming uit een hostnaamopsoek teruggee, is die begin van die fout.

Tweede: lidmaatskap kom uit die sessie

Soek die geverifieerde gebruiker se aktiewe lidmaatskappe op en vergelyk dit met die huurder uit kontrole een. ’n Gebruiker wat aan beide klinieke behoort, mag oorskakel, maar die oorskakeling moet ’n eksplisiete handeling wees wat in die versoekkonteks aangeteken word, nie ’n afleiding uit die URL nie. ’n Gebruiker wat aan een kliniek behoort en die ander een aanvra, word geweier, ook vir aflaaie en API-oproepe.

Toets die negatiewe geval deur ’n rekordidentifiseerder en ’n huurderparameter te verander. As enige van die twee veranderinge data teruggee, word die omvang uit die versoek gelees eerder as uit die geverifieerde lidmaatskap.

Koekiebestek en enkelafmelding bepaal waar ’n rekening aangebied kan word. Hulle bepaal nie wat daardie rekening mag lees nie.

Derde: die netwerk bewys niks oor die persoon

’n VPN-grendel verifieer ’n tonnel, en ’n openbare toelaatlys verifieer ’n adresreeks. Nie een identifiseer ’n persoon nie. NAT druk baie gebruikers saam in een bronadres, en ’n kantoorreeks doen dieselfde vir almal in die gebou. Behandel albei as vervoerfeite en hou magtiging in die toepassing, of in ’n integrasie wat identiteit eksplisiet verklaar en as sodanig nagegaan word.

DNS is ’n derde vervoerfeit. ’n Privaat antwoord benodig ’n privaat roete, en ’n openbare voorkant benodig ’n ondersteunde oorsprongpad. Nie een van hulle dra ’n toestemming nie.

Een sin om teen die muur te hou: die netwerk besluit hoe ’n versoek aankom, en die toepassing besluit wat dit mag lees.

Vierde: hardloop die matriks op albei ingange

Gebruik gekontroleerde rekeninge om A by A, B by B, A by B, ’n onbekende hostnaam en ’n geverifieerde rekening sonder lidmaatskappe te toets. Die vierde en vyfde moet gesluit faal en nooit by verstek na ’n huurder teruggryp nie. Hardloop dieselfde matriks ook deur die VPN-ingang, met een sessiepot per rekening:

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

Verander dan ’n toelaatlys-inskrywing en hardloop weer. ’n Resultaat wat beweeg, beteken ’n netwerkkontrole maak ’n magtigingsbesluit.

Herhaal die matriks na enige voorkantverandering, want ’n tweede kodepad wat die kontrole oorslaan, is die mees algemene manier waarop hierdie grens afbrokkel. Die verwagte resultaat is vervelig: elke ingang lewer dieselfde antwoorde.