Header Ads Widget

Ticker

6/recent/ticker-posts

Prueba de las 10 principales vulnerabilidades de seguridad de API de OWASP

 En comparación con las aplicaciones web, las pruebas de seguridad API tienen sus propias necesidades específicas. A continuación, cubrimos las principales vulnerabilidades inherentes a las API de hoy, como se documenta en la lista de vulnerabilidades de seguridad de las 10 API de OWASP . Proporcionaremos formas de probar y mitigar cada vulnerabilidad y veremos algunas herramientas básicas para automatizar las pruebas de seguridad de API.



Las API son vulnerables a los ataques

OWASP mantiene una lista de las diez principales vulnerabilidades de seguridad de API .

Primero, ¿qué tan vulnerables son las API? Considere una vulnerabilidad de API que permitió a los atacantes robar información confidencial perteneciente a The Nissan Motor Company. En 2016, se descubrió una vulnerabilidad en la API de la aplicación móvil de Nissan que enviaba datos a los automóviles Nissan Leaf. Un grupo de investigadores descubrió que al usar API, podría enviar comandos a cualquier vehículo si supiera su número de VIN.

La vulnerabilidad de la API de Nissan expuso el control del clima, la gestión de la batería y muchas otras funcionalidades del automóvil. Los piratas informáticos podían acceder al historial completo de los viajes de un automóvil, incluido el tiempo de la ruta, las coordenadas GPS exactas de la ruta si el conductor infringía las reglas de tráfico y otros puntos de datos confidenciales. La información privada como esta debe estar muy bien protegida, pero se expuso a través de la API.

Entonces, ¿qué lugar ocupan las API en nuestras vidas hoy? Según las estadísticas , en promedio, cada gran empresa utiliza alrededor de 420 servicios, y el 83% de todo el tráfico en Internet hoy pertenece a servicios basados ​​en API. Con la llegada de 5G y especialmente el Internet de las cosas, esperamos que el tráfico entre los servicios API y las aplicaciones solo crezca.

Hoy vivimos en un mundo de microservicios, contenedores y nubes. Los días de la arquitectura monolítica terminaron, lo que significa que debemos cambiar el enfoque de la seguridad que se estableció hace muchos años.

Como sabrá, OWASP publica los 10 informes de vulnerabilidades principales cada año para diferentes tipos de aplicaciones. Recientemente, OWASP lanzó su proyecto de seguridad de API , que enumera las 10 principales vulnerabilidades de API. Repasemos cada elemento de esta lista.

1. Autorización de nivel de objeto roto

La primera vulnerabilidad de nuestra lista es la autorización de nivel de objeto roto.
Digamos que un usuario genera un documento con ID = 322. Solo se les debe permitir el acceso a ese documento. Si especifica ID = 109 o alguna otra ID, el servicio debería devolver el error 403 (Prohibido).

En realidad, todo es un poco diferente. A menudo, no se comprueban los controles de acceso de todos los servicios. A menudo, puede cambiar el ID de un recurso y acceder a un documento con contenido destinado a otro usuario.

Para probar este problema, ¿con qué parámetros puede experimentar? Puede pasar cualquier ID en la URL o como parte de los parámetros de consulta o el cuerpo (en XML o JSON). Intente cambiarlos para ver qué le devuelve el servicio.

Desafortunadamente, no existen herramientas automáticas en las que pueda presionar un botón mágico y obtener un informe detallado. Hasta ahora, la autorización de nivel de objeto roto solo se puede probar manualmente. Puede utilizar las mismas herramientas con las que normalmente prueba las API como Postman , Fiddler , ReadyAPI . Entonces, envíe diferentes solicitudes y analice las respuestas.

Durante la primera ronda, debe definir estos casos manualmente. Más tarde, puede automatizarlos como parte de sus pruebas funcionales normales.

2. Autenticación de usuario rota

