La especificación OpenAPI (OAS) (anteriormente conocida como especificación Swagger) es una forma de describir y crear documentación para API REST, junto con sus componentes, como detalles sobre los puntos finales, sus operaciones, los parámetros necesarios para dichas operaciones, las respuestas esperadas para cada una, los métodos de autenticación y las anotaciones. La OAS es un formato fácil de aprender y leer, y tanto los humanos como las máquinas pueden consumir sus datos, lo que la hace aplicable a una gran variedad de casos de uso. En esta publicación, cubriremos algunas de las formas en que los equipos de desarrollo y seguridad utilizan la OAS y por qué se queda corta a la hora de proteger sus API.
Cómo utiliza el desarrollo la OAS
Los desarrolladores utilizan la OAS para generar documentación para las API, como archivos de especificación y definición de OpenAPI. Esta documentación ayuda a otros a comprender la estructura y la funcionalidad de la API, lo cual es útil cuando otro desarrollador desea integrar una API para añadir funcionalidad a su aplicación.
Muchos desarrolladores tienen una relación de amor-odio con la OAS, ya que cualquier tiempo dedicado a la documentación es tiempo perdido en el desarrollo. La OAS es fácil de aprender, pero la documentación es intrínsecamente tediosa: es manual, requiere mucho tiempo y es una de las partes menos atractivas del trabajo de un desarrollador. Como resultado, los desarrolladores suelen hacer lo mínimo indispensable, dejando la documentación incompleta, inexacta o, en el peor de los casos, inexistente.
Cómo utiliza la seguridad la OAS
La documentación OAS ayuda a los equipos de seguridad a descubrir la existencia de una API y a comprender qué se supone que debe hacer. Con la documentación, los equipos de seguridad pueden determinar si la API cumple o infringe las políticas. Por ejemplo, el equipo de seguridad podría utilizar la documentación de la API para asegurarse de que el equipo de desarrollo haya implementado correctamente la autenticación y la autorización, y que no haya expuesto innecesariamente datos confidenciales como información de identificación personal (PII).
Los equipos de seguridad también pueden utilizar herramientas de seguridad basadas en OAS para alinearse con lo que los desarrolladores pretendían que hiciera la API, validando la entrada de la API según lo definido en un archivo de definición de OpenAPI y aplicando políticas.
Uso de la OAS para el descubrimiento de API y la validación de políticas
En un mundo ideal, cada API estaría bien documentada como parte del proceso de desarrollo. El equipo de seguridad conocería la documentación y la API antes de que pasen a producción, de modo que puedan evaluar los detalles, validar que la API cumple con las políticas y aprobar su lanzamiento. Como nadie vive en un mundo ideal, considere las siguientes preguntas:
¿Existe documentación OAS? En los casos más extremos, la documentación no existe, por lo que no puede utilizarse para ningún tipo de concienciación. La empresa se queda con API en la sombra y riesgos no detectados.
¿Está completa la documentación OAS? ¿En todos los entornos que hemos visto? No. Nuestros clientes producen su documentación con confianza, nuestra plataforma analiza el mismo entorno y la documentación no coincide con la realidad. Las brechas abarcan desde documentación incompleta hasta la falta de detalles críticos, como destaca el siguiente ejemplo, donde la documentación OAS (Swagger) indicaba 2 parámetros y nosotros encontramos 27:
Además de faltar 25 parámetros, la documentación OAS también carecía de información clave sobre dónde se exponía información de identificación personal (PII), dejando a la empresa vulnerable.
¿Se mantiene actualizada la documentación OAS? Las prácticas de desarrollo rápido significan que las API cambian constantemente, y la actualización de la documentación siempre va a la zaga.
Uso de herramientas de seguridad basadas en OAS para proteger las API
Las empresas también pueden utilizar la documentación OAS como un esquema para validar las entradas de la API, aplicando una herramienta de seguridad basada en OAS para garantizar que la entrada se ajuste a lo definido en el archivo de especificación OpenAPI. Por ejemplo, el archivo de definición OpenAPI puede especificar que se espera una cadena de texto para un parámetro concreto, que dicha cadena no supere una longitud determinada y que solo contenga letras y números, sin caracteres especiales. Cualquier elemento que no cumpla con esa definición será bloqueado.
Una documentación OAS inexistente, inexacta o desactualizada dificulta el inventario y el descubrimiento de las API, pero además supone un riesgo significativo a la hora de aplicar medidas de seguridad.
Depender exclusivamente de la documentación OAS para la seguridad, incluso cuando esta es precisa, solo cubrirá un pequeño porcentaje del riesgo que generan las API y, por tanto, no evitará brechas de seguridad ni la pérdida de datos. Confiar únicamente en la documentación OAS también puede afectar negativamente a sus clientes, socios y operaciones comerciales, incluidos los flujos de ingresos, al bloquear tráfico legítimo.
Estos son los riesgos de depender de la documentación OAS para proteger sus API:
Las herramientas de seguridad basadas en OAS no pueden proteger contra las amenazas a las API más comunes y críticas. El OAS carece de comprensión sobre la lógica de la API, por lo que es imposible crear políticas en un archivo de definición OpenAPI para prevenir ataques dirigidos a la lógica de la API, como las principales amenazas definidas en el OWASP API Security Top 10.
Las herramientas de seguridad basadas en OAS pueden ser engañadas y eludidas. El OAS carece de contexto sobre la actividad general del atacante y, por lo tanto, solo puede bloquear una llamada a la API específica, no al atacante, lo que permite a los atacantes realizar intentos interminables para eludir la validación de esquemas basada en OAS.
Las herramientas de seguridad basadas en OAS corren el riesgo de bloquear tráfico legítimo. La aplicación de la técnica de validación estricta bloquea cualquier llamada a la API anómala, incluyendo discrepancias en los patrones de valores de los parámetros, parámetros desconocidos o puntos finales desconocidos. Este enfoque provocará el bloqueo de tráfico legítimo cuando las API no estén documentadas correctamente.
Las herramientas de seguridad basadas en OAS corren el riesgo de pasar por alto ataques. La aplicación de la técnica de validación flexible con un contrato genérico y muy amplio, como no definir patrones o utilizar tipos de datos genéricos como "string", permitirá que muchas llamadas maliciosas a la API superen la validación.
Conclusión
La documentación basada en OAS es útil tanto para los equipos de desarrollo como para los de seguridad si es precisa, pero el OAS y las herramientas de seguridad basadas en OAS tienen deficiencias inherentes que limitan la protección a solo un pequeño porcentaje del riesgo de las API. Depender de la documentación OAS y de las herramientas de seguridad basadas en OAS para proteger sus API no evitará brechas de seguridad ni la pérdida de datos.
Descubra cómo Salt Security puede ayudarle a mejorar sus esfuerzos de documentación de API basada en OAS y proporcionar una cobertura completa contra las amenazas a las API.