Ligazóns temporais de listas de IP permitidas: que admite realmente a concesión

Converter un clic nunha regra temporal da devasa é cómodo, e ademais constrúe un sistema de autorización que decide quen pode chegar a un servizo. O que emite é un enderezo en lugar dunha persoa, e esa diferenza importa no momento en que dúas persoas comparten un NAT. Limite o alcance da concesión, confírmaa de forma deliberada e faga que a caducidade signifique algo antes de construír a ligazón. A decisión que ten diante é onde poñer a fronteira, non se debería existir unha.

Decida a que pregunta responde a concesión

Comece polo requisito. Se unha persoa concreta debe chegar ao servizo e a aplicación xa autentica esa persoa, unha pasarela autenticada mantén a identidade no punto de aplicación e non necesita ningunha admisión por enderezo. Se o obxectivo é un axente de compilación, un porto de salto administrativo ou un dispositivo que non pode participar no inicio de sesión de usuarios, unha concesión de enderezo de alcance limitado pode ser o único control práctico dispoñible.

Escoller a admisión por enderezo para unha aplicación orientada a usuarios traslada o problema real de autorización a outro lugar, e entón o portal herda a culpa dunha fenda que nunca pechou.

Limite a solicitude no servidor

O navegador non debe escoller o destino, o porto nin o prefixo. O portal resolve o servizo a partir dos seus propios rexistros e comproba o dereito cunha proba no lado do servidor, que é o mesmo principio que a guía de autorización de OWASP aplica a cada solicitude. A derivación do enderezo tamén pertence á fronteira protexida: cando un proxy inverso informa do enderezo do cliente, acepte só a cadea de proxies configurada e o seu tratamento documentado das cabeceiras. Unha cabeceira de reenvío proporcionada por un visitante é unha afirmación sobre a procedencia, non unha proba dela.

Despois comprobe que o portal e o servizo observan a mesma fonte. O túnel dividido, un salto de proxy e IPv4 fronte a IPv6 poden dar a dous destinos dous enderezos distintos, así que unha concesión activada por un camiño pode non cubrir a solicitude seguinte.

Mostre a concesión antes de instalala

Abrir unha ligazón debería amosar o servizo proposto, a fonte observada e a duración, e aínda non cambiar nada. Ese único paso converte a ligazón do correo dunha acción nunha proposta, e evita que un bot de vista previa ou un escáner de correo concedan acceso só por obtela.

A confirmación debería ser unha solicitude que cambia o estado coas defensas habituais contra sitios cruzados e de orixe. O token debería ser dun só uso e consumirse de forma atómica no momento en que se instala a regra, e o rexistro debería recoller o propietario, o servizo, o enderezo, o identificador da concesión e a caducidade sen rexistrar nunca o token en bruto.

A entrega do token merece o mesmo coidado que a propia regra. Unha ligazón caducada ou xa consumida que aínda produce unha regra é unha segunda porta equipada coa mesma chave.

O enderezo compártese mesmo mentres a concesión vive

Un NAT de oficina, un NAT de operador e unha saída de VPN compartida colocan cada un varias persoas detrás dun enderezo. Admitir ese enderezo admite a todos os que están detrás —polo que respecta á seguinte fronteira do servizo—, sen demostrar nada sobre quen ten a conta que o servizo espera.

Retirar a regra tampouco é unha desconexión universal. As conexións establecidas, os tokens de aplicación en caché e as sesións de longa duración poden sobrevivir á regra minutos ou moito máis, así que a vida útil que escolla debería reflectir que fai o servizo despois da admisión e non só canto tempo existe a regra.

Probe catro casos e ambas as familias de enderezos

Unha concesión vale tanto como os catro casos que supera: unha solicitude nova permitida, un solicitante non aprobado, unha repetición da mesma ligazón e a mesma solicitude despois da caducidade.

Despois probe cada familia por separado, porque o enderezo de orixe que observa o servizo pode diferir entre elas.

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

O resultado útil é unha decisión de admisión temporal e auditable baixo a autorización normal de usuario, en lugar dunha apertura permanente que leve o nome de quen fixo clic primeiro.