El segundo tipo de falla se llama Autenticación de usuario rota. Espero que conozca la diferencia entre autenticación y autorización . Todas las vulnerabilidades relacionadas con la autenticación suelen estar asociadas con mecanismos de gestión de contraseñas y mecanismos de inicio de sesión.

Para evitar la autenticación de usuario rota, las contraseñas deben ser largas (al menos, digamos ocho caracteres), incluidas letras mayúsculas y minúsculas, etc. También debe asegurarse de que sea imposible omitir el procedimiento de inicio de sesión y acceder a objetos o páginas sin estar autenticado. En este caso, el servicio debería devolver el 401 (no autorizado). También debe asegurarse de que no se pueda ejecutar un ataque de fuerza bruta, así como de que la función Olvidó la contraseña no le devuelva la contraseña en texto sin cifrar en un correo electrónico, etc.

Cuando los usuarios inician sesión en una aplicación, se les asigna un token de sesión único. Casi todas las vulnerabilidades asociadas con las sesiones están relacionadas con este token de sesión.

Aquí, puede probar si este token de sesión se reasigna después de cada procedimiento de inicio de sesión exitoso o después de que el nivel de acceso se escala en la aplicación. En caso de que su aplicación elimine o cambie de alguna manera el token de sesión, verifique si devuelve un error 401. No debemos permitir la posibilidad de predecir el token de sesión para cada sesión siguiente. Debe ser lo más aleatorio posible.

Además de trabajar con el procedimiento de inicio de sesión y los tokens de sesión, también es importante recordar que las API se comunican con el cliente (UI) y otras API. En estos escenarios, es común utilizar el token de sesión del cliente para una mayor comunicación. Sin embargo, los desarrolladores no siempre siguen esta práctica. A menudo utilizan cuentas de servicio especiales para la comunicación de API a API. Por lo tanto, la API puede tener acceso a más datos de los previstos.

Desafortunadamente, este tipo de vulnerabilidad no se puede detectar incluso si se utilizan pruebas de caja negra. Estas vulnerabilidades solo se encuentran durante la revisión del código o la revisión de la arquitectura.

Los problemas de seguridad de los usuarios fallidos también se pueden asociar con diferentes enfoques de autenticación. Hay autenticación básica y autenticación basada en notificaciones , y la aplicación puede implementar el inicio de sesión único.

Cada uno de estos mecanismos tiene su propio conjunto de vulnerabilidades y mejores prácticas. OWASP ofrece listas de verificación detalladas para cada uno de ellos. Los desarrolladores deben asegurarse de que los mecanismos de autenticación estén configurados y protegidos correctamente. Varias herramientas automatizadas pueden ayudarlo a probar los patrones de autenticación más comunes. Por ejemplo, para la autenticación básica, las herramientas de seguridad como Acunetix o Burp Suite pueden verificar que el token esté encriptado y que el hash sea correcto. Estas herramientas le proporcionarán un informe básico, que luego deberá analizar cuidadosamente.

3. Exposición excesiva de datos

El siguiente tipo de vulnerabilidad está relacionado con el hecho de que las API pueden devolver más datos de los que muestra la interfaz de usuario. Es decir, el filtrado de datos se realiza en la interfaz de usuario y no en el back-end.

Por ejemplo, tiene una interfaz que muestra tres campos: Nombre, Posición, Dirección de correo electrónico y Foto. Sin embargo, si observa la respuesta de la API, puede encontrar más datos, incluidos algunos datos confidenciales como la fecha de nacimiento o la dirección particular. El segundo tipo de exposición excesiva de datos ocurre cuando los datos de la interfaz de usuario y los datos de la API se devuelven correctamente, pero los parámetros se filtran en el front-end y no se verifican de ninguna manera en el back-end. Es posible que pueda especificar en la solicitud qué datos necesita, pero el back-end no verifica si realmente tiene permiso para acceder a esos datos.

