SSRF: Cómo identificar y verificar de forma segura

Fuentes SSRF

En esta etapa, se definen qué evidencias son necesarias para responder a la pregunta de investigación. Para las pruebas SSRF, los puntos básicos son Role y session, Endpoint y method, Request/Response, Object identifier. Para cada fuente, se documenta el propietario, el rango de retención, la zona horaria, el retraso de ingesta y los campos que pueden faltar.

La calidad de la recolección no se mide solo por si el log 'llega'. Se deben verificar Completeness, Latency, Parsing, Duplicate events y sincronización de tiempo. Una prueba Canary o un evento de laboratorio conocido permite verificar que la acción apareció en la fuente, pasó por el Pipeline y se puede buscar en los campos correctos.

Mapeo de entradas URL

El tema 'Mapeo de entradas URL' es una parte central del trabajo sobre pruebas SSRF. Se recomienda dividirlo en tres preguntas: ¿Cuál es la entrada?, ¿Qué decisión se quiere tomar? y ¿Qué evidencia es suficiente para justificarla? Estas preguntas evitan el uso automático de herramientas sin entender el objetivo.

En la práctica, anote URL fetch feature, allowlist, redirects, DNS rebinding defenses, metadata endpoint, compare con el comportamiento esperado y defina al menos un Pivot. El resultado debe ser verificable por otro analista, incluyendo limitaciones y próximos pasos.

Validación con un servidor de laboratorio

Para entender la diferencia en el contexto de las pruebas SSRF, es importante comparar objetivos y no solo herramientas. Una opción ofrece amplitud o velocidad, y otra proporciona una validación profunda o contexto. La elección correcta depende de la pregunta: ¿Se requiere descubrimiento, investigación, prueba de impacto, contención o reporte?

Una tabla comparativa profesional debe incluir al menos: tipo de entrada, nivel de certeza, costo operativo, impacto potencial, limitaciones y seguimiento requerido. En caso de duda, se utiliza el enfoque menos intrusivo y se añade una fuente complementaria en lugar de sacar una conclusión demasiado amplia.

Blind SSRF y Logging

En esta etapa, se definen qué evidencias son necesarias para responder a la pregunta de investigación. Para las pruebas SSRF, los puntos básicos son Role y session, Endpoint y method, Request/Response, Object identifier. Para cada fuente, se documenta el propietario, el rango de retención, la zona horaria, el retraso de ingesta y los campos que pueden faltar.

La calidad de la recolección no se mide solo por si el log 'llega'. Se deben verificar Completeness, Latency, Parsing, Duplicate events y sincronización de tiempo. Una prueba Canary o un evento de laboratorio conocido permite verificar que la acción apareció en la fuente, pasó por el Pipeline y se puede buscar en los campos correctos.

Remediación y Retest

Una prueba profesional para SSRF comienza con condiciones de éxito y condiciones de fallo. Se define un Caso positivo, un Caso negativo, un Caso límite y una actividad legítima similar. Así se pueden identificar tanto Falsos Negativos como Falsos Positivos.

En un entorno autorizado, se utiliza una acción mínima que demuestre la afirmación sin causar daño. Se guarda Input, Output, tiempo y versión, y después de la corrección se realiza un Retest en el mismo escenario y se verifica también la Regresión en funciones cercanas.

Puntos de prueba únicos

En este tema, se recomienda construir de antemano un mapa de evidencias enfocado. Los puntos de prueba centrales son: URL fetch feature, allowlist, redirects, DNS rebinding defenses, metadata endpoint, egress controls. La lista no es un Checklist automático; cada elemento se elige porque puede vincular una entidad, una acción y un tiempo o explicar un comportamiento legítimo.

• URL fetch feature: Defina cuál es el valor esperado, qué se considerará una anomalía y qué fuente adicional verificará el hallazgo.
• allowlist: Defina cuál es el valor esperado, qué se considerará una anomalía y qué fuente adicional verificará el hallazgo.
• redirects: Defina cuál es el valor esperado, qué se considerará una anomalía y qué fuente adicional verificará el hallazgo.
• DNS rebinding defenses: Defina cuál es el valor esperado, qué se considerará una anomalía y qué fuente adicional verificará el hallazgo.
• metadata endpoint: Defina cuál es el valor esperado, qué se considerará una anomalía y qué fuente adicional verificará el hallazgo.
• egress controls: Defina cuál es el valor esperado, qué se considerará una anomalía y qué fuente adicional verificará el hallazgo.

Cuando uno de los puntos no está disponible, se debe documentar la brecha y elegir una alternativa. Por ejemplo, si el Process identifier no es estable, se puede utilizar tiempo, Host, User y Parent; si el Payload está encriptado, se utilizan Metadata, volumen, frecuencia y contexto TLS/DNS.

Proceso de trabajo recomendado

1. Defina el Scope y una pregunta de trabajo sobre las pruebas SSRF.
2. Anote las fuentes de datos y las evidencias necesarias: URL fetch feature, allowlist, redirects, DNS rebinding defenses.
3. Cree una Baseline corta de comportamiento normal o resultado esperado.
4. Realice la prueba mínima en un entorno de laboratorio y guarde el tiempo, la entrada y la salida.
5. Construya una Timeline o tabla comparativa y separe los hechos de la interpretación.
6. Realice un Pivot a otra fuente para confirmar o refutar la explicación inicial.
7. Resuma la decisión, las limitaciones, la acción recomendada y el criterio de Retest.

Escenario práctico

El escenario elegido es una prueba contra un Callback local en laboratorio. El objetivo del ejercicio no es demostrar la capacidad de ataque, sino practicar la recopilación, comparación y documentación de forma segura. Antes de comenzar el trabajo, se definen datos simulados, una ventana de tiempo y un resultado esperado.

Al finalizar el ejercicio, se debe presentar un producto que otro analista o probador pueda revisar: una captura de pantalla o exportación de la evidencia, una Timeline corta, una suposición inicial, una evidencia de confirmación, una limitación y una recomendación. Cuando no hay evidencia suficiente, la conclusión correcta es que el escenario no ha sido probado.

Checklist práctico

• ✓Verificar y documentar: Role y session.
• ✓Verificar y documentar: Endpoint y method.
• ✓Verificar y documentar: Request/Response.
• ✓Verificar y documentar: Object identifier.
• ✓Verificar y documentar: Server-side effect.
• ✓Verificar y documentar: Control expected y remediation.
• ✓Indicar Time zone, versión de la herramienta y hora de recopilación.
• ✓Guardar el dato bruto antes de filtrar o modificar.
• ✓Escribir lo que el hallazgo demuestra y lo que aún se desconoce.
• ✓Definir propietario y acción de seguimiento con fecha.

Errores comunes

• Comprobar solo el Status code.
• Depender de un cambio Client-side.
• Usar un Payload peligroso.
• No probar diferentes Roles.
• Ignorar la lógica de negocio.
• Reportar sin Request/Response limpios.

Resumen y CTA

SSRF: Cómo identificar y verificar de forma segura es un tema que conecta el conocimiento técnico con la disciplina laboral. Comience con una pregunta, recopile solo las evidencias relevantes, mantenga el contexto y el tiempo, y elija una acción que pueda justificarse y volverse a probar.

En el programa Cybersecurity & AI de HPI, estos principios se practican utilizando sistemas, logs y laboratorios. El paso natural es pasar a los artículos vinculados, realizar el ejercicio de laboratorio y guardar el producto como parte de un portafolio profesional.

Preguntas frecuentes