Sottodomini condivisi, due ingressi: chi vede quali cartelle?

La Clinica A e la Clinica B condividono una base di codice, due sottodomini e un misto di visitatori dall’ufficio e tramite VPN. I team di rete tendono a configurare i due ingressi separatamente, e va bene, purché l’applicazione non lo faccia. I controlli qui sotto appartengono all’applicazione e devono comportarsi allo stesso modo indipendentemente dalla porta usata dalla richiesta.

Primo: il nome host nomina solo un inquilino

Risolvete il nome host richiesto rispetto a una mappatura mantenuta dall’amministratore e rifiutate tutto ciò che è sconosciuto. Usate il valore host convalidato dal framework invece dell’intestazione grezza, così un Host contraffatto non può iniettare una chiave di ricerca. Una corrispondenza riuscita dice al codice quale configurazione dell’inquilino e quale marchio caricare. Non dice nulla sulla possibilità, per il chiamante, di vedere i dati di quell’inquilino. Tenete questa seconda domanda in una funzione separata con un input separato.

Una funzione ausiliaria condivisa che restituisce sia il contesto sia l’autorizzazione da un’unica ricerca del nome host è l’inizio del difetto.

Secondo: l’appartenenza viene dalla sessione

Cercate le appartenenze attive dell’utente autenticato e confrontatele con l’inquilino del primo controllo. Un utente che appartiene a entrambe le cliniche può cambiare, ma il cambio deve essere un’azione esplicita registrata nel contesto della richiesta, non un’inferenza dall’URL. Un utente che appartiene a una clinica e chiede l’altra viene negato, anche per download e chiamate API.

Provate il caso negativo modificando un identificatore di cartella e un parametro dell’inquilino. Se una delle due modifiche restituisce dati, l’ambito viene letto dalla richiesta e non dall’appartenenza verificata.

L’ambito dei cookie e l’accesso unico decidono dove un account può essere presentato. Non decidono cosa quell’account può leggere.

Terzo: la rete non dimostra nulla sulla persona

Un gateway VPN autentica un tunnel, e una lista di indirizzi consentiti pubblica autentica un intervallo di indirizzi. Nessuno dei due identifica una persona. NAT raggruppa molti utenti in un unico indirizzo di origine, e un intervallo di ufficio fa lo stesso per tutti quelli dell’edificio. Trattate entrambi come fatti di trasporto e tenete l’autorizzazione nell’applicazione, o in un’integrazione che afferma esplicitamente l’identità ed è esaminata come tale.

DNS è un terzo fatto di trasporto. Una risposta privata richiede una rotta privata, e un frontend pubblico richiede un percorso di origine supportato. Nessuno di essi porta un permesso.

Una frase da tenere al muro: la rete decide come arriva una richiesta, e l’applicazione decide cosa può leggere.

Quarto: eseguite la matrice su entrambi gli ingressi

Usate account controllati per esercitare A su A, B su B, A su B, un nome host sconosciuto e un account autenticato senza appartenenze. Il quarto e il quinto devono fallire chiusi e non devono mai ricadere su un inquilino predefinito. Eseguite la stessa matrice anche attraverso l’ingresso VPN, con un barattolo di sessione per account:

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

Poi modificate una voce della lista degli indirizzi consentiti ed eseguite di nuovo. Un risultato che si sposta significa che un controllo di rete sta prendendo una decisione di autorizzazione.

Ripetete la matrice dopo ogni modifica al frontend, perché un secondo percorso di codice che salta il controllo è il modo più comune in cui questo confine si erode. Il risultato atteso è noioso: ogni ingresso produce le stesse risposte.