Nuevamente, debe probar manualmente la Exposición Excesiva de Datos. Desafortunadamente, nada más que algunas herramientas comunes y sus habilidades lo ayudarán aquí. Debe analizar qué datos devuelve cada API y ver si devuelve más datos de los necesarios, y debe dar a los escenarios únicos la previsión adecuada.

Para ver un ejemplo de exposición excesiva de datos, considere la vulnerabilidad que se encuentra en GitLab. Tenían una API llamada API de eventos que devolvía una gran cantidad de datos en respuesta mientras filtraba en la interfaz de usuario. Se mostraban menos datos en la interfaz de usuario y se podía acceder a datos más confidenciales en la API.

4. Falta de recursos y limitación de tarifas

El siguiente tipo de vulnerabilidad está asociado con recursos insuficientes y límites de velocidad. La limitación de velocidad inadecuada es un tipo de vulnerabilidad que ocurre cuando una API no tiene límite en la cantidad de solicitudes que envía a otra API o un servidor.

Una estrategia simple para controlar esto es establecer que cada API no debe enviar más de N solicitudes por segundo. Sin embargo, esta estrategia no es del todo correcta. Si su cliente genera más tráfico que otro cliente, su API debería ser estable para todos los clientes.

Esto se puede resolver utilizando códigos de estado especiales, por ejemplo, 429(Demasiadas solicitudes). Con este código de estado, puede implementar alguna forma de limitación de tasa. También hay encabezados patentados especiales. Por ejemplo, GitHub usa su X-RateLimit-*Estos encabezados ayudan a regular cuántas solicitudes puede enviar el cliente durante una unidad de tiempo específica.

El segundo escenario está relacionado con el hecho de que es posible que no tenga suficientes comprobaciones de parámetros en la solicitud. Suponga que tiene una aplicación que devuelve una lista de tipos de usuarios como size = 10. ¿Qué sucede si un atacante cambia esto a 200000? ¿Puede la aplicación hacer frente a una solicitud tan grande?

Para encontrar vulnerabilidades que limitan la tasa, puede utilizar diferentes herramientas de fuzzing como JBroFuzz o Fuzzapi . O puede utilizar las mismas herramientas con las que analiza el tráfico.

5. Autorización de nivel de función rota

La siguiente vulnerabilidad tiene que ver con los niveles verticales de autorización: el usuario intenta obtener más derechos de acceso de los permitidos. Por ejemplo, un usuario normal que intenta convertirse en administrador. Para encontrar esta vulnerabilidad, primero debe comprender cómo se conectan los distintos roles y objetos de la aplicación. En segundo lugar, debe comprender claramente la matriz de acceso implementada en la aplicación.

Por ejemplo, supongamos que tiene un proyecto relacionado con la publicidad. Su aplicación tiene diferentes entidades como productos, usuarios, canales, etc. También tiene cinco opciones para ver la lista de anuncios, crear anuncios, eliminar anuncios, actualizar anuncios y obtener información sobre cada anuncio específico. Estas funciones requieren diferentes derechos de acceso. Por lo tanto, la aplicación tiene un usuario, un usuario autenticado, un administrador y un administrador.

¿Cómo puede encontrar errores y vulnerabilidades en esta situación? Puede probar el envío de una solicitud para eliminar un anuncio mientras está conectado como usuario normal (en lugar de administrador) para ver qué devuelve la API. Si la API devuelve 403 (Prohibido), entonces todo está bien. Sin embargo, si la API devuelve códigos doscientos como 200 (OK), 204 (Sin contenido) o 201 (Creado), entonces ha violado la matriz de control de acceso de alguna manera.

Hace varios años, se encontró una vulnerabilidad similar en Steam cuando un atacante potencial pudo extraer las claves de activación del juego. El investigador que encontró esta vulnerabilidad estaba experimentando y enviando solicitudes mientras estaba conectado como usuario. Después de experimentar con varios parámetros en el campo de solicitud, usó un "0"; de repente, el servicio Steam expuso la lista completa de claves del juego.

6. Asignación masiva

