OWASP API Security Top 10 - Español (III)

El proyecto OWASP API Security Top 10 mantiene un documento de los 10 principales riesgos de seguridad en APIs, así como un portal de documentación para las mejores prácticas al crear o evaluar API.

En el primer post analizamos el objetivo del proyecto, en el segundo mostramos cuales son las primeras cinco vulnerabilidades y, a continuación, brindamos un resumen de las últimas cinco vulnerabilidades del Top 10.

👉 Ver primeras cinco vulnerabilidades 👈

API 6: Asignación masiva

La vinculación de datos proporcionados por el cliente (por ejemplo, JSON) a modelos de datos, sin un filtrado de propiedades adecuado basado en una lista blanca, generalmente conduce a una asignación masiva de datos. Adivinar las propiedades de los objetos, explorar otros end-point de la API, leer documentación o proporcionar propiedades de objetos adicionales en las cargas útiles de solicitud, permite a los atacantes modificar las propiedades de los objetos que no deberían hacerlo.

En aplicaciones modernas, los objetos pueden contener muchas propiedades que podrían ser actualizadas directamente por el cliente (por ejemplo, user.first_name o user.address) y otras no (por ejemplo, user.is_vip flag).

Ejemplo:

PUT /api/v1/users/me
{"user_name":"inons","age":24}

Un end-point de API es vulnerable si convierte automáticamente los parámetros del cliente en propiedades de objeto internas, sin tener en cuenta la sensibilidad y el nivel de exposición de estas propiedades. Esto podría permitir a un atacante actualizar las propiedades del objeto a las que no debería tener acceso.

Como prevenirlo

• Si es posible, evitar utilizar funciones que enlacen automáticamente la entrada de un cliente en variables u objetos internos.
• Incluir en una lista blanca solo las propiedades que el cliente pueda y deba actualizar.
• Utilizar las funciones integradas para incluir en la lista negra las propiedades a las que los clientes no deberían acceder.
• Si corresponde, definir explícitamente y forzar esquemas en datos de entrada.

API 7: Configuración incorrecta de seguridad

La configuración incorrecta de seguridad suele ser el resultado de configuraciones predeterminadas no seguras, configuraciones incompletas o ad-hoc, almacenamiento abierto en la nube, encabezados HTTP mal configurados, métodos HTTP innecesarios, uso compartido de recursos de origen cruzado permisivo (CORS) y mensajes de error detallados que contienen información confidencial.

Ejemplo:

$ curl -X GET 'https://api.server/endpoint/' -H 'authorization: Basic Zm9vOmJhcg=='

Como prevenirlo

• Se debe desarrollar un proceso de fortalecimiento (hardening) repetible que permita la implementación rápida y fácil de un entorno adecuadamente protegido.
• Revisar y actualizar configuraciones en toda la pila de API. La revisión debe incluir: archivos de orquestación, componentes de API y servicios en la nube (por ejemplo, permisos S3).
• Un canal de comunicación seguro para todos los activos estáticos (por ejemplo, imágenes y CSS).
• Incluir un proceso automatizado para evaluar continuamente la efectividad de la configuración y las configuraciones en todos los entornos.
• Evitar que se envíen excepciones y otra información valiosa a los atacantes y, si corresponde, definir y aplicar esquemas de respuestas de error.
• Asegurar de que solo los verbos HTTP especificados puedan acceder a la API. Todos los demás verbos HTTP deben estar deshabilitados (por ejemplo, HEAD).
• Las API que esperan acceder desde clientes basados ​​en el navegador (por ejemplo, front-end de WebApp) deben implementar una política adecuada de Cross-Origin Resource Sharing (CORS).

API 8: Inyección

Las inyecciones SQL, NoSQL, comandos, etc., ocurren cuando se envían datos no confiables a un intérprete como parte de un comando o consulta. Los datos maliciosos del atacante pueden engañar al intérprete para que ejecute comandos no deseados o acceda a los datos sin la autorización adecuada.

Ejemplo:

$ curl -k "https://${deviceIP}:4567/api/CONFIG/restore" -F 'appid=$(/etc/pod/power_down.sh)'

DELETE /api/bookings?bookingId[$ne]=678

Como prevenirlo

