Lista de destinos permitidos frente a lista negada

Una lista negada tiene que acertar con todas las formas de nombrar un destino que no queremos; una lista de permitidos solo tiene que acertar con los pocos destinos que sí queremos. La diferencia es que la primera depende de lo que el autor haya imaginado, y la segunda depende de lo que el negocio necesita, que es una lista corta y conocida.

Hay un segundo problema, más terco: una red interna cambia sin avisar al código. Un servicio nuevo, un rango nuevo, un nombre nuevo. La lista negada se queda escrita donde estaba. La guía de prevención de OWASP para esta debilidad y la entrada API7 de su Top 10 de APIs coinciden en el mismo orden: permitir esquema, destino y puerto concretos, y dejar la lista negada como último recurso.

Abre el laboratorio. DestinoPermitido.php compara el texto de la dirección contra una lista de cosas prohibidas. pruebas-filtro.txt tiene la batería que corrió plataforma en su entorno aislado, con la decisión del filtro y la dirección a la que terminó conectando el cliente. mapa-red.txt dice qué hay en cada rango.

Busca entre los destinos permitidos el que llegó al servicio de facturación interno.

Un informe que dice «el filtro es débil» no se arregla; uno que dice cuántos destinos internos lo atravesaron, sí. Cuenta los destinos de la batería que el filtro dejó pasar y que, según el mapa de red, apuntan a una red de la empresa. No cuentes los que terminaron en internet ni los que el filtro bloqueó.

Lee propuesta-permitidos.yml. No es una lista de nombres a secas: cada funcionalidad declara el esquema, el puerto y los destinos que necesita, y lo demás queda fuera por omisión. Esa forma convierte una decisión de seguridad en una decisión de producto, que es quien sabe con qué proveedores habla la aplicación.