El siguiente tipo de vulnerabilidad se llama asignación masiva. Muchos marcos de desarrollo modernos intentan facilitar la vida de los desarrolladores al proporcionar funciones de asignación masiva convenientes (cuando se asignan parámetros de forma masiva).

Por ejemplo, digamos que tiene un fragmento de código donde hay un objeto Usuario al que se le asignan todos los parámetros pasados ​​desde la API o la IU:

def signup @user = User.create(params[:user])
# => User<email: “bob@spider.com”, password: “12345”, is_administrator: false>
end

Como puede ver arriba, puede pasar parámetros emailpasswordSin embargo, también tiene is_administrator, que, en teoría, debería asignarse automáticamente o formarse de alguna manera en el back-end. Si un atacante puede realizar una inyección HTML y establecer el is_administrator: true, cuando se ejecute este código, se le asignará junto con el resto de parámetros.

La implementación correcta de esto sería asignar cada parámetro por separado. Es decir, si usted quiere tomar sólo un correo electrónico y una contraseña, tome solamente emailpassworde indique explícitamente. Hacerlo equivale a muchas líneas de código similares con diferentes parámetros, lo que agrega complejidad para los desarrolladores. Afortunadamente, los nuevos marcos están simplificando esta carga, reduciendo así este tipo de vulnerabilidad.

7. Configuración incorrecta de seguridad

El siguiente tipo de vulnerabilidad está relacionado con la mala configuración de sus servidores web o API. ¿Qué puedes probar aquí? En primer lugar, los métodos HTTP innecesarios deben desactivarse en el servidor. No muestre ningún error de usuario innecesario. No entregue detalles técnicos del error al cliente. Si su aplicación utiliza Intercambio de recursos de origen cruzado (CORS), es decir, si permite que otra aplicación de un dominio diferente acceda a las cookies de su aplicación, estos encabezados deben configurarse adecuadamente para evitar vulnerabilidades adicionales. También se debe deshabilitar cualquier acceso a archivos internos. Hay encabezados de seguridad especiales, como Content-Security-Policy , que también puede implementar en sus aplicaciones para aumentar el nivel de seguridad.

8. Inyecciones

En los 10 principales riesgos de seguridad de aplicaciones web de OWASP, las inyecciones ocupan el primer lugar; sin embargo, las inyecciones ocupan el octavo lugar para los API. En mi opinión, esto se debe a que los marcos modernos, los métodos de desarrollo modernos y los patrones arquitectónicos nos bloquean de las inyecciones de SQL o XSS más primitivas. Por ejemplo, puede utilizar el modelo de mapeo relacional de objetos para evitar la inyección de SQL. Esto no significa que deba olvidarse en absoluto de las inyecciones. Estos problemas todavía son posibles en una gran cantidad de sitios y sistemas antiguos. Además de XSS y SQL, debe buscar inyecciones XML, inyecciones JSON, etc.

Puede probar las inyecciones con diferentes herramientas. Por ejemplo, ReadyAPI proporciona una herramienta de pago para el escaneo automático. Otros, como Burp Suite , son parcialmente gratuitos. O, si usa Postman en un proyecto, puede realizar pruebas de inyección básicas con Postman y pruebas basadas en datos.

9. Gestión inadecuada de activos

El siguiente tipo de vulnerabilidad está relacionado con la mala gestión de sus activos. Esta falla está creciendo a medida que los ingenieros adoptan DevOps, pruebas continuas y canalizaciones de CI / CD. Desde el punto de vista de la seguridad, es fundamental configurar correctamente estas canalizaciones de CI / CD.

Las canalizaciones de CI / CD tienen acceso a varios secretos y datos confidenciales, como las cuentas utilizadas para firmar el código. Asegúrese de no dejar secretos codificados de forma rígida en el código y de no "enviarlos" al repositorio, sin importar si es público o privado.

