Liens temporaires de liste d’IP autorisées : ce que l’autorisation admet vraiment

Transformer un clic en règle de pare-feu temporaire est pratique, et cela construit aussi un système d’autorisation qui décide qui peut atteindre un service. Ce qu’il délivre est une adresse plutôt qu’une personne, et cette différence compte dès l’instant où deux personnes partagent un NAT. Délimitez la portée de l’autorisation, confirmez-la délibérément et donnez un sens à l’expiration avant que le lien soit construit. La décision devant vous est où placer la frontière, non si elle doit exister.

Décidez à quelle question l’autorisation répond

Partez de l’exigence. Si une personne nommée doit atteindre le service et que l’application authentifie déjà cette personne, une passerelle authentifiée conserve l’identité au point d’application et n’a besoin d’aucune admission par adresse. Si la cible est un agent de compilation, un port de saut administratif ou un appareil qui ne peut pas participer à la connexion de l’utilisateur, une autorisation d’adresse à portée limitée peut être le seul contrôle pratique disponible.

Choisir l’admission par adresse pour une application destinée aux utilisateurs déplace le vrai problème d’autorisation ailleurs, et le portail hérite alors du blâme pour un trou qu’il n’a jamais fermé.

Bornez la requête sur le serveur

Le navigateur ne doit pas choisir la destination, le port ni le préfixe. Le portail résout le service à partir de ses propres données et vérifie le droit par un test côté serveur, ce qui est le même principe que le guide d’autorisation de l’OWASP applique à chaque requête. La dérivation de l’adresse relève aussi de la frontière protégée : lorsqu’un proxy inverse signale l’adresse du client, n’acceptez que la chaîne de proxies configurée et son traitement documenté des en-têtes. Un en-tête de transfert fourni par un visiteur est une affirmation sur la provenance, non une preuve de celle-ci.

Vérifiez ensuite que le portail et le service observent la même source. Le tunnel divisé, un saut de proxy et IPv4 face à IPv6 peuvent donner à deux destinations deux adresses différentes, si bien qu’une autorisation activée par un chemin peut ne pas couvrir la requête suivante.

Montrez l’autorisation avant de l’installer

Ouvrir un lien devrait afficher le service proposé, la source observée et la durée, et ne rien changer encore. Cette seule étape transforme le lien reçu par courriel d’une action en une proposition, et elle empêche un robot d’aperçu ou un analyseur de courrier d’accorder l’accès simplement en le récupérant.

La confirmation devrait être une requête qui change l’état, avec les défenses habituelles contre les sites croisés et l’origine. Le jeton devrait être à usage unique et consommé atomiquement au moment où la règle est installée, et l’enregistrement devrait saisir le propriétaire, le service, l’adresse, l’identifiant de l’autorisation et l’expiration sans jamais journaliser le jeton brut.

La livraison du jeton mérite le même soin que la règle elle-même. Un lien expiré ou déjà consommé qui produit encore une règle est une seconde porte équipée de la même clé.

L’adresse est partagée même pendant la vie de l’autorisation

Un NAT de bureau, un NAT d’opérateur et une sortie VPN partagée placent chacun plusieurs personnes derrière une adresse. Admettre cette adresse admet tous ceux qui sont derrière — pour ce qui concerne la frontière suivante du service —, sans rien prouver sur qui détient le compte que le service attend.

Retirer la règle n’est pas non plus une déconnexion universelle. Les connexions établies, les jetons d’application en cache et les sessions de longue durée peuvent survivre à la règle quelques minutes ou bien plus longtemps, donc la durée de vie que vous choisissez devrait refléter ce que fait le service après l’admission, et pas seulement combien de temps la règle existe.

Testez quatre cas et les deux familles d’adresses

Une autorisation ne vaut que ce que valent les quatre cas qu’elle survit : une requête nouvelle autorisée, un demandeur non approuvé, un rejeu du même lien et la même requête après expiration.

Testez ensuite chaque famille séparément, car l’adresse source que le service observe peut différer entre elles.

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

Le résultat utile est une décision d’admission temporaire et auditable placée sous l’autorisation normale de l’utilisateur, plutôt qu’une ouverture permanente portant le nom de celui qui a cliqué le premier.