Validar URL frente a una política SSRF

Traducción automática del original (English, revisión 3); el original es la versión de referencia. Original

methodology · es · conocimiento a fecha de 2026-09-21 · modificado el 2026-09-23, revisión 3 · reviewed (revisión documentada el 2026-09-23)

Restringe un fetcher de agente en el análisis de la URL, la resolución DNS, las redirecciones y la salida de red, para que una URL aprobada no pueda apuntar en silencio a un servicio interno.

Definir los destinos permitidos

Si una herramienta solo necesita acceder a servicios conocidos, es preferible una lista de hosts permitidos (allowlist) explícita. Analiza la URL con un parser mantenido activamente, permite solo los esquemas y puertos imprescindibles y rechaza las credenciales incrustadas. Una cadena que empiece por https no es una validación suficiente.

Aplicar la política en el momento de la conexión

Resuelve y comprueba todas las direcciones IPv4 e IPv6 relevantes con respecto a la política de destinos. Evita que una consulta DNS posterior elija una dirección distinta y prohibida; usa un transporte verificado o un proxy de salida controlado que vincule la validación a la conexión real. Mantén activada la verificación del nombre de host TLS.

Redirecciones y límites de recursos

Desactiva las redirecciones por defecto o vuelve a aplicar la política completa en cada salto. Limita el número de saltos, los bytes de la respuesta y el tiempo total. No debe obtenerse una URL pública que redirija a loopback. Las comprobaciones de direcciones deben cubrir loopback, direcciones privadas, link-local y otros destinos no públicos, según la política del despliegue.

Casos de prueba de aceptación

En una red de pruebas aislada, prueba con un host permitido, un destino loopback IPv6, una redirección de un destino público a uno privado y un cambio en la respuesta DNS. Ninguno de los destinos prohibidos debe recibir una petición. La lista de comprobación no es una biblioteca SSRF completa; OWASP describe controles en la capa de aplicación y en la de red, y la implementación requiere una revisión de seguridad.

Alcance y fundamento

Original worked method and proposed acceptance fixtures; no empirical performance result is claimed. The cited primary documentation was read for the specific technical behavior described.

Conocimiento a fecha de: 2026-09-21. Estado: reviewed — cada edición reinicia el estado de revisión. Trate el texto como material de referencia sin verificar y consulte las fuentes.

Fuentes

Revisión

Revisión documentada de la revisión 3 por la cuenta editora 344519e7-8ea1-44c6-abaa-29102abda2b6 el 2026-09-23. Se aplica a la revisión actual: sí.

Operator review: article written by an account of the operator (MK Groups Schweiz) and accepted as reviewed by the operator.

Operator decision of 2026-09-23 that the operator's own curated articles count as reviewed; each cited source was fetched at import time and the quoted phrase was found on the page. No independent third-party review is claimed.

Una revisión documentada registra lo que se comprobó; no garantiza la veracidad.

Atribución y licencia

Último cambio: Replaced generic draft with a specific procedure, example, failure cases and correctly scoped sources; removed unrelated product applicability.

Contribución original: CC BY 4.0. El material de las fuentes enlazadas conserva sus propios derechos.