Entrevista de Backend: ¿Cómo prevenir SSRF en un servicio de obtención de URLs?

Prompt y contexto aplicable

Diseñe la ruta de obtención segura para una API de vista previa de URLs. Un usuario autenticado envía una URL pública arbitraria HTTP o HTTPS. Un worker en segundo plano obtiene el documento y devuelve únicamente el título de la página saneado. El producto no puede mantener una lista de permitidos (allowlist) de dominios fija porque la entrada prevista son sitios web públicos.

Para esta entrevista, permita únicamente los puertos predeterminados 80 y 443, siga un máximo de tres redirecciones, aplique un tiempo límite total de tres segundos y lea un máximo de 2 MiB tras la descompresión. Estos números son supuestos de la entrevista más que configuraciones de seguridad universales. El servicio no debe alcanzar destinos de loopback, privados, compartidos, de enlace local, multidifusión, reservados, de documentación o de metadatos de la nube a través de IPv4 o IPv6. También debe resistir notaciones de IP alternativas, respuestas DNS mixtas, rebinding de DNS, URLs públicas que redirigen a direcciones internas, respuestas sobredimensionadas y servidores lentos.

MITRE define CWE-918 como un servidor que recibe una URL y la recupera sin asegurarse suficientemente de que la solicitud llegue al destino esperado. Ese marco es útil: el problema central es la autorización de salida. La validación de entrada, el comportamiento de DNS, la ruta de red y el destino real del socket deben aplicar una única política. Un debate público sobre entrevistas de seguridad web de 2026 sitúa a SSRF junto con XSS, inyección SQL e IDOR como temas que los candidatos deben estar preparados para explicar. Esto respalda la relevancia actual en entrevistas, pero no establece una pregunta fija por empresa ni una afirmación de frecuencia. OWASP Top 10:2025 clasifica CWE-918 dentro de Broken Access Control, reforzando el modelo de autorización.

El banco de preguntas existente menciona SSRF como un límite dentro de un crawler y un acortador de URLs. Esta pregunta aísla la ruta de obtención en sí misma: análisis sintáctico, resolución, clasificación de destinos, vinculación de conexiones, redirecciones, controles de salida y la prueba de que la política sobrevive a condiciones de carrera de verificación/uso (time-of-check/time-of-use).

Qué evalúa el entrevistador

La primera señal es si el candidato modela el destino como una decisión de autorización. Una comprobación de las cadenas localhost y 127.0.0.1 es incompleta. El destino puede ser un literal IPv6, una dirección IPv6 asignada a IPv4, una representación numérica alternativa, un nombre de host con respuestas tanto seguras como inseguras, un destino de redirección o un nombre cuya respuesta DNS cambie entre la validación y la conexión.

La segunda señal es la disciplina con el analizador sintáctico (parser). Las expresiones regulares y las comprobaciones de subcadenas no definen la semántica de una URL. Una respuesta sólida utiliza un único parser basado en estándares, rechaza fallos de análisis y credenciales incrustadas, permite solo esquemas HTTP explícitos y puertos esperados, y luego toma todas las decisiones de política a partir de los campos canónicos del parser. La verificación TLS sigue utilizando el nombre de host normalizado original incluso cuando el socket está fijado a una dirección IP aprobada.

La tercera señal es cerrar la brecha de rebinding de DNS. Resolver y aprobar una IP es ineficaz cuando la biblioteca HTTP realiza una segunda búsqueda DNS antes de abrir el socket. El componente de obtención (fetcher) debe conectarse a una dirección aprobada específica, o enviar la solicitud a través de un proxy de salida consciente de las políticas que lo haga. Cada redirección y reintento es un nuevo evento de autorización.

La cuarta señal es la defensa en profundidad. Un error en la aplicación debería toparse con un límite de red que no pueda enrutar hacia subredes internas o endpoints de metadatos. El worker debe tener privilegios de identidad mínimos, carecer de cookies o encabezados de autorización de usuario de contexto ambiental, contar con un parser acotado y no tener capacidad para ejecutar scripts de página ni obtener subrecursos.

