Este artículo revisa brevemente el historial de desarrollo de la API, sus conceptos básicos, funciones, protocolos relacionados y escenarios de uso, y se centra en diferentes elementos de seguridad, amenazas, métodos de autenticación y doce buenas prácticas relacionadas.
Según la historia registrada, la primera Web API apareció a finales de 1990 con la introducción de la solución de automatización de ventas de Salesforce. En ese momento, era un recurso abierto accesible para todos. Las herramientas de automatización de Salesforce están impulsadas por XML. El formato de datos utilizado para intercambiar la información de la herramienta se reconoció más tarde como el estándar API SOAP. Tiene especificaciones de formato de mensaje asociadas con permitir o rechazar varias solicitudes, así como reglas específicas del código. Es decir, la mayoría de los desarrolladores necesitan usar documentos XML manualmente con RPC además del procesamiento SOAP necesario para el desarrollo y la creación de API. Posteriormente, el desarrollador debe interpretar el punto final de la API y publicar la suite SOAP en ese punto final. Este no es solo el nacimiento de la API, sino también el comienzo del concepto de SaaS.
Los eventos clave que dieron forma a las API modernas fueron la introducción de las API de Flicker y Facebook. Flicker ha desarrollado una plataforma para almacenar imágenes digitales a través de la nube, que admite el intercambio de imágenes en diferentes plataformas mediante el desarrollo de API e integra nuevos servicios de varias instalaciones para compartir fotos.
Para 2008, las API habían evolucionado para operar de forma independiente y manejar grandes cantidades de información interconectada. Al lanzar una API, Twilio facilita a los usuarios la conexión de varias partes de todo el producto, como llamadas y mensajes de texto.
¿Qué son las API?
Para empezar, una API se refiere a una interfaz de programación de aplicaciones diseñada para permitir una comunicación fluida entre dos aplicaciones diferentes. A menudo se le conoce como el "intermediario" de la aplicación. Dado que necesitamos proteger los datos de los usuarios y la integridad de la aplicación en sí, la seguridad de la API es una "necesidad única".
Y para los desarrolladores, la API es una gran herramienta. Puede intercambiar información entre microservicios y contenedores y permitir una comunicación rápida. Así como la integración y la interconexión son importantes para el desarrollo de aplicaciones, las API, en cierto modo, impulsan y mejoran el diseño de aplicaciones.
Las API toman Internet por asalto
En los primeros días de Internet, API, como protocolo propietario, se usaba a menudo en áreas, propósitos u organizaciones restringidas en la red, lo que hacía posible la comunicación y la computación en diferentes arquitecturas de red. Después del surgimiento de la Web 2.0, las herramientas basadas en la Web surgieron ampliamente y la gente comenzó a usar REST (Representational State Transfer Framework), una especificación de desarrollo comunitario, para crear interfaces API para aplicaciones prácticas, como nuestra OpenAPI común.
En la era actual de la Web 3.0, las API desempeñan un papel fundamental en la comunicación entre el IoT y los dispositivos alimentados por IA. El paradigma regular de solicitud-respuesta de las API también ha cambiado a un enfoque basado en eventos.
Casos de uso de API
Como elemento básico para facilitar el intercambio de información, la API es ampliamente utilizada en el campo del desarrollo de aplicaciones Web. Actualmente, los casos de uso de API más utilizados e importantes en la industria son los siguientes:
Solicitud de una sola página (SPA)
Las API REST no solo aceleran el desarrollo de aplicaciones de una sola página, sino que también ayudan a las aplicaciones a colocar todo el contenido en una página para brindar una experiencia de usuario completa. Durante el desarrollo de aplicaciones, los programadores pueden usar archivos CSS, JavaScript y HTML predefinidos para iniciar la comunicación entre servidores web. Tenga en cuenta que los marcos REST se utilizan a menudo para la comunicación del lado del servidor y para el intercambio de información del lado del cliente para ciertos tipos de marcos.
Los marcos de trabajo de API REST comúnmente utilizados para el desarrollo de SPA incluyen: NancyFx, Express.js y ASP.Net WebAPI. Como marco sin estado, las API REST no se ven afectadas por los clientes que llaman a uno o más servidores para cada solicitud. Por lo tanto, el uso de la API REST para el desarrollo de SPA puede mejorar la escalabilidad de la aplicación. Obviamente, esto no solo reduce el costo del desarrollador de extender la aplicación, sino que también elimina la necesidad de que la aplicación acceda a recursos específicos.
En el desarrollo de SPA, aparte de la documentación de la API REST, ningún otro elemento está vinculado al cliente y al servidor. Por lo tanto, esta independencia promueve la flexibilidad en el desarrollo, prueba y despliegue de aplicaciones. Y esto es precisamente lo que el marco web dinámico no puede lograr.
API pública, B2B de nivel empresarial
Las llamadas telefónicas, los faxes y los correos electrónicos han sido durante mucho tiempo los principales medios de comunicación para las operaciones B2B. Sin embargo, para satisfacer las necesidades del intercambio de información basado en IoT, las API RESTful pueden desempeñar un papel clave en la automatización de la comunicación B2B a nivel empresarial.
Desde la perspectiva del cliente, la publicación de API públicas permitirá a las empresas crear aplicaciones orientadas al consumidor y maximizar la comunicación con el mundo exterior. Al mismo tiempo, dado que la API pública permite a los clientes B2B ampliar varios comportamientos basados en el usuario, desacopla por completo los procesos comerciales y mejora la interoperabilidad basada en máquinas sin aumentar la carga de costos.
API privada frente a servicios de API internos
Mediante el uso de API privadas, los clientes B2B pueden reducir el tiempo de comercialización y acelerar la incorporación de nuevas aplicaciones y herramientas sin embotellar los flujos de trabajo existentes. Al administrar flujos de trabajo internos, las API privadas pueden identificar áreas componibles para que las empresas las reestructuren y modernicen. Y como proceso creativo, los modelos de negocios componibles pueden descomponer funciones complejas en micropartes manejables. Las API privadas facilitan el uso estratégico de los recursos al permitir una comunicación eficiente en todos los niveles dentro de la organización.
Hace que los resultados del análisis de inteligencia empresarial sean más precisos ya que la API interna proporciona información detallada sobre varias causas posibles de fallas operativas y mejora el tiempo de respuesta de los componentes del sistema. Y después de usar la API privada, las capacidades de colaboración e intercambio de información de la aplicación serán más rápidas y seguras.
malla de servicio
Como componente de la capa de infraestructura, una red de servicios es altamente configurable y de baja latencia. Por lo general, se usa en estructuras de red para manejar comunicaciones internas a gran escala. Mediante el uso juicioso de las redes, los desarrolladores pueden garantizar un intercambio de información rápido, seguro y confiable para varias aplicaciones efímeras y en contenedores.
Las API se pueden utilizar para el intercambio de información en una red de servicios. Pero las cosas se complican mucho más cuando el plano de datos de la malla entra en contacto con cada paquete o solicitud que pasa por el sistema. Por lo tanto, usar API como Universal Data Plane y xDS puede simplificar este tipo de trabajo. Pueden verificar el estado del sistema, monitorear su rendimiento, enrutar varias solicitudes entrantes o salientes, equilibrar el tráfico del sistema compartiendo la carga y descubrir operaciones incorrectas relacionadas con la autorización del usuario a través del descubrimiento de servicios.
servidor móvil
Como modelo emergente de prestación de servicios, los backends móviles se utilizan a menudo en el desarrollo de soluciones de optimización móvil. El modelo de desarrollo, conocido como Mobile Backend as a Service (MBaaS), brinda a los desarrolladores la libertad de mantener servidores y herramientas relacionadas con el servidor, incluidos componentes como administración de usuarios, notificaciones automáticas y complementos de inicio de sesión social.
Cada recurso de MBaaS utilizará un SDK flexible para conectarse al punto final de la API. Por ejemplo, MBaaS utiliza tecnologías como Flutter, Unity, Iconic y React Native para desarrollar aplicaciones front-end para los sistemas operativos Android e iOS. Al mismo tiempo, varias API de la plataforma MBaaS pueden brindar automatización a los desarrolladores en aspectos como la gestión del flujo de trabajo, las actualizaciones de notificaciones y la planificación de tareas.
Además, estas API pueden generar una capa de aplicación para permitir un intercambio de información fluido entre varios sistemas y servicios utilizados. Los desarrolladores también pueden diseñar varios servicios basados en necesidades para grupos de usuarios recién agregados.
Internet de las cosas (IoT)
Dado que los dispositivos IoT deben estar conectados a clientes o dispositivos de otros usuarios de la red para completar el intercambio de información, a menudo es inevitable exponer la información intercambiada cuando se usan las API. Para hacer esto, los desarrolladores deben crear aplicaciones lo suficientemente seguras y basadas en el contexto que no usen directamente la interfaz de usuario para interactuar con el mundo exterior.
La API REST es actualmente la API más común utilizada para escenarios del mundo real de dispositivos IoT e intercambia información a través del protocolo de Internet. Además, la API REST también permite a los desarrolladores aplicar estrategias de autenticación y autorización.
API a los ojos de diferentes personas
La diversidad de las API se usa a menudo en diferentes escenarios de aplicaciones, y los desarrolladores con diferentes roles tienen diferentes interpretaciones de las API.
Desarrollo de back-end:
-
Marco: Un plan o estrategia bien estructurada que define cómo funcionan las operaciones y los procesos.
-
Especificación: un documento basado en Swagger que describe funciones como REST u OpenAPI. Por ejemplo, algún tipo de esquema GraphQL relacionado con el contenido de Geo PC.
-
Datos y lógica comercial: los desarrolladores de back-end prefieren separar los datos y la lógica entre los clientes (por ejemplo, aplicaciones móviles o navegadores). Esto beneficiará su propio código o datos, por ejemplo, las aplicaciones de una sola página y las aplicaciones móviles pueden usar los mismos datos y API para manejar varias integraciones personalizadas.
-
Un backend móvil, web y de integración unificado mejora y simplifica el proceso de sincronización.
DevOps:
-
Cumpla con las especificaciones del entorno de producción: por ejemplo, si el punto final devuelve errores 502 con frecuencia, debe considerar usar la API para solucionarlo.
-
Escalabilidad: si el punto final necesita escalar para resolver los errores 504, debe averiguar los microservicios asociados con esto, el mejor flujo y la dirección a seguir para resolver el problema (por ejemplo, una API REST para GraphQL).
Diagrama de flujo de cómo funciona la API
Seguridad:
-
Nuevos protocolos: ¿Cómo lidiar con firewalls, escáneres y otras herramientas heredadas que dejan de actualizarse?
-
Seguridad este-oeste (este-oeste, es decir, entre varias aplicaciones de back-end y bases de datos, que es diferente de lo que solemos decir sur-norte): hay una falta de un buen monitoreo de las comunicaciones dentro de la red.
-
Requisitos de cumplimiento para nuevos componentes de seguridad, red u otros componentes de TI.
La importancia de la seguridad de las API
Como se mencionó anteriormente, la API y la seguridad de la API van de la mano. Esas API con poca seguridad a menudo son expuestas y atacadas por piratas informáticos. Y debido a que las API se utilizan principalmente para intercambiar información, conectar servicios y transmitir datos, una vez que se produce una fuga de datos, la empresa sufrirá pérdidas significativas.
Varios métodos de autenticación para la API
Antes de otorgar acceso a los usuarios, es necesario verificar la identidad real de quienes ven o editan los recursos de la API para evitar el uso inapropiado de la API.
1. Autenticación basada en host
Este proceso garantiza que solo los usuarios autenticados puedan acceder a los recursos implementados en el servidor al autenticar el host o el servidor. No necesitamos ninguna llave, ni de otro modo, para iniciar el proceso. Sin embargo, el servidor debe tener la capacidad de verificar la clave de inicio de sesión en tiempo real para controlar eventos como la suplantación de DNS, la suplantación de enrutamiento y la suplantación de IP.
La autenticación basada en host es muy similar a RSA en proceso e implementación. Por defecto, no tenemos que establecer ningún parámetro. Un administrador puede realizar la autenticación de usuario basada en host creando una clave privada para el host local o extrayendo una clave pública para el host local.
2. Autenticación básica
Este es uno de los esquemas de autenticación de API más sencillos. Dado que el cliente envía una solicitud HTTP con encabezados predefinidos, este método utiliza el protocolo y el proceso HTTP para solicitar y verificar credenciales como el nombre de usuario y la contraseña. Estas comprobaciones a menudo se realizan en un entorno controlado por navegador.
Con el respaldo de la gran mayoría de los navegadores y servidores, los detalles de las credenciales que se utilizan para este tipo de autenticación se pueden compartir a través de la red en texto sin cifrar o simplemente codificarse con base64. No solo puede ejecutarse en varios servidores proxy, sino que también puede otorgar acceso a recursos que no están alojados en un servidor IIS. Debido a la falta de protección cifrada, es vulnerable a ataques como la reproducción.
3, OAuth
Como tecnología de autenticación de API abierta personalizable, OAuth puede realizar la interacción entre aplicaciones, servidores y API de almacenamiento mediante la verificación de las identidades de los usuarios y la definición de estándares de autorización.
Cuando alguien inicia sesión en el sistema, autentica al usuario solicitando un token. Para ello, la persona o creador de la solicitud debe reenviar la solicitud de acceso al recurso al servidor de autenticación. El servidor aceptará o rechazará la solicitud de acuerdo con el resultado de la verificación.
OAuth es más seguro que otros procesos, lo que lo convierte en la primera opción para muchos usuarios. Los tres elementos clave de OAuth incluyen el proveedor de OAuth (como Google y Facebook), el cliente de OAuth (refiriéndose al sitio web/página que aloja la información) y el propietario (refiriéndose al usuario que realiza la solicitud de acceso).
4, OAuth 2.0
Una versión actualizada de OAuth, OAuth 2.0 es un protocolo de administración de acceso API ampliamente utilizado. Sus funciones incluyen restringir el acceso de los clientes de la API mediante el uso de servicios HTTP para iniciar las aplicaciones de los clientes. Tanto GitHub como Facebook usan el protocolo en su código de autenticación para servicios HTTP clave, eliminando las credenciales de usuario.
Los tres elementos clave de OAuth 2.0 son: el usuario que posee los datos, la aplicación y la propia API. Durante el proceso de autenticación, este método puede resolver fácilmente los datos del usuario para usar diferentes recursos. Se puede implementar en dispositivos y aplicaciones web, móviles y de escritorio con fines de autenticación.
5 、 SAML
El lenguaje de marcado de aserción de seguridad (SAML) es un proceso de API estandarizado para la autenticación mediante tecnología de inicio de sesión único. Realiza la verificación en base a los datos proporcionados por el usuario. Una vez autenticados, los usuarios tienen acceso a varias aplicaciones o recursos. Actualmente, SAML 2.0 es la versión más utilizada. Es muy similar a una identificación y puede ayudar en la evaluación de la identidad de un usuario.
¿Qué significa seguridad API?
La seguridad de las API no solo se enfoca en proteger las API que están directa o indirectamente expuestas a los usuarios, sino que también involucra principios de seguridad de la red, como la aceleración y la limitación de velocidad, el análisis de seguridad basado en la identidad y los siguientes conceptos clave de control de seguridad:
Acuerdo de API
La API se puede utilizar de muchas formas y estilos según las diferentes necesidades. Las diferentes formas de uso también determinan la seguridad de la implementación de la API.
JABÓN
El Protocolo simple de acceso a objetos (Simple Object Access Protocol, SOAP) es un protocolo de comunicación y mensajería basado en XML. El protocolo amplía HTTP y proporciona transporte de datos para servicios web. Usando este protocolo, podemos intercambiar fácilmente archivos que contienen todo, o llamar a procedimientos de forma remota. A diferencia de otros marcos como CORB, DCOM y Java RMI, el mensaje completo de SOAP está escrito en XML, por lo que es independiente del lenguaje.
DESCANSAR
Como arquitectura estándar web basada en el protocolo HTTP, REST puede usar cuatro verbos para cada solicitud HTTP pendiente: GET, POST, PUT y DELETE. Para los desarrolladores, la arquitectura RESTful es una de las herramientas más sencillas para comprender la funcionalidad y el comportamiento de la API. No solo hace que la arquitectura de la API sea fácil de mantener y expandir, sino que también facilita que los desarrolladores internos y externos accedan a la API.
gRPC
Como marco de alto rendimiento de código abierto, gRPC mejora el antiguo protocolo de llamada a procedimiento remoto (RPC). Utiliza HTTP/2, un protocolo de transferencia de tramas binarias, que simplifica el proceso de comunicación y mensajería entre los clientes y los servicios de back-end.
El gRPC completamente liviano es más de 8 veces más rápido que JSON. Puede llamar al búfer a través de un protocolo de tecnología de código abierto y adopta un formato de serialización independiente de la plataforma para mensajes estructurados. En el uso de la API, los desarrolladores pueden averiguar los diversos procedimientos que deben llamarse y evaluar los valores de los parámetros a través de gRPC.
Webhook
Los webhooks pueden enviar mensajes generados automáticamente de una aplicación a otra. En otras palabras, puede establecer, enviar y obtener comunicación actualizada entre dos aplicaciones en tiempo real.
Dado que los webhooks pueden contener información crítica y transmitirla a un servidor de terceros, podemos garantizar las prácticas de seguridad relevantes de la API mediante la autenticación HTTP básica o la autenticación TLS en los webhooks.
WebSocket
WebSocket es un protocolo de comunicación bidireccional que puede proporcionar un canal de comunicación bidireccional maduro entre el cliente y el servidor, compensando así las limitaciones del protocolo HTTP.
El cliente de la aplicación puede usar WebSocket para crear una solicitud de conexión HTTP y enviarla al servidor. Una vez que se establece la conexión de comunicación inicial, tanto el cliente como el servidor pueden usar la conexión TCP/IP actual para transmitir datos e información de acuerdo con el protocolo del marco de mensajes básico.
XML-RPC
XML-RPC puede comunicarse entre WordPress y otros sistemas a través de un proceso de comunicación estandarizado. Utiliza HTTP como transporte y XML como proceso de codificación. Su código de trabajo se almacena en el archivo xmlrpc.php ubicado en el directorio raíz del sitio web. Disponible como opción predeterminada en la versión 3.5 de WordPress, XML-RPC permite que las aplicaciones móviles interactúen sin problemas con el proceso de instalación de WordPress basado en la web.
Sin embargo, dado que xmlrpc.php puede compartir detalles de autenticación para cada solicitud de acceso, aumenta las posibilidades de ataques de fuerza bruta y ataques DDoS. En este sentido, cuando adoptamos la API XML-RPC, necesitamos aumentar las prácticas de seguridad relevantes.
JSON-RPC
Para los no iniciados, JSON-RPC es un protocolo RPC ultraligero que se puede utilizar para desarrollar API basadas en la cadena de bloques de Ethereum. Utiliza JSON (RFC4627) como formato de datos básico y tiene la capacidad de interpretar y procesar múltiples reglas y estructuras de datos. El protocolo se puede utilizar repetidamente sobre el mismo zócalo.
MQTT
MQTT es un protocolo de mensajes aprobado por OASIS, que ha sido ampliamente utilizado en el campo del desarrollo de herramientas y dispositivos IoT, y realiza el intercambio de información de tipo HTTP. Al ser tan liviano, permite a los desarrolladores escalar a millones de dispositivos a la vez. Cuando se trata de la seguridad de la API, MQTT no solo ayuda con el cifrado de mensajes, sino que también facilita la aplicación de TLS y la autenticación.
AMQP
Como protocolo abierto, Advanced Message Queuing Protocol (Advanced Message Queuing Protocol, AMQP) estipula el proceso de comportamiento del proveedor de mensajes, que se puede aplicar a la capa de aplicación para crear un sistema interoperable. Debido a que se implementa en binario, el protocolo no solo admite varias comunicaciones de middleware orientadas a mensajes, sino que también puede garantizar la entrega completa de los mensajes.
XMPP
Como conjunto de tecnologías de fuente libre, XMPP se puede utilizar para desarrollar colaboración multipartita, mensajería instantánea, chat multipartita, videollamadas y middleware ligero. Sus cuatro componentes clave incluyen: PHP, MySQL, Apache y Perl.
CoAP
Como estándar IETF definido por RFC 7252, CoAP se puede usar como un protocolo de seguridad API estandarizado para restringir aplicaciones en dispositivos IoT. Debido a que CoAP puede admitir la comunicación a través de LPWAN, es la mejor opción para proteger nodos de microcontroladores simples. CoAP trabaja en la capa TCP/IP y utiliza UDP como protocolo de transporte básico.
Seguridad de API en implementaciones en la nube, locales e híbridas
Los avances en tecnologías como los servicios en la nube, las plataformas de integración y las puertas de enlace de API han permitido a los proveedores de API proteger las API de diversas formas. Se puede argumentar que el tipo de pila de tecnología elegida para crear una API tiene un impacto directo en la protección de la API. Por ejemplo, una organización grande podría usar múltiples aplicaciones con API desarrolladas por sí mismas. Y en el proceso de fusionar varias aplicaciones, pueden aparecer varias islas API. Estos silos son a menudo donde se encuentran los riesgos de seguridad.
En un ecosistema heterogéneo, la infraestructura de seguridad de API específica en las islas de API se puede configurar como agentes secundarios y de banda lateral, integrados entre la nube y las implementaciones locales. Al ser altamente portátil, estas configuraciones de seguridad permiten que cualquier tecnología preparada para el futuro transfiera o extraiga API fácilmente.
capa de seguridad API
La capa de seguridad de la API debe tener varias capas. Cada capa realiza sus propias funciones para proporcionar la máxima protección de seguridad.
descubrimiento de API
La primera capa de seguridad de API es el descubrimiento de API; después de todo, no puede protegerse si no conoce los objetivos y las amenazas. Como se mencionó anteriormente, los silos de API son el principal problema que impide que el personal de seguridad descubra las API. Debido a la falta de visibilidad de la API, obstaculizará directamente la gestión de los derechos de acceso a la API.
Las API en la sombra son la segunda barrera más grande para la visibilidad de las API. Cuando una API se desarrolla como parte de una aplicación, a menudo solo la conocen los miembros del equipo de desarrollo, mientras que el personal de seguridad ignora los detalles de implementación de tales "API en la sombra".
El tercer obstáculo es el control de versiones de la API. Durante el ciclo de vida de una aplicación de software, su API a menudo necesita iterarse continuamente. Sin embargo, la nueva versión de la API a menudo no puede reemplazar de manera inmediata y completa a la versión anterior. Dado que las versiones de la aplicación del cliente no son las mismas, la versión anterior de la API debe continuar ejecutándose durante un período de tiempo de acuerdo con el requisito de compatibilidad con versiones anteriores. Y entonces, gradualmente desaparecerán del campo de visión del equipo de desarrollo, o incluso serán olvidados. Todo esto sucedió en silencio.
Por lo tanto, el descubrimiento de API es en realidad una carrera entre el proveedor de API y el atacante. Si los proveedores pueden descubrir los tipos anteriores de API antes que los atacantes, entonces pueden extraer metadatos de tráfico de API de puertas de enlace de API, balanceadores de carga y tráfico de red en línea directo, y a través de motores especializados, producir un informe de lista de API efectivo para compararlo con el catálogo de API disponible. en la capa de gestión de la API.
Las 10 principales amenazas de seguridad para la seguridad de las API de OWASP
Defectos en la autorización a nivel de objeto API1:2019
Por lo general, los puntos finales de la API explotan el plano de control de acceso al descubrir los identificadores de los objetos procesados. Necesitamos verificar la información proporcionada por el cliente una por una.
Fallas en la autenticación de usuario API2:2019
Los atacantes suelen utilizar los tokens obtenidos o las fallas de ejecución del sistema de verificación para hacerse pasar por usuarios legítimos y realizar operaciones ilegales.
API3:2019 Exposición excesiva de datos
Los atacantes pueden inferir los atributos relevantes de algunos elementos a través de llamadas API y datos obtenidos legalmente, y luego filtrar diversa información útil.
API4:2019 Recursos insuficientes y limitación actual
Generalmente, la API no impone restricciones de flujo o cantidad en los datos que se llaman. Esto deja una oportunidad para que los atacantes lancen ataques de acaparamiento de recursos, como la denegación de servicio (DoS).
Defectos en la autorización de nivel de función API5:2019
Algunas API están incompletas en políticas de control de acceso complejas e incluso tienen fallas de autorización. Esto permitirá a los atacantes obtener recursos que otros usuarios pueden llamar a través de llamadas a funciones.
API6: asignación de lotes 2019
Para mejorar la eficiencia, el modelo que proporciona información a los usuarios en forma de JSON a menudo proporciona una asignación masiva (Mass Assignment) sin una verificación de atributos legales basada en la lista de permisos específica. En base a esto, un atacante puede leer los documentos de apoyo cuidadosamente para inferir las propiedades del objeto, encontrar diferentes puntos finales de la API o descubrir propiedades adicionales en la carga útil de la solicitud y luego alterarlas.
Error de configuración de seguridad API7:2019
Los errores de configuración de seguridad a menudo provienen de un diseño predeterminado incompleto, orquestación irregular, almacenamiento distribuido abierto, encabezados HTTP no coincidentes, uso compartido de activos de origen cruzado suelto (intercambio de activos de origen cruzado, CORS) y la inclusión de aspectos confidenciales como mensajes de error extensos para datos.
Inyección API8:2019
La información maliciosa de un atacante podría engañar a las comprobaciones de entrada, aprovechar las fallas de SQL o NoSQL, ejecutar comandos maliciosos u obtener información sin la validación adecuada.
API9:2019 Gestión de activos inadecuada
Las API a menudo pueden descubrir más puntos finales que las aplicaciones web normales, lo que hace que sea aún más importante que la documentación adjunta se actualice correctamente. En este sentido, deberíamos seguir mejorando las tablas relevantes de la API y descubrir aquellos endpoints que no se han registrado a tiempo.
API10:2019 registro y monitoreo insuficientes
La falta de registro e inspección, combinada con capacidades de respuesta a incidentes insuficientes, puede poner las llamadas API en riesgo de ataque.
pruebas de penetración
Los desarrolladores pueden considerar el uso de los datos de prueba de API preconstruidos del agente de Postman para comunicarse directamente con la API. Al realizar pruebas de penetración rápida y repetidamente para las API, podemos obtener informes detallados y reducir los costos de las pruebas.
Dado que las pruebas de penetración requieren competencia en la API de destino e incluso en todo el sistema, es mejor contratar un equipo de seguridad capacitado o utilizar herramientas de código abierto para simular ataques contra la API. A través de pruebas de penetración regulares y continuas, los desarrolladores podrán encontrar soluciones de manera oportuna y consistente con el nivel de protección de la API.
12 mejores prácticas para la seguridad de API
De la discusión anterior, podemos ver que la seguridad de la API es crucial para el desarrollo de aplicaciones centradas en datos. Analicemos las mejores prácticas de seguridad para diferentes tipos y etapas de API.
1. Usa encriptación
Para evitar ataques de craqueo, debemos usar el protocolo de encriptación TLS para aquellas API que se usan para la comunicación interna y externa, e implementar la encriptación de extremo a extremo.
2. Certificación API
Como se mencionó anteriormente, la autenticación garantiza que la API no pueda ser utilizada directamente por extraños. Al mismo tiempo, a través de la clave API o la autenticación de acceso, podemos rastrear las llamadas de los recursos API. Por supuesto, tales medidas de seguridad también aumentan la dificultad de implementar el sistema.
3. Aproveche al máximo OAuth y OpenID Connect
La combinación de OAuth y OpenID Connect puede asumir la responsabilidad total de la autenticación y/o autorización de la API. Por ejemplo, en el proceso de autorización, tanto los consumidores como los proveedores de la API no realizan operaciones de autorización directamente, sino que usan OAuth como protocolo de delegación para agregar una capa de protección básica a la API y, sobre esta base, usan el estándar OpenID Connect como una capa de Identidad adicional, usando tokens de ID para extender OAuth2.0.
4. Expertos en seguridad
Con tantas prácticas de seguridad de API para elegir, es posible que sufra el "síndrome de elección". En este punto, los expertos en seguridad experimentados pueden guiarlo en la construcción de una sólida postura de seguridad de API con un sistema antivirus adecuado y un servidor ICAP (Protocolo de adaptación de contenido de Internet).
5. Monitoreo continuo, auditoría y registro
Como dice el refrán, más vale prevenir que curar. Podemos configurar los indicadores para que sean monitoreados y registrados al comienzo del diseño de la API y, durante el uso de los servicios de la aplicación, podemos rastrear las interacciones de la API a través de los paneles apropiados y revisar los registros relevantes y los mensajes de error de manera oportuna. Al mismo tiempo, en el proceso posterior de depuración y actualización de versiones, no olvide sincronizar todas las API.
6. Compartir solo información limitada
Recuerde, cuanta menos información comparta a través de una API, menos riesgo de seguridad plantea la propia API. Al mismo tiempo, también debe asegurarse de que se revele la menor cantidad de información posible en los mensajes de error.
Además, el uso de listas blancas y listas negras de direcciones IP es una excelente manera de limitar el acceso a los recursos de la API. Puede garantizar que solo el personal o las aplicaciones autorizados tengan acceso limitado a los recursos de la API y mantener oculta la información clave en la interfaz.
7. Limitación de corriente y protección de cuotas.
Limite razonablemente la cantidad limitada de mensajes para acceder a ciertas API de acuerdo con el sistema de back-end, el ancho de banda real y la capacidad del servidor, para prevenir de manera efectiva la amenaza de ataques DDoS.
8. Datos efectivos
El servidor debe verificar y verificar todo el contenido recibido dos veces. Cualquier contenido nuevo, grandes conjuntos de datos e información compartida por los consumidores debe verificarse. Actualmente, la validación de JSON y XML son dos de las herramientas más utilizadas para verificar la seguridad de los parámetros. Al mismo tiempo, también pueden controlar eventos como inyección SQL y bombas XML.
9. Infraestructura sólida
Al implementar las últimas tecnologías de red segura, nuevos servidores y software de equilibrio de carga, podemos mantener la API segura a nivel de infraestructura, haciéndola resistente a los ataques de exfiltración de grandes volúmenes de datos.
10. Siga OWASP Top 10
A través del análisis anterior, puede ver fácilmente que las diez principales amenazas de vulnerabilidad de API enumeradas e interpretadas por OWASP son algunas de las formas más comunes de impacto de ataque. Son extremadamente dañinos no solo para las páginas web, sino también para varias vulnerabilidades en las API. Por lo tanto, debemos hacer un buen trabajo de prevención a nivel de código por adelantado.
11. Utilice un cortafuegos API
Construir un firewall para su API tiene dos propósitos:
-
Se puede utilizar para realizar comprobaciones de seguridad básicas, como comprobar el tamaño del mensaje, la posibilidad de inyección SQL y si el ataque se puede bloquear de inmediato.
-
Puede integrarse en el sistema de protección existente dentro de la LAN para mejorar conjuntamente la situación general de seguridad.
12. Implementar API Gateway
Ya sea para uso de intranet o llamadas de red externa, el entorno en el que se ubican las API suele ser complejo y peligroso. Por lo tanto, para reducir la presión de administrar las API, podemos implementar un control, monitoreo y protección integrales del tráfico relacionado con las API mediante la implementación de puertas de enlace de API.