Link temporanei degli elenchi di IP consentiti: che cosa ammette davvero la concessione

Trasformare un clic in una regola temporanea del firewall è comodo, e costruisce anche un sistema di autorizzazione che decide chi può raggiungere un servizio. Ciò che rilascia è un indirizzo anziché una persona, e quella differenza conta nel momento in cui due persone condividono un NAT. Delimitate l’ambito della concessione, confermatela deliberatamente e date un senso alla scadenza prima che il link venga costruito. La decisione davanti a voi è dove collocare il confine, non se debba esisterne uno.

Decidete a quale domanda risponde la concessione

Partite dal requisito. Se una persona nominata deve raggiungere il servizio e l’applicazione autentica già quella persona, un gateway autenticato mantiene l’identità nel punto di applicazione e non ha affatto bisogno di un’ammissione per indirizzo. Se l’obiettivo è un agente di build, una porta di salto amministrativa o un’appliance che non può partecipare all’accesso dell’utente, una concessione di indirizzo con ambito limitato può essere l’unico controllo praticabile disponibile.

Scegliere l’ammissione per indirizzo per un’applicazione rivolta agli utenti sposta il vero problema di autorizzazione altrove, e il portale eredita poi la colpa di una lacuna che non ha mai chiuso.

Limitate la richiesta sul server

Il browser non deve scegliere la destinazione, la porta o il prefisso. Il portale risolve il servizio dai propri registri e verifica il diritto con una prova lato server, che è lo stesso principio che le linee guida di OWASP sull’autorizzazione applicano a ogni richiesta. Anche la derivazione dell’indirizzo appartiene al confine protetto: quando un proxy inverso segnala l’indirizzo del client, accettate solo la catena di proxy configurata e la sua gestione documentata delle intestazioni. Un’intestazione di inoltro fornita da un visitatore è un’asserzione sulla provenienza, non una prova della stessa.

Poi verificate che il portale e il servizio osservino la stessa origine. Il tunneling diviso, un salto di proxy e IPv4 rispetto a IPv6 possono dare a due destinazioni due indirizzi diversi, perciò una concessione attivata da un percorso può non coprire la richiesta successiva.

Mostrate la concessione prima di installarla

Aprire un link dovrebbe mostrare il servizio proposto, l’origine osservata e la durata, e non cambiare ancora nulla. Quell’unico passaggio trasforma il link ricevuto via email da azione in proposta, e impedisce a un bot di anteprima o a uno scanner di posta di concedere l’accesso solo recuperandolo.

La conferma dovrebbe essere una richiesta che cambia stato con le consuete difese contro richieste cross-site e di origine. Il token dovrebbe essere monouso e consumato in modo atomico nel momento in cui la regola viene installata, e il record dovrebbe registrare proprietario, servizio, indirizzo, identificatore della concessione e scadenza senza mai registrare il token in chiaro.

La consegna del token merita la stessa cura della regola stessa. Un link scaduto o già consumato che produce ancora una regola è una seconda porta dotata della stessa chiave.

L’indirizzo è condiviso anche mentre la concessione è attiva

Un NAT aziendale, un NAT dell’operatore e un’uscita VPN condivisa mettono ciascuno più persone dietro un solo indirizzo. Ammettere quell’indirizzo ammette tutti quelli che stanno dietro — per quanto riguarda il confine successivo del servizio —, senza dimostrare nulla su chi possiede l’account che il servizio si aspetta.

Rimuovere la regola non è nemmeno una disconnessione universale. Le connessioni stabilite, i token applicativi in cache e le sessioni di lunga durata possono sopravvivere alla regola per minuti o molto più a lungo, quindi la durata che scegliete dovrebbe riflettere ciò che il servizio fa dopo l’ammissione e non solo quanto a lungo esiste la regola.

Provate quattro casi e entrambe le famiglie di indirizzi

Una concessione vale quanto i quattro casi che supera: una richiesta nuova consentita, un richiedente non approvato, una ripetizione dello stesso link e la stessa richiesta dopo la scadenza.

Poi provate ciascuna famiglia separatamente, perché l’indirizzo di origine che il servizio osserva può differire tra loro.

dig +short A service.example.com
dig +short AAAA service.example.com
curl -4 -sS -o /dev/null -w "%{http_code}\n" https://service.example.com
curl -6 -sS -o /dev/null -w "%{http_code}\n" https://service.example.com

Il risultato utile è una decisione di ammissione temporanea e verificabile sotto la normale autorizzazione utente, invece di un’apertura permanente che porti il nome di chi ha cliccato per primo.