Bendri subdomenai, du įėjimai: kas mato kuriuos įrašus?

Klinika A ir Klinika B dalijasi viena kodo baze, dviem subdomenais ir biuro bei VPN lankytojų mišiniu. Tinklo komandos linkusios abu įėjimus konfigūruoti atskirai, ir tai gerai, kol programa to nedaro. Toliau pateiktos patikros priklauso programai ir turėtų elgtis vienodai, nesvarbu, kurias duris naudojo užklausa.

Pirma: hosto vardas tik įvardija nuomininką

Išspręskite prašomą hosto vardą pagal administratoriaus palaikomą atvaizdavimą ir atmeskite viską, kas nežinoma. Naudokite karkaso patvirtintą hosto reikšmę, o ne neapdorotą antraštę, kad suklastotas Host negalėtų įterpti paieškos rakto. Sėkmingas atitikimas pasako kodui, kurią nuomininko konfigūraciją ir kurį prekės ženklą įkelti. Jis nieko nesako apie tai, ar kvietėjas gali matyti to nuomininko duomenis. Laikykite šį antrą klausimą atskiroje funkcijoje su atskiru įėjimu.

Bendra pagalbinė funkcija, kuri iš vienos hosto vardo paieškos grąžina ir kontekstą, ir leidimą, yra klaidos pradžia.

Antra: narystė ateina iš sesijos

Raskite autentifikuoto vartotojo aktyvias narystes ir palyginkite jas su nuomininku iš pirmos patikros. Vartotojas, priklausantis abiem klinikoms, gali persijungti, bet persijungimas turi būti aiškus veiksmas, įrašytas užklausos kontekste, o ne išvada iš URL. Vartotojui, priklausančiam vienai klinikai ir prašančiam kitos, atsisakoma, įskaitant atsisiuntimus ir API kvietimus.

Išbandykite neigiamą atvejį pakeisdami įrašo identifikatorių ir nuomininko parametrą. Jei bent vienas pakeitimas grąžina duomenis, apimtis skaitoma iš užklausos, o ne iš patvirtintos narystės.

Slapukų apimtis ir vienkartinis prisijungimas nusprendžia, kur paskyrą galima pateikti. Jie nenusprendžia, ką ta paskyra gali skaityti.

Trečia: tinklas nieko neįrodo apie asmenį

VPN šliuzas autentifikuoja tunelį, o viešas leidžiamų adresų sąrašas autentifikuoja adresų diapazoną. Nė vienas neidentifikuoja asmens. NAT sutraukia daug vartotojų į vieną šaltinio adresą, o biuro diapazonas daro tą patį visiems pastate. Traktuokite abu kaip transporto faktus ir laikykite autorizaciją programoje arba integracijoje, kuri aiškiai deklaruoja tapatybę ir yra atitinkamai peržiūrima.

DNS yra trečias transporto faktas. Privatus atsakymas reikalauja privataus maršruto, o viešas priedas reikalauja palaikomo kilmės kelio. Nė vienas jų neneša leidimo.

Vienas sakinys ant sienos: tinklas nusprendžia, kaip užklausa atvyksta, o programa nusprendžia, ką ji gali skaityti.

Ketvirta: paleiskite matricą abiem įėjimais

Naudokite kontroliuojamas paskyras, kad išbandytumėte A prie A, B prie B, A prie B, nežinomą hosto vardą ir autentifikuotą paskyrą be narysčių. Ketvirtoji ir penktoji turi nepavykti uždarai ir niekada neturi nusiristi iki numatytojo nuomininko. Paleiskite tą pačią matricą ir per VPN įėjimą, su vienu sesijos stiklainiu kiekvienai paskyrai:

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

Tada pakeiskite vieną leidžiamų adresų sąrašo įrašą ir paleiskite iš naujo. Rezultatas, kuris pasislenka, reiškia, kad tinklo kontrolė priima autorizacijos sprendimą.

Kartokite matricą po bet kurio priedo pakeitimo, nes antras kodo kelias, praleidžiantis patikrą, yra dažniausias būdas, kuriuo ši riba eroduoja. Laukiamas rezultatas nuobodus: kiekvienas įėjimas duoda tuos pačius atsakymus.