La señal final es la validación falsable. Un candidato debe proponer pruebas que ejerciten formatos alternativos de dirección, registros A y AAAA mixtos, carreras de resolución repetida, redirecciones, límites de descompresión y reglas de firewall de salida. Decir "use una lista de permitidos" no resuelve esta consigna porque los dominios públicos arbitrarios son un requisito del producto; solo es apropiado para un alcance diferente, exclusivo para socios.

Preguntas para aclarar antes de responder

• ¿Los destinos son sitios públicos arbitrarios o socios conocidos? Los socios conocidos permiten una lista de permitidos exacta por esquema, host y puerto. Las vistas previas arbitrarias necesitan una política conservadora de direcciones públicas y un límite de salida impuesto por la red.
• ¿Qué protocolos, puertos, métodos y encabezados son necesarios? Este ejercicio solo permite GET sobre HTTP en el puerto 80 o HTTPS en el puerto 443. No acepta métodos seleccionados por el llamante, cuerpos de solicitud, proxies, cookies, encabezados de autorización ni encabezados arbitrarios.
• ¿Se requieren redirecciones? Sí, hasta tres saltos. El servicio deshabilita las redirecciones automáticas y autoriza de forma independiente cada destino de Location antes de seguirlo.
• ¿Qué salida se necesita? Solo un título saneado. El worker no devuelve HTML sin procesar, no ejecuta JavaScript, no procesa entidades externas XML, no renderiza imágenes ni obtiene hojas de estilo, fuentes o scripts.
• ¿Qué espacio de direcciones es alcanzable desde el worker? La respuesta debe cubrir IPv4, IPv6, rutas de red de contenedores y servicios, redes corporativas y endpoints de metadatos del proveedor. Se necesita un inventario antes de poder probar la política de salida.
• ¿Cómo deben comportarse la caché y los reintentos? Una vista previa en caché puede reducir las descargas repetidas, pero los fallos de caché siguen atravesando la ruta segura. Este diseño no reintenta automáticamente. Un reintento explícito repite la resolución DNS, la autorización y la fijación de la conexión desde el principio.
• ¿Qué compensación de disponibilidad es aceptable? Rechazar un nombre de host cuando cualquier dirección devuelta sea insegura puede bloquear un sitio público mal configurado. La consigna opta por la seguridad sobre la accesibilidad parcial; el rechazo es observable y no selecciona silenciosamente otra respuesta.

Estructura de respuesta de 30 segundos

"Modelaría el análisis con un parser de URLs basado en estándares, permitiría únicamente HTTP en el puerto 80 o HTTPS en el puerto 443, y rechazaría credenciales. Resolvería cada respuesta A y AAAA mediante un resolvedor de confianza, normalizaría IPv6 asignado a IPv4 y rechazaría el destino si alguna dirección queda fuera de una política de direcciones públicas mantenida. El worker se conecta directamente a una IP aprobada pero conserva el nombre de host para Host, TLS SNI y la verificación de certificados, cerrando la brecha de rebinding de DNS. Las redirecciones automáticas y los reintentos se mantienen desactivados; cada redirección repite la verificación completa. Un firewall de salida aislado bloquea rutas internas y de metadatos. Luego aplico los límites de tres segundos, 2 MiB y tres saltos, no cargo subrecursos y pruebo el rebinding y la redirección a metadatos de extremo a extremo".

Análisis detallado paso a paso

Paso 1: Convertir el requisito en una política de destino única

Represente la política explícitamente en lugar de distribuir comprobaciones de cadenas a través de la API, el worker y el cliente HTTP:

DestinationPolicy
  schemes: http, https
  origin_pairs: http:80, https:443
  userinfo: forbidden
  address_requirement: globally reachable public unicast
  redirects: at most 3, authorize every hop
  method: GET
  caller_headers: none
  total_deadline: 3 seconds
  decompressed_body_limit: 2 MiB

La API autentica al llamante, aplica cuotas de cuenta e inquilino, almacena la cadena enviada como datos no confiables y encola un trabajo. No realiza una "comprobación de seguridad" para pasar un indicador confiable a un worker posterior; el DNS y las rutas pueden cambiar antes de que se ejecute el trabajo. El worker es el componente que abre la conexión, por lo que toma la decisión autoritativa inmediatamente antes de conectarse.

