Jaetut aliverkkotunnukset, kaksi sisäänkäyntiä: kuka näkee mitkä tietueet?

Klinikka A ja Klinikka B jakavat yhden koodikannan, kaksi aliverkkotunnusta sekä sekoituksen toimistosta ja VPN:n kautta tulevia vierailijoita. Verkkotiimit yleensä määrittävät kaksi sisäänkäyntiä erikseen, ja se on aivan hyvä, kunhan sovellus ei tee niin. Alla olevat tarkistukset kuuluvat sovellukseen ja niiden pitäisi toimia samalla tavalla riippumatta siitä, mitä ovea pyyntö käytti.

Ensimmäinen: isäntänimi nimeää vain vuokralaisen

Selvitä pyydetty isäntänimi ylläpitäjän ylläpitämää kuvautta vasten ja hylkää kaikki tuntematon. Käytä kehyksen validoimaa isäntäarvoa raa'an otsakkeen sijaan, jotta väärennetty Host ei voi syöttää hakukoodia. Onnistunut vastaavuus kertoo koodille, mikä vuokralaisen kokoonpano ja brändäys ladataan. Se ei kerro mitään siitä, saako kutsuja nähdä kyseisen vuokralaisen tietoja. Pidä tuo toinen kysymys erillisessä funktiossa erillisellä syötteellä.

Jaettu apufunktio, joka palauttaa sekä kontekstin että luvan yhdestä isäntänimen hausta, on virheen alku.

Toinen: jäsenyys tulee istunnosta

Hae todennetun käyttäjän aktiiviset jäsenyydet ja vertaa niitä ensimmäisen tarkistuksen vuokralaiseen. Käyttäjä, joka kuuluu molempiin klinikoihin, voi vaihtaa, mutta vaihdon pitäisi olla pyynnön kontekstiin kirjattu nimenomainen toiminto, ei URL:sta tehty päätelmä. Käyttäjältä, joka kuuluu yhteen klinikkaan ja pyytää toista, evätään pääsy, myös latauksilta ja API-kutsuilta.

Testaa kielteinen tapaus muokkaamalla tietueen tunnistetta ja vuokralaisen parametria. Jos jompikumpi muutos palauttaa tietoja, laajuus luetaan pyynnöstä eikä vahvistetusta jäsenyydestä.

Evästeiden laajuus ja kertakirjautuminen päättävät, missä tili voidaan esittää. Ne eivät päätä, mitä tili saa lukea.

Kolmas: verkko ei todista mitään henkilöstä

VPN-yhdyskäytävä todentaa tunnelin ja julkinen sallittujen luettelo todentaa osoitealueen. Kumpikaan ei tunnista henkilöä. NAT tiivistää monet käyttäjät yhteen lähiosoitteeseen, ja toimistoalue tekee saman kaikille rakennuksessa. Kohtele molempia kuljetustosiasioina ja pidä valtuutus sovelluksessa tai integraatiossa, joka ilmoittaa identiteetin nimenomaisesti ja jota tarkastellaan sellaisena.

DNS on kolmas kuljetustosiasia. Yksityinen vastaus tarvitsee yksityisen reitin, ja julkinen etupää tarvitsee tuetun alkuperäpolun. Kukaan niistä ei kanna lupaa.

Yksi lause seinälle: verkko päättää, miten pyyntö saapuu, ja sovellus päättää, mitä se saa lukea.

Neljäs: aja matriisi molemmilla sisäänkäynneillä

Käytä valvottuja tilejä harjoitellaksesi A:ta A:ssa, B:tä B:ssä, A:ta B:ssä, tuntematonta isäntänimeä ja todennettua tiliä ilman jäsenyyksiä. Neljännen ja viidennen pitäisi epäonnistua suljetusti eikä koskaan pudota oletusvuokralaiseen. Aja sama matriisi myös VPN-sisäänkäynnin kautta yhdellä istuntopurkilla per tili:

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

Muuta sitten sallittujen luettelon merkintää ja aja uudelleen. Tulos, joka liikkuu, tarkoittaa, että verkkokontrolli tekee valtuutuspäätöksen.

Toista matriisi jokaisen etupäämuutoksen jälkeen, koska toinen koodipolku, joka ohittaa tarkistuksen, on yleisin tapa, jolla tämä raja rapautuu. Odotettu tulos on tylsä: jokainen sisäänkäynti tuottaa samat vastaukset.