Hola hacketones! Bienvenidos a un nuevo CTF de la ruta completa de Web Fundamentals, en este capítulo veremos: TryHackMe OWASP API Security Top 10 – 1
Open Worldwide Application Security Project ( OWASP ) es una comunidad en línea colaborativa y sin fines de lucro que tiene como objetivo mejorar la seguridad de las aplicaciones a través de un conjunto de principios de seguridad, artículos, documentación, etc. En 2019, OWASP publicó una lista de las 10 principales vulnerabilidades de API , que se discutirán en detalle, junto con su impacto potencial y algunas medidas de mitigación efectivas.
Hemos dividido esta sala en dos partes. En la Parte 1 , estudiarás los 5 principios principales, y en la Parte 2 , aprenderás los principios restantes.
Objetivos de aprendizaje
- Mejores prácticas para la autorización y autenticación de API
- Identificación de problemas de nivel de autorización
- Manejo de la exposición excesiva de datos
- Falta de recursos y problemas de limitación de velocidad
Comprensión de las API: un repaso
¿Qué es una API y por qué es importante?
API significa Interfaz de Programación de Aplicaciones. Es un middleware que facilita la comunicación entre dos componentes de software mediante un conjunto de protocolos y definiciones. En el contexto de las API , el término » aplicación » se refiere a cualquier software con una funcionalidad específica, e » interfaz » al contrato de servicio entre dos aplicaciones que posibilita la comunicación mediante solicitudes y respuestas. La documentación de la API contiene toda la información sobre cómo los desarrolladores han estructurado dichas respuestas y solicitudes. La importancia de las API para el desarrollo de aplicaciones se resume en una sola frase: la API es un componente fundamental para el desarrollo de aplicaciones complejas y de nivel empresarial .
Violaciones de datos recientes a través de API
- Filtración de datos de LinkedIn: En junio de 2021, los datos de más de 700 millones de usuarios de LinkedIn se pusieron a la venta en un foro de la dark web, donde se extrajeron mediante la API de LinkedIn . El hacker publicó una muestra de un millón de registros para confirmar la legitimidad de la filtración, que contenía nombres completos de los usuarios, direcciones de correo electrónico, números de teléfono, registros de geolocalización, enlaces a perfiles de LinkedIn, información sobre su experiencia laboral y otros detalles de sus cuentas en redes sociales.
- Filtración de datos de Twitter: En junio de 2022, se publicaron a la venta en la dark web los datos de más de 5,4 millones de usuarios de Twitter . Los hackers llevaron a cabo la filtración explotando un día cero en la API de Twitter que comparó el nombre de usuario de Twitter con un número de teléfono móvil o correo electrónico.
- Filtración de datos de PIXLR: En enero de 2021, PIXLR, una aplicación de edición de fotos en línea, sufrió una filtración de datos que afectó a aproximadamente 1,9 millones de usuarios. Todos los datos de los hackers, incluidos nombres de usuario, direcciones de correo electrónico, países y contraseñas cifradas, se publicaron en un foro de la dark web.
Ahora que entendemos la amenaza y el daño causado por el incumplimiento de las medidas de mitigación, analicemos el desarrollo de una API segura a través de los 10 principios principales de seguridad de API de OWASP .
Responda las preguntas a continuación
En la violación de datos de LinkedIn (junio de 2021), ¿cuántos millones de registros (muestra) fueron publicados por un pirata informático en la red oscura?
1
¿La documentación de la API es un elemento trivial y no se utiliza después del desarrollo de la API (sí/no)?
nay
Vulnerabilidad I – Autorización a Nivel de Objeto Roto (BOLA)
¿Cómo sucede?
Generalmente, los puntos finales de API se utilizan para la práctica común de recuperar y manipular datos mediante identificadores de objetos. BOLA (Referencia Directa de Objetos Insegura ) crea un escenario en el que el usuario utiliza la funcionalidad de entrada y obtiene acceso a recursos a los que no está autorizado . En una API , estos controles suelen implementarse mediante programación en modelos (Arquitectura Modelo-Vista-Controlador) a nivel de código.
Impacto probable
La falta de controles para prevenir el acceso no autorizado a objetos puede provocar fugas de datos y, en algunos casos, el robo total de cuentas. Los datos de usuarios o suscriptores en la base de datos desempeñan un papel fundamental en la reputación de marca de una organización; si estos datos se filtran a través de internet, pueden ocasionar pérdidas financieras considerables.
Ejemplo práctico
- Abra la máquina virtual . Verá que el navegador Chrome y la aplicación Talend API Tester se ejecutan automáticamente, y que usaremos para depurar los puntos finales de la API .
- Bob trabaja como desarrollador de APICompany MHT y desarrolló un endpoint /apirule1/users/{ID} que permitirá a otras aplicaciones o desarrolladores solicitar información enviando el ID de un empleado. En la máquina virtual, se pueden solicitar resultados enviando GET solicitudes a http://localhost:80/MHT/apirule1_v/user/1.
- ¿Cuál es el problema con la llamada API anterior? El problema radica en que el punto final no valida ninguna llamada API entrante para confirmar la validez de la solicitud. No verifica si existe autorización para que la persona que solicita la llamada API pueda solicitarla o no.
- La solución para este problema es bastante simple; Bob implementará un mecanismo de autorización a través del cual podrá identificar quién puede realizar llamadas API para acceder a la información de identificación de los empleados.
- El objetivo se logra mediante tokens de acceso o tokens de autorización en el encabezado. En el ejemplo anterior, Bob añadirá un token de autorización para que solo los encabezados con tokens de autorización válidos puedan realizar una llamada a este endpoint.
- En la máquina virtual, si agrega un token válido Authorization-Tokeny llama a http://localhost:80/MHT/apirule1_s/user/1, solo entonces podrá obtener los resultados correctos. Además, todas las llamadas a la API con un token no válido mostrarán 403 Forbiddenun mensaje de error (como se muestra a continuación).
Medidas de mitigación
- Se debe implementar adecuadamente un mecanismo de autorización que se base en políticas y jerarquías de usuarios.
- Métodos estrictos de control de acceso para verificar si el usuario que inició sesión está autorizado a realizar acciones específicas.
- Promover el uso de valores completamente aleatorios (mecanismo de cifrado y descifrado fuerte) para tokens casi imposibles de predecir.
Promover el uso de valores completamente aleatorios (mecanismo de cifrado y descifrado fuerte) para tokens casi imposibles de predecir.
Responda las preguntas a continuación
Supongamos que el ID del empleado es un entero con valor creciente. ¿Puedes verificar el número total de empleados de la empresa a través del endpoint API vulnerable?
3
¿Cuál es la bandera asociada con el ID de empleado 2?
THM{838123}
¿Cuál es el nombre de usuario del empleado ID 3?
bob
Vulnerabilidad II: Autenticación de usuario rota (BUA)
¿Cómo sucede?
La autenticación de usuarios es fundamental para el desarrollo de cualquier aplicación que contenga datos confidenciales. La autenticación de usuarios fallida (BUA) refleja un escenario en el que un endpoint de API permite a un atacante acceder a una base de datos o adquirir un privilegio superior al existente. La razón principal de la BUA es una implementación incorrecta de la autenticación (como el uso de consultas de correo electrónico o contraseña incorrectas, etc.) o la ausencia de mecanismos de seguridad como encabezados de autorización y tokens.
Imaginemos un escenario en el que un atacante obtiene la capacidad de abusar de una API de autenticación ; esto eventualmente resultará en fugas de datos, eliminación, modificación o incluso la apropiación total de la cuenta. Normalmente, los hackers crean scripts especiales para perfilar, enumerar usuarios en un sistema e identificar endpoints de autenticación. Un sistema de autenticación mal implementado puede llevar a cualquier usuario a suplantar la identidad de otro.
Impacto probable
En una autenticación de usuario deficiente, los atacantes pueden comprometer la sesión autenticada o el mecanismo de autenticación y acceder fácilmente a datos confidenciales. Los actores maliciosos pueden hacerse pasar por alguien autorizado y realizar actividades no deseadas, como el robo total de cuentas.
Ejemplo práctico
- Continúe usando el navegador Chrome y Talend API Tester para la depuración en la máquina virtual .
- Bob entiende que la autenticación es fundamental y se le ha encomendado desarrollar un punto final de APIapirule2/user/login_v que autenticará en función del correo electrónico y la contraseña proporcionados.
- El endpoint devolverá un token, que se pasará como Authorization-Tokenencabezado (solicitud GET) paraapirule2/user/details mostrar los detalles del empleado específico. Bob desarrolló correctamente el endpoint de inicio de sesión; sin embargo, solo usó el correo electrónico para validar al usuario user tablee ignoró el campo de contraseña en la consulta SQL. Un atacante solo necesita la dirección de correo electrónico de la víctima para obtener un token válido o para obtener el control de la cuenta.
- En la VM, puedes probar esto enviando una POST solicitud http://localhost:80/MHT/apirule2/user/login_v con correo electrónico y contraseña en los parámetros del formulario.
- Como podemos ver, el punto final vulnerable recibió un token que puede reenviarse /apirule2/user/detailspara obtener detalles de un usuario.
- Para solucionar esto, actualizaremos la lógica de consulta de inicio de sesión y usaremos tanto el correo electrónico como la contraseña para la validación. El punto final /apirule2/user/login_ses válido, como se muestra a continuación, y autoriza al usuario basándose tanto en la contraseña como en el correo electrónico.
Medidas de mitigación
- Asegúrese de que sus contraseñas sean complejas y tengan mayor entropía para los usuarios finales.
- No exponga credenciales confidenciales en solicitudes GET o POST .
- Habilite tokens web JSON (JWT) fuertes , encabezados de autorización, etc.
- Asegúrese de implementar la autenticación multifactor (cuando sea posible), el bloqueo de cuentas o un sistema captcha para mitigar la fuerza bruta contra usuarios particulares.
- Asegúrese de que las contraseñas no se guarden en texto sin formato en la base de datos para evitar que el atacante vuelva a tomar control de la cuenta.
Responda las preguntas a continuación
¿Puedes encontrar el token de hr@mht.com?
cOC%Aonyis%H)mZ&uJkuI?_W#4&m>Y
¿A qué país pertenece sales@mht.com?
China
¿Es una buena práctica enviar un nombre de usuario y una contraseña en una solicitud GET (sí/no)?
nay
Vulnerabilidad III: Exposición excesiva de datos
¿Cómo sucede?
La exposición excesiva de datos ocurre cuando las aplicaciones tienden a revelar más información de la deseada al usuario a través de una respuesta de API . Los desarrolladores de aplicaciones suelen exponer todas las propiedades de los objetos (considerando las implementaciones genéricas) sin considerar su nivel de sensibilidad. Dejan la tarea de filtrado al desarrollador front-end antes de que se muestre al usuario. En consecuencia, un atacante puede interceptar la respuesta a través de la API y extraer rápidamente los datos confidenciales deseados. Las herramientas de detección en tiempo de ejecución o las herramientas generales de análisis de seguridad pueden alertar sobre este tipo de vulnerabilidad. Sin embargo, no pueden diferenciar entre los datos legítimos que se supone que deben devolverse y los datos sensibles.
Impacto probable
Un agente malicioso puede rastrear el tráfico con éxito y acceder fácilmente a datos confidenciales, incluyendo información personal como números de cuenta, números de teléfono, tokens de acceso y mucho más. Normalmente, las API responden con tokens confidenciales que pueden usarse posteriormente para realizar llamadas a otros endpoints críticos.
Ejemplo práctico
- Continúe usando el navegador Chrome y Talend API Tester para la depuración en la máquina virtual .
- La empresa MHT lanzó un portal web basado en comentarios que toma los comentarios de los usuarios y los almacena en la base de datos junto con otra información como ubicación, información del dispositivo, etc., para mejorar la experiencia del usuario.
- A Bob se le encargó desarrollar un endpoint para mostrar los comentarios de los usuarios en el sitio web principal de la empresa. Desarrolló un endpoint apirule3/comment_v/{id} que extrae toda la información disponible sobre un comentario de la base de datos. Bob asumió que el desarrollador frontend filtraría la información al mostrarla en el sitio web principal de la empresa.
- ¿Cuál es el problema? La API envía más datos de los deseados. En lugar de confiar en un ingeniero front-end para filtrarlos, solo se deben enviar los datos relevantes desde la base de datos.
- Bob, al darse cuenta de su error, actualizó el punto final y creó un punto final válido /apirule3/comment_s/{id} que devuelve solo la información necesaria al desarrollador (como se muestra a continuación).
Medidas de mitigación
- Nunca deje tareas de filtración de datos confidenciales al desarrollador front-end.
- Asegúrese de revisar periódicamente la respuesta de la API para garantizar que devuelva solo datos legítimos y verifique si plantea algún problema de seguridad.
- Evite utilizar métodos genéricos como to_string() and to_json().
- Utilice la prueba de puntos finales de API a través de varios casos de prueba y verifique mediante pruebas automatizadas y manuales si la API filtra datos adicionales.
Responda las preguntas a continuación
¿Cuál es el valor del ID del dispositivo para el post-ID 2?
iOS15.411
¿Cuál es el valor del nombre de usuario para el ID de publicación 3?
hacker#!
¿Deberíamos utilizar dispositivos a nivel de red para controlar la exposición excesiva de datos en lugar de gestionarla a través de API (programáticamente) – (sí/no)?
nay
Vulnerabilidad IV: Falta de recursos y limitación de velocidad
¿Cómo sucede?
La falta de recursos y la limitación de velocidad implican que las API no imponen ninguna restricción sobre la frecuencia con la que los clientes solicitan recursos ni sobre el tamaño de los archivos, lo que afecta gravemente el rendimiento del servidor API y provoca una denegación de servicio ( DoS ) o la indisponibilidad del servicio. Imaginemos un escenario en el que no se aplica un límite de API , lo que permite a un usuario (normalmente un intruso) cargar varios GB de archivos simultáneamente o realizar cualquier número de solicitudes por segundo. Estos endpoints API provocarán un uso excesivo de recursos de red, almacenamiento, computación, etc.
Hoy en día, los atacantes utilizan este tipo de ataques para garantizar la indisponibilidad del servicio de una organización , dañando así la reputación de la marca al aumentar el tiempo de inactividad. Un ejemplo sencillo es el incumplimiento del sistema Captcha en el formulario de inicio de sesión, que permite a cualquiera realizar numerosas consultas a la base de datos mediante un pequeño script escrito en Python.
Impacto probable
El ataque apunta principalmente a los principios de seguridad de disponibilidad ; sin embargo, puede dañar la reputación de la marca y causar pérdidas financieras.
Ejemplo práctico
- Continúe usando el navegador Chrome y Talend API Tester para la depuración en la máquina virtual .
- La empresa MHT adquirió un plan de marketing por correo electrónico (20 000 correos electrónicos al mes) para enviar marketing, correos electrónicos de recuperación de contraseña, etc. Bob se dio cuenta de que había desarrollado con éxito una API de inicio de sesión , pero debe haber una opción de «Olvidé mi contraseña» que pueda usarse para recuperar una cuenta.
- Comenzó a construir un endpoint /apirule4/sendOTP_vque enviará un código numérico de 4 dígitos a la dirección de correo electrónico del usuario. Un usuario autenticado usará esa contraseña de un solo uso (OTP) para recuperar la cuenta.
- ¿Cuál es el problema? Bob no ha habilitado ninguna limitación de velocidad en el endpoint. Un atacante malicioso podría escribir un pequeño script y forzar el endpoint, enviando muchos correos electrónicos en segundos y utilizando el plan de email marketing recientemente adquirido por la empresa (pérdida financiera).
- Finalmente, Bob ideó una solución inteligente (/apirule4/sendOTP_s)y habilitó la limitación de velocidad tal que el usuario tiene que esperar 2 minutos para solicitar nuevamente un token OTP.
Medidas de mitigación
- Asegúrese de utilizar un captcha para evitar solicitudes de scripts automatizados y bots.
- Garantizar la implementación de un límite, es decir, la frecuencia con la que un cliente puede llamar a una API dentro de un tiempo específico y notificar instantáneamente cuando se excede el límite.
- Asegúrese de definir el tamaño máximo de datos en todos los parámetros y cargas útiles, es decir, la longitud máxima de la cadena y el número máximo de elementos de la matriz.
Responda las preguntas a continuación
¿Se puede realizar una limitación de velocidad a nivel de red a través del firewall, etc. (sí/no)?
yea
¿Cuál es el código de respuesta HTTP cuando envías una solicitud POST a /apirule4/sendOTP_s utilizando la dirección de correo electrónico hr@mht.com?
200
¿Cuál es el valor de la «clave msg» después de una solicitud HTTP POST a /apirule4/sendOTP_s utilizando la dirección de correo electrónico sale@mht.com?
Invalid Email
Vulnerabilidad V – Autorización de nivel de función rota
¿Cómo sucede?
La autorización de nivel de función errada refleja un escenario en el que un usuario con pocos privilegios (p. ej., el de ventas) elude las comprobaciones del sistema y obtiene acceso a datos confidenciales haciéndose pasar por un usuario con muchos privilegios (administrador) . Consideremos un escenario con políticas de control de acceso complejas con diversas jerarquías, roles y grupos, y una separación imprecisa entre funciones regulares y administrativas, lo que genera graves fallos de autorización. Al aprovecharse de estos problemas, los intrusos pueden acceder fácilmente a los recursos no autorizados de otro usuario o, lo que es aún más peligroso, a las funciones administrativas.
La autorización de nivel de función interrumpida refleja el permiso IDOR , donde un usuario, probablemente un intruso, puede realizar tareas administrativas. Las API con roles de usuario complejos y permisos que abarcan toda la jerarquía son más propensas a este ataque.
Impacto probable
El ataque se centra principalmente en los principios de seguridad de autorización y no repudio. Una autorización de nivel funcional vulnerada puede llevar a un intruso a suplantar la identidad de un usuario autorizado y permitirle obtener permisos administrativos para realizar tareas confidenciales.
Ejemplo práctico
- Continúe usando el navegador Chrome y Talend API Tester para la depuración en la máquina virtual .
- A Bob se le ha asignado otra tarea: desarrollar un panel de administración para los ejecutivos de la empresa, para que puedan ver todos los datos de los empleados y realizar tareas específicas.
- Bob desarrolló un endpoint /apirule5/users_vpara obtener los datos de todos los empleados de la base de datos. Para mayor protección, añadió una capa adicional de seguridad añadiendo un encabezado especial isAdmina cada solicitud. La API solo obtiene la información de los empleados de la base de datos si isAdmin=1y Authorization-Tokenson correctos. El token de autorización para la usuaria de RR. HH. Alice es YWxpY2U6dGVzdCFAISM6Nzg5Nzg= .
- Podemos ver que Alice es un usuario no administrador (RR. HH.) pero puede ver todos los datos de los empleados configurando solicitudes personalizadas en el punto final con isAdmin value = 1.
- El problema se puede resolver programáticamente implementando reglas de autorización correctas y verificando los roles funcionales de cada usuario en la base de datos durante la consulta. Bob implementó otro endpoint /apirule5/users_sque valida el rol de cada usuario y solo muestra los datos de los empleados si el rol es de administrador.
Medidas de mitigación
- Garantizar el diseño y las pruebas adecuados de todos los sistemas de autorización y denegar todo acceso de forma predeterminada.
- Asegúrese de que las operaciones sólo estén permitidas a los usuarios que pertenecen al grupo autorizado.
- Asegúrese de revisar los puntos finales de la API para detectar fallas con respecto a la autorización a nivel funcional y tenga en cuenta la lógica comercial de la jerarquía de aplicaciones y grupos.
Responda las preguntas a continuación
¿Cuál es el número de móvil del nombre de usuario Alice?
+1235322323
¿Es una buena práctica enviar el valor isAdmin a través de los campos ocultos en las solicitudes de formulario? ¿Sí/no?
Nay
¿Cuál es la bandera de dirección del nombre de usuario admin?
THM{3432$@#2!}
Eso es todo por esta sala. En esta sala, hemos estudiado los principios básicos del desarrollo de API para la Autorización y la Autenticación, y cómo la exposición excesiva de datos puede provocar el robo total de cuentas.
Ahora, nos veremos en la Parte 2 de esta sala, donde repasaremos los cinco principios restantes de la seguridad de la API de OWASP .
Sigan entrenando, Hacketones, Nos vemos en el próximo laboratorio!!!