Para una integración con socios, la política más sólida es una lista de permitidos exacta con esquema, nombre de host y puerto normalizados, opcionalmente con las rutas esperadas. Este producto de vista previa acepta intencionalmente hosts públicos arbitrarios. Por lo tanto, su política permite solo destinos clasificados como públicos y alcanzables globalmente. Mantenga el clasificador a partir de registros de direcciones autoritativos y del propio inventario de red de la organización. Una lista escrita a mano que contenga solo rangos RFC 1918 pasa por alto loopback, enlace local, compartidos, multidifusión, reservados, documentación, direcciones IPv6 locales únicas, formas asignadas a IPv4 y endpoints de metadatos específicos del proveedor.

Paso 2: Analizar primero y tomar decisiones de política a partir de los campos analizados

Utilice el analizador de URLs de la plataforma compatible con WHATWG o equivalentemente probado. Exija una URL absoluta. Rechace errores de análisis, componentes de nombre de usuario o contraseña, fragmentos si el producto no tiene motivos para conservarlos, esquemas que no sean HTTP y puertos fuera de la política explícita. Normalice el nombre de host a través del parser, incluidos los nombres internacionalizados, y nunca reinterprete por separado la cadena sin procesar con una expresión regular.

Ejemplos como https://expected.example@evil.example/ demuestran por qué la coincidencia de prefijos es insegura: el host de red es evil.example. Un fragmento no selecciona el destino de red, y las codificaciones o formas numéricas alternativas pueden crear discrepancias entre un validador y un cliente HTTP. Un solo parser debe proporcionar el esquema, el host canónico, el puerto efectivo y la ruta de solicitud utilizados por cada paso posterior.

Si el host es un literal IP, canonicalícelo y clasifíquelo de inmediato. Convierta IPv6 asignado a IPv4 a su valor IPv4 incrustado antes de aplicar las políticas de ambas familias. No infiera la seguridad a partir de la puntuación, la longitud de la cadena o si el host "parece" un dominio.

Paso 3: Resolver cada dirección y vincular la conexión a un resultado aprobado

Para un nombre de host, resuelva tanto los registros A como AAAA con un resolvedor controlado. Siga el procesamiento normal de CNAME del resolvedor y recopile las direcciones finales. Esta consigna rechaza el destino si alguna respuesta no está permitida. Cada dirección pasa por el mismo clasificador que un literal IP. Registre un código de motivo, no la URL completa con la consulta, al rechazarla.

El invariante crítico es:

the IP authorized by policy == the IP used by connect()

Elija una dirección aprobada y proporcione esa dirección exacta a la capa de sockets. Conserve el nombre de host normalizado para el encabezado Host de HTTP y, para HTTPS, para TLS SNI y la verificación del nombre de host del certificado. Un certificado válido para la IP numérica no es un sustituto. Deshabilite la búsqueda DNS independiente del cliente HTTP; de lo contrario, un atacante puede devolver una dirección pública durante la validación y una dirección privada durante la conexión.

Un proxy de salida consciente de las políticas puede encargarse de la resolución, clasificación y fijación de conexiones en lugar de cada worker. El worker envía la URL normalizada y la política de solicitud fija a ese proxy, no a una dirección de proxy seleccionada por el atacante. El mismo componente debe tomar la decisión de autorización y de socket, o pasar un resultado de dirección aprobada a prueba de manipulaciones a través de un límite estrictamente controlado.

Las respuestas DNS pueden rotar legítimamente, por lo que la fijación dura para un único salto de obtención, no para siempre. Un trabajo posterior, una redirección o un reintento explícito vuelven a resolver y autorizar. La reutilización de conexiones en un pool debe indexarse por el origen y la política autorizados; nunca reutilice un socket simplemente porque una cadena de URL no confiable parezca similar.

Paso 4: Tratar cada redirección como una nueva solicitud saliente

Desactive el seguimiento automático de redirecciones. Para cada respuesta con un estado de redirección, resuelva Location contra la URL actual utilizando el mismo parser, incremente el recuento de saltos y reinicie las comprobaciones de esquema, puerto, userinfo, DNS, dirección y conexión. Rechace ubicaciones faltantes o mal formadas, bucles, una cuarta redirección y cualquier salto que se resuelva en una dirección no permitida.