• La prevención de la inyección requiere mantener los datos separados de los comandos y consultas.
• Realizar la validación de datos utilizando una biblioteca única, confiable y mantenida activamente.
• Validar, filtrar y desinfectar todos los datos proporcionados por el cliente u otros datos provenientes de sistemas integrados.
• Los caracteres especiales se deben escapar utilizando la sintaxis específica para el intérprete de destino.
• Utilizar una API segura que proporcione una interfaz parametrizada.
• Siempre limitar el número de registros devueltos para evitar la divulgación masiva en caso de inyección.
• Validar los datos entrantes utilizando filtros suficientes para permitir solo valores válidos para cada parámetro de entrada.
• Definir tipos de datos y patrones estrictos para todos los parámetros de tipos de cadena.

API 9: Gestión de activos inapropiada

Las API tienden a exponer más end-points que las aplicaciones web tradicionales, lo que hace que la documentación adecuada y actualizada sea muy importante. Los hosts adecuados y el inventario de versiones de API implementadas también juegan un papel importante para mitigar problemas como versiones de API obsoletas y puntos finales de depuración expuestos.

Ejemplo:

api.someservice.com/v1
api.someservice.com/v2
api.someservice.com/v2

Como prevenirlo

• Hacer un inventario de todos los hosts de la API y documentar los aspectos importantes de cada uno de ellos, centrándose en el entorno de la API (por ejemplo, producción, test, desarrollo), quién debe tener acceso de red al host (por ejemplo, público, interno, socios) y versiones de la API
• Hacer un inventario de los servicios integrados y documentar aspectos importantes como su papel en el sistema, qué datos se intercambian (flujo de datos) y su sensibilidad.
• Documentar todos los aspectos de la API, como autenticación, errores, redireccionamientos, limitación de velocidad, política de intercambio de recursos de origen cruzado (CORS) y puntos finales, incluidos sus parámetros, solicitudes y respuestas.
• Generar documentación automáticamente mediante la adopción de estándares abiertos. Incluir la compilación de documentación en los procesos de CI/CD.
• Hacer que la documentación de la API esté disponible para aquellos autorizados a usar la API.
• Usar medidas de protección externas como los firewalls de seguridad de API para todas las versiones expuestas de la API, no solo para la versión de producción actual.
• Evitar utilizar datos de producción con implementaciones de API que no sean de producción. Si esto es inevitable, estos puntos finales deberían recibir el mismo tratamiento de seguridad que los de producción.
• Cuando las versiones más recientes de las API incluyan mejoras de seguridad, realizar un análisis de riesgos para tomar la decisión de las acciones de mitigación requeridas para la versión anterior: por ejemplo, si es posible respaldar las mejoras sin romper la compatibilidad hacia atrás de la API o si se necesita sacar la versión anterior rápidamente y obligar a todos los clientes a pasar a la última versión.

API 10: Registro y monitoreo insuficiente

El registro y el monitoreo insuficientes, junto con la integración faltante o ineficaz de la respuesta a incidentes, permite facilitar los ataques, mantener la persistencia, controlar y manipular más sistemas, extraer o destruir datos sin control, etc. La mayoría de los estudios de incumplimiento demuestran que el tiempo para detectar un incumplimiento es superior a 200 días, generalmente detectado por partes externas en lugar de procesos internos o monitoreo.

Como prevenirlo

• Registrar todos los intentos fallidos de autenticación, acceso denegado y errores de validación de entrada.
• Los registros deben escribirse usando un formato adecuado para ser consumido por una solución de administración de registros, y deben incluir suficientes detalles para identificar al actor malicioso.
• Los registros deben manejarse como datos confidenciales y su integridad debe garantizarse en reposo y tránsito.
• Configurar un sistema de monitoreo para monitorear continuamente la infraestructura, la red y el funcionamiento de la API.
• Utilizar un Security Information and Event Management (SIEM) para administrar registros de todos los componentes de la pila API y los hosts.
• Configurar paneles y alertas personalizados, lo que permite detectar actividades sospechosas y responder más rápido a los incidentes.

Licencia

¡Los documentos del Proyecto de Seguridad API OWASP son de uso gratuito!

El Proyecto de Seguridad API OWASP está licenciado bajo la licencia Creative Commons Attribution-ShareAlike 3.0, por lo que puede copiar, distribuir y transmitir el trabajo, y puede adaptarlo y usarlo comercialmente, siempre que atribuya el trabajo y si desea alterar, transformar o mejorar este trabajo, puede distribuirlo solo bajo la misma licencia o similar a esta.

Cristian de la Redacción de Segu-Info

Suscríbete a nuestro Boletín