Especifica controles de falsificación de solicitudes del lado del servidor utilizando esquemas y hosts en lista blanca, resolución DNS con verificación posterior, bloqueo de destinos de enlace local y metadatos en la nube, y una prohibición de usar URLs del llamador como proxy abierto.
Estado del paquete: contexto de referencia listo para revisión humana. El contrato y los escenarios de prueba están completos, pero no se afirma que una implementación adoptante los haya superado.
Decisión
Los recuperadores del lado del servidor que acceden a la red en nombre de un usuario operan con una lista blanca de esquemas y hosts. Después de la resolución DNS, la implementación vuelve a verificar cada dirección resultante contra listas de denegación para loopback, RFC1918, enlace local, IPv6 local único y puntos finales de metadatos en la nube. Las URLs proporcionadas por el usuario nunca se usan como proxy abierto. Los redireccionamientos están deshabilitados en este perfil para que un primer salto no pueda rebotar hacia un rango bloqueado. El rebinding DNS se trata como un destino fallido.
Alcance
- Previsualizaciones de enlaces, callbacks de webhooks iniciados por el producto y generadores de miniaturas o despliegues.
- Límites de esquema, host, IP, metadatos, fijación DNS, tiempo de espera y tamaño de respuesta en el perfil de adopción.
- Vocabulario de errores
ssrf_destination_blocked.
Fuera de este bloque
- Reglas de contenido mixto del lado del navegador.
- Escaneo de malware en bytes descargados; ver el bloque relacionado de puerta de subida.
- Controles de salida para herramientas administrativas iniciadas por el operador que usan una ruta de confianza diferente.
Contrato
- La conexión solo está permitida cuando el esquema está en
allow_schemesy el nombre de host está enallow_hosts. - Tras la resolución, cada dirección debe estar fuera de
deny_ip_cidrsymetadata_hosts; de lo contrario, la recuperación se aborta. - Si las respuestas DNS cambian dentro de
pin_ttl_secondsa una dirección denegada, la recuperación en curso se aborta por rebinding. user_url_as_proxyes falso: no se recuperan URLs de llamadores que no están en la lista blanca.follow_maxes cero; un estado de redirección no produce una segunda conexión.- Los tiempos de espera y
max_response_byteslimitan la recuperación; superarlos falla cerrando sin reintento a un host nuevo.
Guía de implementación
- Análisis estricto de URLs; rechazar credenciales en la URL e IPs que evadan la lista blanca de nombres de host.
- Resolver con un resolvedor controlado por la aplicación; canonicalizar IPv4 mapeado en IPv6 antes de las verificaciones de denegación.
- Combinar con una política de red que aún deniegue metadatos y enlace local.
Manejo de fallos y salvaguardas
- Fallo DNS es un bloqueo. Un
allow_hostsvacío impide el inicio del recuperador. - Los cuerpos sobredimensionados se descartan. Conectar solo a la dirección fijada y verificarla nuevamente.
Verificación y operaciones
- Pruebas: IPs de metadatos, CNAME a metadatos, esquema http, redirección a enlace local.
- Volver a verificar hosts en lista blanca contra listas de denegación; no ampliar a sufijos comodín.
Los ejemplos con apariencia ejecutable en este paquete son fixtures y contratos de aceptación. Ejecute
python tools/validate.py desde la raíz de la colección para verificar la estructura y metadatos del paquete; luego
implemente y ejecute los escenarios en el repositorio objetivo.
Suposiciones de adopción
- Los nombres y valores numéricos en
example.yamlson un perfil de adopción, no valores predeterminados universales. - El equipo adoptante debe mapear actores, clases de datos, vocabulario de errores y propiedad a su sistema.