No reenvíe cookies del llamante, encabezados de autorización ni encabezados arbitrarios al primer host. No reenvíe credenciales establecidas en la respuesta a un origen diferente. El fetcher utiliza un User-Agent fijo y un conjunto pequeño y fijo de encabezados. Dado que el producto solo necesita un título, GET es suficiente; las redirecciones no deben transformar la operación en un POST con cuerpo controlado por el llamante.

Esto cierra una vía de evasión común: una URL pública controlada por un atacante devuelve una redirección a http://169.254.169.254/, http://127.0.0.1/ o a un servicio interno. Aprobar solo la primera URL autorizaría un destino final diferente al que realmente se contacta.

Paso 5: Hacer que la red rechace lo que el código de la aplicación omita

Ejecute los workers de obtención en un segmento de red o espacio de nombres dedicado. Su firewall de salida permite DNS solo hacia el resolvedor controlado y HTTP/HTTPS solo a través del proxy consciente de políticas o la ruta pública aprobada. Deniega escapes de loopback, rangos de servicios internos, redes de clústeres, redes corporativas, espacio de enlace local y endpoints de metadatos en la nube para ambas familias de IP. Valide las rutas efectivas, no solo las reglas escritas.

La identidad de servicio del worker tiene únicamente los permisos necesarios para leer y completar trabajos de vista previa. Evite colocar credenciales amplias de la nube en su entorno. En EC2, deshabilitar los metadatos de instancia cuando no se usan o exigir IMDSv2 reduce la exposición; AWS documenta tanto el endpoint de metadatos IPv4 169.254.169.254 como el endpoint opcional IPv6. Estos controles añaden defensa en profundidad y no hacen que la política de URLs sea opcional.

Utilice un grupo de workers separado del de los clientes internos de webhooks o administración. Un helper HTTP genérico que pueda alcanzar servicios privados no debería procesar también URLs no confiables. Los intentos denegados por la red, incluidos los destinos de metadatos, deben generar métricas y alertas sin exponer la topología interna al llamante.

Paso 6: Limitar la obtención y analizar únicamente el artefacto prometido

Aplique límites de tiempo independientes para DNS, conexión, primer byte, lectura inactiva y un plazo total de tres segundos. Transmita la respuesta por flujo (streaming) y deténgase tras 2 MiB de contenido descomprimido; un límite exclusivo sobre el cuerpo comprimido permite bombas de descompresión. Acepte únicamente los tipos de contenido necesarios para un título HTML. Limite la concurrencia por cuenta y globalmente para que múltiples servidores públicos lentos no consuman todos los workers.

No reintente automáticamente. Un reintento crea otra autorización de salida y puede multiplicar la carga. Si los requisitos del producto añaden reintentos más adelante, cada intento debe comenzar desde el análisis y la resolución, manteniéndose dentro del presupuesto total del trabajo.

El parser trata el cuerpo como hostil. No ejecuta JavaScript, no resuelve entidades externas XML, no carga imágenes, hojas de estilo, fuentes, iframes ni scripts, ni sigue instrucciones de actualización de metadatos. Extraiga el título con un parser acotado en flujo o aislado, normalícelo como texto, limite su longitud y devuelva únicamente ese valor. Mantenga el HTML sin procesar fuera de la respuesta de la API y aplique escape al título en el destino final de renderizado.

Paso 7: Observar las decisiones y probar el invariante a nivel de socket

Registre el resultado del trabajo, el host normalizado o una clave de host que preserve la privacidad, el esquema, el puerto efectivo, la clase de dirección seleccionada, el recuento de redirecciones, los bytes, la duración y un código de motivo de denegación estable. No registre la URL completa, la cadena de consulta, userinfo, el cuerpo de la respuesta ni la carga útil de DNS, ya que las URLs pueden contener secretos. Rastree las tasas de denegación para reglas de direcciones privadas, enlace local, metadatos, esquema, puerto, redirección, tamaño, tiempo de espera y tipo de contenido.

Realice pruebas a través del resolvedor, proxy, firewall y cliente HTTP reales. Incluya:

