- TL;DR: en lugar de redirigir las llamadas a la API de HTTP a HTTPS, deben fallar. Hay que desactivar por completo HTTP o devolver una respuesta de error HTTP clara, y revocar las claves de API enviadas por conexiones sin cifrar. Lamentablemente, muchos proveedores de API conocidos hoy no lo hacen.
Contexto
- Cuando un navegador web accede a una URL HTTP, el servicio a menudo redirige esa solicitud a una página HTTPS.
- El tráfico HTTP inicial no está cifrado, por lo que es vulnerable a ataques de intermediario en la red (MITM).
- Se introdujeron tecnologías como HSTS (HTTP Strict Transport Security) para reforzar la seguridad.
El riesgo de un simple error tipográfico
- Durante una integración con una API de terceros, se escribió por error la URL base de la API como
http:// en lugar de https://.
- El
fetch de Node.js siguió silenciosamente la redirección hacia HTTPS.
- La clave de API pudo haberse enviado en texto plano, generando un riesgo de seguridad.
- El error se detectó durante la revisión de código y se corrigió.
Principio de fallo rápido
- Si una API redirige solicitudes HTTP a HTTPS, es fácil pasar por alto un error tipográfico.
- Conviene seguir el principio de fallo rápido: una llamada a API sin cifrado debe fallar de forma clara.
- Lo ideal es desactivar la interfaz HTTP del servidor de la API o devolver un mensaje de error para las solicitudes HTTP.
Casos de otras API
- Varias API conocidas devuelven un mensaje de error 403 para solicitudes HTTP o desactivan la interfaz HTTP.
- Sin embargo, algunas API todavía redirigen de HTTP a HTTPS.
La necesidad de mejores prácticas
- En aplicaciones orientadas al usuario, redirigir de HTTP a HTTPS es algo común.
- En el caso de las API, redirigir de HTTP a HTTPS puede ser más bien perjudicial.
- Se necesitan lineamientos claros para las API en proyectos de seguridad como OWASP.
Conclusión
- Las API no deben redirigir de HTTP a HTTPS; deben hacer que las solicitudes sin cifrar fallen claramente.
- Si una clave de API se envía por una conexión sin cifrar, debe revocarse de inmediato.
- Es necesario actualizar las mejores prácticas de seguridad para API y ofrecer lineamientos claros.
Opinión de GN⁺
- Necesidad de reforzar la seguridad: la seguridad de las API es muy importante, y redirigir de HTTP a HTTPS puede provocar vulnerabilidades.
- Principio de fallo rápido: es importante seguir este principio para poder detectar y corregir errores en etapas tempranas del desarrollo.
- Actualización de mejores prácticas: proyectos de seguridad como OWASP deberían ofrecer lineamientos claros sobre la seguridad de las API.
- Revocación automática de claves: las claves de API enviadas por conexiones sin cifrar deberían revocarse automáticamente.
- Tomar como referencia otros casos: conviene revisar las prácticas de seguridad de otras API para reforzar la seguridad de la propia API.
5 comentarios
Parece un ámbito que debería regularse por ley.
Por ahora, una nota... prohibir las redirecciones a HTTPS en las API
Técnicamente es correcto,
pero en la mayoría de los clientes corporativos existe la política de seguridad de que, al acceder por HTTP, siempre se envíe una redirección a HTTPS.
Además, también evitan mostrarles una pantalla de error a los clientes que usan su sitio, así que, salvo que sea un lugar que opera su propio servicio, desde la posición de quien entrega la solución esto vendría siendo una historia de otro mundo, supongo..
Vaya, la IA cometió este error jaja. Ya lo corregí.
Comentarios en Hacker News