¿Qué es una API REST?
Una API REST es una API que cumple con restricciones arquitectónicas específicas asociadas a aplicaciones web, como la comunicación sin estado y los datos almacenables en caché. Las API REST permiten que las aplicaciones de navegador, las aplicaciones móviles y otros clientes de API se comuniquen con un servidor. A continuación, se presentan las 10 principales directrices de seguridad para API REST basadas en las experiencias de los clientes y los problemas destacados en el informe más reciente State of API Security report de Salt Security. Cuando el tiempo y los recursos lo permitan, considere adoptar el conjunto completo de prácticas recomendadas de seguridad para API descritas en la guía de prácticas recomendadas de seguridad para API de Salt. También puede utilizar la lista de verificación de seguridad para API correspondiente para realizar un seguimiento del trabajo asociado.
A diferencia de otros tipos de API, REST es un estilo y no un estándar estricto. Las API REST pueden diseñarse de muchas maneras, lo que influye en cómo se invoca la funcionalidad o cómo se pasan los datos en una solicitud. El esquema de la API REST resultante y la estructura de la URL del punto de conexión pueden variar enormemente de una organización a otra. Las API REST son implementadas, operadas o utilizadas por muchos roles dentro de una organización, incluidos el desarrollo, los equipos de producto, los equipos de operaciones, los equipos de seguridad de aplicaciones y las operaciones de seguridad. Las API REST son uno de los tipos de servicios web más comunes en la actualidad. Es imperativo diseñar las API REST correctamente, teniendo en cuenta la seguridad, el rendimiento y la facilidad de uso para los consumidores de la API REST.
Las 10 principales directrices de seguridad para API REST
1. Al generar la documentación de la API REST, opte por formatos legibles por máquina y definiciones de esquema en lugar de documentación tradicional o diagramas visuales.
Para las API REST, estos formatos legibles por máquina suelen ser Swagger u OAS. Dependiendo del diseño de su API REST, el desarrollo o las herramientas de publicación, pueden estar presentes otros formatos como RAML o REST API Blueprint. La documentación tradicional puede ser útil para revisiones por parte de una audiencia menos técnica, pero estas formas de documentación no son fáciles de mantener. Los formatos de definición de esquema de API REST están diseñados para la generación rápida de documentación como parte del diseño y la simulación de la API REST, que también es reutilizable para pruebas, integración, publicación y operaciones.
2. Descubra las API REST en entornos que no sean de producción, no solo en los de producción.
Es fundamental que realice un seguimiento de los entornos inferiores, incluidos QA, UAT, staging, SIT y preproducción, además de sus entornos de producción. Los atacantes saben que los entornos que no son de producción a menudo tienen controles de seguridad más relajados o inexistentes, aunque las API REST en esos entornos aún pueden permitir el acceso a conjuntos similares de funcionalidad y datos. Las organizaciones a menudo configuran entornos inferiores con una protección mínima para ayudar a promover el desarrollo y la integración rápidos a fin de cumplir con los objetivos de producción y los cronogramas de lanzamiento. Los entornos inferiores también pueden estar expuestos a Internet, lo que aumenta aún más el riesgo de seguridad.
3. Incluya las dependencias de sus API REST.
Vaya más allá de las API REST desarrolladas internamente e incluya también las API REST de software de código abierto, paquetes de aplicaciones adquiridos y servicios SaaS de terceros. Las preocupaciones de seguridad de las API REST no comienzan ni terminan solo con las API REST creadas a medida. La certificación de riesgos de proveedores y el lenguaje contractual son útiles principalmente como medidas reactivas que proporcionan recursos legales, pero ofrecen una garantía mínima a nivel tecnológico. Las organizaciones están inherentemente limitadas por las opciones de configuración que están dentro de su ámbito de control para los servicios de terceros. Sin embargo, esta limitación no exime a la organización del riesgo de seguridad. A menudo existen brechas significativas entre el diseño percibido de una aplicación y sus API REST en comparación con el sistema integrado entregado. La combinación de API creadas, integradas y adquiridas define la cadena de suministro digital en la que operan todas las organizaciones. Del mismo modo, también debe tener en cuenta otros tipos de API, como gRPC, GraphQL y SOAP.
4. Analice el código de la API REST automáticamente siempre que sea posible.
Analice el código automáticamente con herramientas de análisis estático, como comprobadores de calidad de código y pruebas de seguridad de aplicaciones estáticas (SAST), al confirmar el código en sistemas de control de versiones como git y/o en canalizaciones de compilación CI/CD. Si revisa el código manualmente, el proceso se topará rápidamente con un muro debido a la tasa de cambio que la mayoría de las organizaciones experimentan en su código y API REST. Analice la base de código integrada como parte de la compilación dentro de CI/CD para obtener el análisis más preciso, aunque algunas organizaciones también optan por analizar partes del código a medida que se confirman en el control de versiones para mayor rapidez. Un comprobador de calidad de código es la herramienta menos especializada, pero suele ser abundante en las organizaciones, ya que muchas herramientas de diseño y desarrollo incluyen capacidades nativas de comprobación de calidad de código. El SAST puede entregarse a través de linters específicos del lenguaje o una oferta de análisis de grado comercial. Independientemente de la herramienta que seleccione, prepárese para una gran cantidad de hallazgos de posibles debilidades y falsos positivos, especialmente si una base de código nunca se ha analizado. Los analizadores estáticos necesitan ajustes para utilizarse de manera eficaz. El análisis estático no podrá cubrir las fallas de la lógica empresarial por diseño, lo que requiere un análisis del comportamiento en tiempo de ejecución.
5. Intermedie las API REST para aplicar el control de acceso.
Las puertas de enlace de API (API gateways) se implementan a menudo para proporcionar visibilidad y control sobre las llamadas a API REST para el intercambio de datos o la funcionalidad. Estas puertas de enlace son mecanismos de mediación fundamentales que ofrecen gestión de tráfico, autenticación y autorización. Las funciones de gestión de tráfico se asignan a controles de seguridad de red bien conocidos, como límites de tasa o listas de permitidos y denegados de direcciones IP. Las puertas de enlace de API también son un lugar ideal para aplicar la autenticación y autorización para API REST, como OpenID Connect (OIDC) y OAuth2, respectivamente. Por lo general, las puertas de enlace de API se combinan con sistemas externos de gestión de identidad y acceso (IAM) para compartir la carga de almacenar todo tipo de identidades de usuario o máquina, autenticar identidades, autorizar identidades y mantener registros de auditoría de toda la actividad. El consumo automatizado de sus API REST (como en casos de uso de automatización o integración con socios) puede ser tan predominante como el consumo tradicional de usuarios finales a través de aplicaciones basadas en navegador y aplicaciones móviles.
6. Utilice transporte cifrado para proteger los datos que transmiten sus API REST.
Se debe habilitar TLS para cualquier punto final de API REST con el fin de proteger los datos en tránsito. Apunte a TLS 1.2 como mínimo y, idealmente, habilite TLS 1.3 si otros elementos arquitectónicos lo admiten. Todas las versiones de SSL deben deshabilitarse debido a la cantidad de debilidades en el protocolo o en los conjuntos de cifrado relacionados. Los componentes de infraestructura heredados a veces permanecen dentro de las organizaciones o proveedores, lo que requiere mantener SSL o versiones anteriores de TLS. Es posible que algunas herramientas de inspección de tráfico tampoco admitan protocolos de cifrado más recientes, lo que pone a las organizaciones en un aprieto cuando desean mantener la visibilidad sobre el tráfico de su red. Desafortunadamente, admitir protocolos y conjuntos de cifrado antiguos expone a la organización a una serie de ataques criptográficos y de degradación que pueden hacer que los datos cifrados sean visibles para partes no autorizadas. Aplique políticas de cifrado a través de sus capas de mediación de API REST siempre que sea posible y asegúrese de que los protocolos y conjuntos de cifrado heredados permanezcan deshabilitados. Si es necesario, refactorice o rediseñe la infraestructura de soporte de sus API REST, optando por puntos de terminación TLS que le permitan mantener la visibilidad del tráfico mientras mitiga el riesgo de seguridad de los ataques a los protocolos de cifrado.
7. Evite enviar demasiados datos a los clientes de la API REST.
Los clientes de API REST o el código de front-end suelen adoptar la forma de JavaScript ejecutándose dentro de un navegador web o binarios de aplicaciones en un dispositivo móvil. Las API REST de back-end a veces están diseñadas para ofrecer una gran cantidad de datos en respuesta a las llamadas de los clientes de API, y se convierte en responsabilidad del código del cliente de front-end filtrar lo que debe ser visible según los objetivos de la experiencia del usuario (UX) o los niveles de permiso. Este patrón de diseño va en contra de las mejores prácticas de seguridad de API REST, ya que esos datos son totalmente visibles al observar las solicitudes y respuestas de la API REST. Los atacantes suelen realizar ingeniería inversa en el código de front-end y rastrear el tráfico de la API REST directamente para ver qué datos se están transmitiendo realmente. Este problema se clasifica como uno de los 10 principales riesgos de seguridad de API REST de OWASP, específicamente API3:2019 Exposición excesiva de datos, debido a que es muy común. No envíe demasiados datos, especialmente datos confidenciales o privados, a los clientes de front-end y asuma siempre que están comprometidos. Filtre los datos adecuadamente en el back-end y envíe solo los datos necesarios para ese consumidor de API REST en particular.
8. Autentique y autorice continuamente a los consumidores de API REST.
El control de acceso siempre ha implicado autenticación y autorización. La autenticación (AuthN) implica identificar al solicitante de una función o recurso determinado y desafiar a esa entidad para obtener material de autenticación o credenciales. La autorización (AuthZ) implica verificar si esa entidad autenticada realmente tiene permisos para ejercer una función o leer, escribir, actualizar o eliminar datos. Tradicionalmente, ambos se manejaban al inicio de una sesión. En el mundo web, y por extensión en las API REST, las sesiones no tienen estado. Los entornos operativos de los back-ends y front-ends no están garantizados y a menudo son efímeros. Cada vez más, los entornos también son propensos a problemas de integridad o compromiso, de ahí el auge de las arquitecturas de confianza cero (zero trust). Como resultado, debe verificar continuamente si una identidad de usuario o máquina debe tener acceso a un recurso determinado y asumir siempre que la sesión autenticada podría estar comprometida. Este enfoque requiere analizar el comportamiento de una sesión determinada para un consumidor de API REST y, potencialmente, terminar esa sesión, requerir una autenticación reforzada o bloquear el acceso según corresponda.
9. Explore el análisis de comportamiento y la detección de anomalías.
A medida que las organizaciones adoptan API REST, se dan cuenta rápidamente de la necesidad de análisis de datos y comportamiento impulsados por máquinas para comprender el consumo normal de API REST e identificar a los atacantes que abusan de ellas. Los algoritmos deben estar informados por los metadatos de la API REST, así como por la recopilación de tráfico de la API REST, aprender continuamente y tomar decisiones de forma dinámica según la lógica empresarial única de la organización. La detección y protección impulsadas por máquinas también deben integrarse en una plataforma más amplia de servicios e integración para que se pueda implementar temporalmente una acción de mitigación adecuada, como establecer un límite de tasa dinámico para un solicitante abusivo, en la entrada de red adecuada de la arquitectura general. Incluso las organizaciones maduras con recursos de desarrollo y ciencia de datos se topan rápidamente con un muro al intentar desarrollar dicha detección e integración. Inevitablemente, necesitará explorar herramientas de seguridad de API REST para cerrar esta brecha.
10. Cree manuales de respuesta a incidentes centrados en API para API REST.
Asegúrese de documentar los procesos de análisis forense digital y respuesta a incidentes (DFIR) sobre cómo responder a los patrones de ataque de API REST inevitables. Si ya ha madurado su estrategia de SecOps para incluir el uso de orquestación, automatización y respuesta de seguridad (SOAR), automatice también algunos de los elementos del flujo de trabajo como parte de la respuesta a incidentes. Cerrar una API REST que es objeto de actividad maliciosa rara vez es una decisión comercial prudente, sin mencionar que reduce su capacidad para obtener información adicional sobre un atacante y sus técnicas. En lugar de bloquear el tráfico por completo, es probable que desee emplear una mayor precisión, como limitar solo al llamador sospechoso de la API REST, desafiarlo con factores de autenticación adicionales o monitorear su comportamiento de manera más intensiva. Cree manuales de respuesta a incidentes para patrones comunes de ataque a API REST, incluidos DoS de capa de aplicación, ataques de fuerza bruta, relleno de credenciales, enumeración y scraping.
Resumen de mejores prácticas de seguridad de API REST
Este conjunto de mejores prácticas de seguridad de API está diseñado específicamente para los tipos de API REST y los conjuntos de problemas de seguridad más comunes que enfrentan las organizaciones. Comience eligiendo algunas áreas de mejores prácticas con las que esté más familiarizado. Amplíe su estrategia de seguridad de API con el tiempo para cubrir todas las mejores prácticas y evitar brechas en la postura de seguridad de API de su organización. Considere adoptar el conjunto completo de mejores prácticas de seguridad de API descritas en la guía de mejores prácticas de seguridad de API de Salt como parte de un enfoque integral para cubrir todos los tipos de API. También puede hacer uso de la lista de verificación correspondiente para realizar un seguimiento del trabajo asociado.
Si le interesa ver la plataforma de protección de API de Salt Security en acción, contáctenos para una demostración personalizada ¡hoy mismo!