• variantes de loopback como 127.1, IPv6 ::1 e IPv6 asignado a IPv4;
• direcciones privadas, compartidas, de enlace local, multidifusión, reservadas, de documentación y de metadatos;
• dominios con una respuesta pública y una privada, además de registros A y AAAA combinados;
• un resolvedor que devuelve una dirección pública durante la validación y una privada en la siguiente búsqueda;
• un endpoint público que redirige a cada familia de direcciones denegada y uno que realiza cuatro saltos en bucle;
• credenciales incrustadas, hosts codificados, esquemas que no son HTTP, puertos prohibidos y URLs mal formadas;
• encabezados lentos, cuerpos estancados, cuerpos descomprimidos sobredimensionados y bombas comprimidas;
• una página HTML cuyo script o imagen apunte a un host interno;
• una página HTTPS pública válida cuyo socket esté fijado mientras TLS verifica el nombre de host original;
• una elusión deliberada de la política de la aplicación que el firewall de salida siga bloqueando.

La prueba de rebinding de DNS debe fallar si el cliente realiza una segunda búsqueda. La prueba positiva de TLS debe fallar si la verificación del certificado apunta accidentalmente a la IP numérica. Juntas demuestran que la validación y la conexión utilizan la identidad prevista.

Respuesta de muestra de alta calidad

"Modelaría la prevención de SSRF como una autorización de salida realizada por el componente que abre el socket. La API autentica y limita la tasa del llamante, almacena la URL como entrada no confiable y encola un trabajo. El worker de obtención la analiza con un parser basado en estándares, rechaza userinfo, esquemas que no sean HTTP y puertos que no sean 80 y 443, y toma el host canónico y la ruta únicamente de ese parser.

Para un literal IP, lo canonicalizo, desenvuelvo IPv6 asignado a IPv4 y aplico un clasificador de direcciones públicas mantenido. Para un nombre de host, resuelvo todas las respuestas A y AAAA a través de un resolvedor controlado y rechazo todo el destino si algún resultado es privado, loopback, compartido, enlace local, multidifusión, reservado, de documentación, metadatos o queda fuera de la política. Luego me conecto directamente a una IP aprobada mientras conservo el nombre de host original para Host, TLS SNI y la verificación de certificados. Eso elimina la ventana de la segunda búsqueda DNS que utilizan los ataques de rebinding.

Las redirecciones automáticas y los reintentos están deshabilitados. Para un máximo de tres redirecciones, analizo la nueva ubicación y repito la autorización completa antes de abrir otro socket. Envío únicamente GET con encabezados fijos y sin cookies ni credenciales del llamante. Un proxy de salida o firewall dedicado deniega por separado cada ruta interna, de clúster, corporativa, de enlace local y de metadatos tanto en IPv4 como en IPv6. El worker tiene una identidad de servicio mínima y no puede utilizar un cliente HTTP interno de uso general.

Cada trabajo tiene un tiempo límite total de tres segundos y un tope de 2 MiB para el cuerpo descomprimido. El parser no ejecuta scripts ni carga subrecursos; devuelve únicamente un título saneado y limitado en longitud. Registro códigos de motivo, clase de dirección, recuento de redirecciones, bytes y latencia sin URLs completas. Mi conjunto de pruebas de aceptación incluye respuestas DNS mixtas, rebinding entre la comprobación y la conexión, IPv6 asignado a IPv4, redirección a metadatos, bombas gzip, cuerpos lentos, TLS fijado por socket y una evasión de política que la red aún debe detener".

Errores comunes