Cuando se utilizan máquinas virtuales, los contenedores se pueden crear mediante la canalización de CI / CD y los microservicios se pueden colocar en un contenedor separado. A lo largo de este proceso, asegúrese de no tener contenedores viejos que todos hayan olvidado, ya que podrían convertirse fácilmente en puntos de acceso adicionales.

10. Registro y supervisión insuficientes

El último tipo de vulnerabilidad tiene que ver con procedimientos insuficientes de registro y monitoreo. La idea principal aquí es que pase lo que pase con su aplicación, debe estar seguro de que puede rastrearla. Siempre debe tener registros que muestren con precisión lo que el atacante estaba tratando de hacer. Además, tenga sistemas para identificar el tráfico sospechoso, etc. Nuevamente, OWASP proporciona listas de verificación detalladas a las que hacer referencia para garantizar que su aplicación esté protegida.

El enfoque DevSecOps

Todas las vulnerabilidades discutidas anteriormente representan el resultado de medidas insuficientes o medidas que se tomaron demasiado tarde. Podría contratar a dos, cinco, diez expertos en seguridad, ejecutar su prueba de seguridad antes de cada lanzamiento y esperar que no encuentre vulnerabilidades críticas que lo obliguen a rediseñar, hacer refactorización global y luego ejecutar toneladas de pruebas de regresión. Sin embargo, hoy en día, cada vez más empresas intentan mover la seguridad (y todas las pruebas) hacia la izquierda en el ciclo de vida del desarrollo. Cuando empezamos a pensar en la seguridad desde el principio de nuestro proceso de desarrollo, lo llamamos DevSecOps .

Con una mentalidad de DevSecOps, analizamos los requisitos funcionales en términos de seguridad. Establecemos requisitos de seguridad adicionales para nuestra aplicación. Revisamos nuestros diagramas de implementación, arquitecturas y cualquier otro diagrama en un modelo de vista arquitectónica 4 + 1 . Modelamos amenazas y construimos escenarios en los que pensamos en qué tipos de vulnerabilidades pueden aparecer en la arquitectura, la infraestructura o la aplicación, y tratamos de predecirlas y prevenirlas. Escaneamos el código incluso antes de que llegue al maestro de la rama. Hay analizadores de código estático especiales que verifican el código de nuestros desarrolladores y el código de bibliotecas de terceros. Después de eso, puede hacer una prueba de seguridad utilizando las herramientas API mencionadas anteriormente.

Sus ingenieros deben verificar cuidadosamente todas las configuraciones de contenedores, nubes, canalizaciones de CI / CD y evitar las vulnerabilidades de API mencionadas anteriormente. Es necesario realizar capacitaciones frecuentes para el equipo del proyecto. También se recomienda que, una vez al año, involucre a empresas externas para realizar pruebas de penetración para asegurarse de que no se pierda nada.

Todos los desarrolladores y evaluadores deben estar al tanto de las nuevas vulnerabilidades a medida que aparecen y aprender regularmente cómo abordar la seguridad correctamente. DevSecOps es un enfoque difícil que requiere mucho tiempo, recursos y conocimiento, pero esta es la única forma de proteger sus aplicaciones correctamente.

La seguridad de la API trae preocupaciones únicas

Las pruebas de API requieren cierta mentalidad. Los evaluadores deben estar preparados para el hecho de que es posible que no tengan una interfaz de usuario. Deben estar preparados para diseñar diferentes solicitudes de servidor desde cero y comprender los encabezados de solicitud y respuesta. La documentación no siempre está actualizada. Por lo tanto, siempre es mejor monitorear el tráfico real para saber cómo se comporta una aplicación. Los probadores de API tienen que preguntarse constantemente a sí mismos como, "¿Qué pasa si hay otras versiones de esta API? ¿La API será diferente, por ejemplo, para una aplicación móvil y la web? " Si los evaluadores están realmente interesados ​​en proteger sus API, deben cultivar este tipo de mentalidad de seguridad.

Publicar un comentario

0 Comentarios