• Bloquear solo localhost y RFC 1918 → las formas alternativas de IPv4, IPv6, enlace local, compartidas, reservadas y direcciones de metadatos siguen siendo alcanzables → canonicalice y clasifique ambas familias de direcciones con una política de destinos públicos mantenida.
• Validar con expresiones regulares → el validador y el parser HTTP pueden discrepar sobre credenciales, codificación, host y puerto → utilice un único parser basado en estándares y consuma únicamente sus campos canónicos.
• Resolver, verificar y luego dejar que el cliente resuelva de nuevo → el rebinding de DNS cambia el destino del socket tras la aprobación → fije la conexión a una IP verificada mientras valida TLS contra el nombre de host.
• Aprobar solo la primera URL → un host público permitido puede redirigir a un servicio interno → deshabilite las redirecciones automáticas y vuelva a autorizar cada salto.
• Elegir la respuesta segura de resultados DNS mixtos → un cambio en la selección de direcciones puede alcanzar más adelante la respuesta insegura → rechace el nombre de host cuando cualquier dirección devuelta viole la política de esta consigna.
• Reenviar encabezados del llamante → las cookies o valores de autorización se filtran a un host seleccionado por el atacante → construya una solicitud saliente fija sin credenciales ambientales.
• Confiar únicamente en IMDSv2 o en una configuración de nube → los servicios internos y otros rangos de direcciones permanecen expuestos → combine la autorización en la aplicación, la identidad mínima, el endurecimiento de metadatos y la denegación de salida.
• Limitar solo los bytes comprimidos → un cuerpo pequeño puede expandirse hasta agotar la memoria o la CPU → limite los bytes descomprimidos, el trabajo de análisis, el tiempo y la concurrencia.
• Analizar la página como un navegador → los scripts y subrecursos crean nuevas solicitudes salientes no revisadas → extraiga únicamente el artefacto prometido con el contenido activo y la resolución de entidades externas desactivados.
• Registrar URLs completas para depuración → los secretos en las consultas y las credenciales pasan a los sistemas de observabilidad → registre campos canónicos acotados y códigos de motivo estables.

Preguntas de seguimiento

¿Qué cambia cuando cada destino es un socio conocido?

Utilice una lista de permitidos exacta de esquema, nombre de host y puerto normalizados, y configúrela mediante cambios revisados. Resuelva y clasifique la dirección de todos modos: un registro DNS comprometido o un error de configuración no debe convertir un nombre de confianza en una ruta interna. El endpoint privado de un socio corresponde a una integración autenticada separada con una ruta de red explícita, no al worker de vista previa pública.

¿Puede el servicio admitir de forma segura redirecciones entre dominios?

Sí, si las redirecciones entre dominios son un requisito del producto y cada salto repite la política completa. Elimine credenciales y estados específicos del origen, resuelva el nuevo nombre de host, clasifique cada resultado, fije la nueva conexión y contabilice el salto. Una política más simple puede exigir el mismo origen, pero rechaza acortadores y redireccionadores públicos comunes; el entrevistador debe escuchar esa compensación de producto de forma explícita.

¿Por qué rechazar un nombre de host cuando una respuesta DNS es pública y otra es privada?

Esto crea un contrato estable con fallo seguro (fail-closed). El orden de las direcciones varía entre resolvedores, familias de IP y reintentos. Seleccionar una respuesta pública durante la validación mientras otro componente selecciona posteriormente la respuesta privada reabre la vulnerabilidad. Un producto que desee una aceptación parcial necesita que el mismo componente fije únicamente direcciones aprobadas para cada conexión y debe probar la conmutación por error cuidadosamente; esta consigna adopta la política conservadora más simple.

¿Qué ocurre si el producto necesita capturas de pantalla o vistas previas renderizadas con JavaScript?

Ubique el renderizado en un nivel más aislado con la misma política de salida. Un navegador genera muchas solicitudes secundarias, por lo que debe interceptar y autorizar cada navegación, redirección, worker, WebSocket y subrecurso. Deshabilite el acceso al sistema de archivos local y funciones innecesarias del navegador, limite CPU, memoria, tiempo y descargas, y destruya el sandbox después de cada trabajo. El renderizado no hereda la confianza de la URL de la página inicial.

¿Cómo demostraría que el firewall es efectivo tras el despliegue?

Ejecute pruebas canary controladas desde la identidad y el espacio de nombres reales del worker contra destinos denegados de IPv4, IPv6, clúster, corporativos y de metadatos, y luego confirme tanto el fallo de la conexión como la telemetría de red esperada. Repita el proceso tras cambios en rutas, contenedores, proxies o redes de la nube. La revisión de configuración muestra la intención; los canaries y los registros de flujo (flow logs) muestran la ruta efectiva.