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 – 2
Vulnerabilidad VI – Asignación masiva
¿Cómo sucede?
La asignación masiva refleja un escenario en el que los datos del cliente se vinculan automáticamente con objetos o variables de clase del servidor . Sin embargo, los hackers aprovechan esta función comprendiendo primero la lógica de negocio de la aplicación y enviando datos especialmente diseñados al servidor, obteniendo acceso administrativo o insertando datos manipulados. Esta funcionalidad se explota ampliamente en los frameworks más recientes, como Laravel, Code Ignitor, etc.
Considere el panel de perfiles de un usuario , donde los usuarios pueden actualizar su perfil, como su correo electrónico, nombre, dirección, etc. El nombre de usuario es un atributo de solo lectura y no se puede modificar; sin embargo, un atacante malicioso puede editarlo y enviar el formulario. Si el filtrado necesario no está habilitado en el servidor (modelo), simplemente se insertarán o actualizarán los datos en la base de datos.
Impacto probable
El ataque puede provocar la manipulación de datos y la escalada de privilegios de un usuario normal a un administrador.
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 .
- A Bob se le ha asignado el desarrollo de un punto final de API/apirule6/user de registro que aceptará un nombre, un nombre de usuario y una contraseña como parámetros de entrada (POST). La tabla del usuario tiene un credit columnvalor predeterminado de 50. Los usuarios actualizarán su membresía para obtener un mayor valor de crédito.
- Bob diseñó con éxito el formulario y utilizó la función de asignación masiva en Laravel para almacenar todos los datos entrantes del lado del cliente a la base de datos (como se muestra a continuación).
- ¿Cuál es el problema? Bob no está realizando ningún filtrado en el servidor. Desde que usa la función de asignación masiva , también está insertando valores de crédito en la base de datos (los atacantes pueden actualizar ese valor).
- La solución al problema es bastante sencilla. Bob debe garantizar el filtrado necesario en el servidor ( apirule6/user_s) y que el valor predeterminado de crédito se inserte como 50, incluso si se recibe más de 50 del cliente (como se muestra a continuación).
Medidas de mitigación
- Antes de usar cualquier framework, es necesario estudiar cómo se realizan las inserciones y actualizaciones del backend. En el framework Laravel, los arrays rellenables y protegidos mitigan los escenarios mencionados.
- Evite utilizar funciones que vinculen una entrada de un cliente a variables de código automáticamente.
- Permitir únicamente aquellas propiedades que necesitan actualizarse desde el lado del cliente.
Responda las preguntas a continuación
¿Es una buena práctica insertar o actualizar a ciegas los datos proporcionados por el usuario en la base de datos (sí/no)?
nay
Usando /apirule6/user_s, inserte un registro en la base de datos usando el valor de crédito como 1000.
No se necesita respuesta
¿Cuál sería el valor del crédito devuelto después de realizar la pregunta n.° 2?
50
Vulnerabilidad VII – Configuración incorrecta de seguridad
¿Cómo sucede?
Una configuración incorrecta de seguridad se refiere a la implementación de controles de seguridad incorrectos y mal configurados que ponen en riesgo la seguridad de toda la API . Diversos factores pueden provocar una configuración incorrecta de seguridad, como una configuración predeterminada incorrecta o incompleta, el almacenamiento en la nube de acceso público, el uso compartido de recursos entre orígenes ( CORS ) y la visualización de mensajes de error con datos confidenciales. Los intrusos pueden aprovechar estas configuraciones incorrectas para realizar un reconocimiento detallado y obtener acceso no autorizado al sistema.
Las configuraciones de seguridad incorrectas suelen detectarse mediante escáneres de vulnerabilidades o herramientas de auditoría, por lo que pueden reducirse desde el principio. La documentación de la API , la lista de endpoints, los registros de errores, etc., no deben ser de acceso público para garantizar la seguridad contra configuraciones incorrectas. Normalmente, las empresas implementan controles de seguridad como firewalls de aplicaciones web, que no están configurados para bloquear solicitudes y ataques no deseados.
Impacto probable
Una configuración de seguridad incorrecta puede proporcionar a los intrusos un conocimiento completo de los componentes de la API . En primer lugar, les permite eludir los mecanismos de seguridad. El seguimiento de la pila u otros errores detallados pueden proporcionar al atacante acceso a datos confidenciales y detalles esenciales del sistema, lo que le ayuda a perfilar el sistema y acceder a él.
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 enfrenta graves problemas de disponibilidad de servidores. Por lo tanto, le asignaron a Bob el desarrollo de un punto final de API/apirule7/ping_v (GET) que compartirá información sobre el estado del servidor.
- Bob diseñó con éxito el punto final; sin embargo, olvidó implementar algún manejo de errores para evitar fugas de información.
- ¿Cuál es el problema? En caso de una llamada fallida, el servidor envía un seguimiento de pila completo como respuesta, que contiene nombres de funciones, información del controlador y la ruta, la ruta del archivo, etc. Un atacante puede usar esta información para perfilar y preparar ataques específicos contra el entorno.
- La solución al problema es bastante sencilla. Bob creará un punto final de API /apirule7/ping_s que gestionará los errores y solo compartirá la información deseada con el usuario (como se muestra a continuación).
Medidas de mitigación
- Limite el acceso a las interfaces administrativas para los usuarios autorizados y deshabilítelas para los demás usuarios.
- Deshabilite los nombres de usuario y contraseñas predeterminados para los dispositivos públicos (enrutadores, firewall de aplicaciones web , etc.).
- Deshabilite la lista de directorios y establezca los permisos adecuados para cada archivo y carpeta.
- Elimine fragmentos de código innecesarios, registros de errores, etc. y desactive la depuración mientras el código esté en producción.
Responda las preguntas a continuación
¿Es un enfoque excelente mostrar registros de errores del seguimiento de la pila a los visitantes generales (sí/no)?
nay
Intente utilizar la llamada API /apirule7/ping_s en la VM adjunta.
No se necesita respuesta
¿Qué es el código de respuesta HTTP?
500
¿Cuál es el número de identificación de error en el mensaje de respuesta HTTP?
1401
Vulnerabilidad VIII – Inyección
¿Cómo sucede?
Los ataques de inyección se encuentran probablemente entre los ataques más antiguos contra API /web, y aún son perpetrados por hackers en aplicaciones reales. Las fallas de inyección ocurren cuando la entrada del usuario no se filtra y es procesada directamente por una API , lo que permite al atacante realizar acciones no deseadas en la API sin autorización. Una inyección puede provenir de lenguaje de consulta estructurado ( SQL ) , comandos del sistema operativo ( SO ), lenguaje de marcado extensible ( XML ), etc. Actualmente, los frameworks ofrecen funciones de protección contra este ataque mediante la limpieza automática de datos; sin embargo, las aplicaciones desarrolladas con frameworks personalizados, como PHP, siguen siendo susceptibles a estos ataques.
Impacto probable
Las fallas de inyección pueden provocar la divulgación de información, la pérdida de datos, ataques de denegación de servicio (DoS) y la apropiación total de cuentas . Los ataques de inyección exitosos también pueden permitir que los intrusos accedan a datos confidenciales o incluso creen nuevas funciones y ejecuten código de forma remota.
Ejemplo práctico
- Continúe usando el navegador Chrome y Talend API Tester para la depuración en la máquina virtual .
- Algunos usuarios de la empresa MHT informaron que la contraseña de su cuenta había cambiado y no podían iniciar sesión en su cuenta original. Por consiguiente, el equipo de desarrollo descubrió que Bob había desarrollado un endpoint API/apirule8/user/login_v de inicio de sesión vulnerable que no filtra la información del usuario.
- Un atacante malicioso requiere el nombre de usuario del objetivo y, a cambio, la contraseña; puede usar la carga útil ‘ OR 1=1–‘ y obtener una clave de autorización para cualquier cuenta (como se muestra a continuación).
- Bob se dio cuenta inmediatamente de su error; actualizó el punto final de la API /apirule8/user/login_sy utilizó consultas parametrizadas y filtros integrados de Laravel para desinfectar la entrada del usuario.
- Como resultado, todas las cargas maliciosas en los parámetros de nombre de usuario y contraseña se mitigaron de manera efectiva (como se muestra a continuación).
Medidas de mitigación
- Asegúrese de utilizar una biblioteca conocida para la validación de entrada del lado del cliente.
- Si no se utiliza un marco, todos los datos proporcionados por el cliente deben validarse primero y luego filtrarse y desinfectarse.
- Agregue las reglas de seguridad necesarias al firewall de aplicaciones web (WAF). Generalmente, las fallas de inyección se pueden mitigar a nivel de red.
- Utilice filtros integrados en marcos como Laravel, Code Ignitor, etc., para validar y filtrar datos.
Responda las preguntas a continuación
¿Se pueden realizar ataques de inyección para extraer datos de la base de datos (sí/no)?
yea
¿Pueden los ataques de inyección resultar en ejecución remota de código (sí/no)?
yea
¿Cuál es el código de respuesta HTTP si un usuario ingresa un nombre de usuario o contraseña no válidos?
403
Vulnerabilidad IX: Gestión inadecuada de activos
¿Cómo sucede?
La gestión inadecuada de activos se refiere a un escenario en el que tenemos dos versiones de una API disponibles en nuestro sistema ; las llamaremos APIv1 y APIv2. Todo está migrando completamente a APIv2, pero la versión anterior, APIv1, aún no se ha eliminado. Considerando esto, es fácil suponer que la versión anterior de la API , es decir, APIv1, no cuenta con las funciones de seguridad más recientes. Muchas otras funciones obsoletas de APIv1 permiten detectar escenarios vulnerables que pueden provocar fugas de datos y la toma de control del servidor mediante una base de datos compartida entre las versiones de la API .
Se trata básicamente de un seguimiento inadecuado de los puntos finales de la API . Las posibles razones podrían ser una documentación incompleta de la API o la falta de cumplimiento del Ciclo de Vida del Desarrollo de Software . Un inventario de API actualizado y bien mantenido, así como una documentación adecuada, son más cruciales que el control de seguridad basado en hardware para una organización.
Impacto probable
Las versiones de API más antiguas o sin parches pueden permitir que los intrusos obtengan acceso no autorizado a datos confidenciales o incluso control total del sistema.
Ejemplo práctico
- Continúe usando el navegador Chrome y Talend API Tester para la depuración en la máquina virtual .
- Durante el desarrollo de la API , la empresa MHT desarrolló diferentes versiones, como la v1 y la v2. Se aseguró de usar las versiones y llamadas API más recientes , pero olvidó eliminar la versión anterior del servidor.
- En consecuencia, se descubrió que las llamadas APIapirule9/v1/user/login antiguas devuelven más información, como saldo, dirección, etc., al usuario (como se muestra a continuación).
- Bob, como desarrollador del punto final, se dio cuenta de que debía desactivar inmediatamente los activos antiguos y no utilizados para que los usuarios solo pudieran acceder a información limitada y deseada desde el nuevo punto final /apirul9/v2/user/login(como se muestra a continuación).
Medidas de mitigación
- El acceso a llamadas API obsoletas y confidenciales desarrolladas previamente debe bloquearse a nivel de red.
- Las API desarrolladas para I+D, control de calidad, producción, etc., deben estar segregadas y alojadas en servidores separados.
- Asegúrese de documentar todos los aspectos de la API , incluida la autenticación, las redirecciones, los errores, la política CORS y la limitación de velocidad.
- Adoptar estándares abiertos para generar documentación automáticamente.
Responda las preguntas a continuación
¿Es una buena práctica alojar todas las API en el mismo servidor (sí/no)?
nay
Realice una llamada API a /apirule9/v1/user/login utilizando el nombre de usuario » Alice » y la contraseña » ##!@#!! «.
No se necesita respuesta
¿Cuál es la cantidad de saldo asociado al usuario Alice?
100
¿Cual es el país del usuario Alice?
USA
Vulnerabilidad X: Registro y monitoreo insuficientes
¿Cómo sucede?
Un registro y monitoreo insuficientes reflejan un escenario en el que un atacante realiza una actividad maliciosa en su servidor; sin embargo, cuando intenta rastrear al hacker, no hay suficiente evidencia disponible debido a la ausencia de mecanismos de registro y monitoreo . Varias organizaciones solo se enfocan en el registro de infraestructura como eventos de red o registro de servidor, pero carecen de registro y monitoreo de API . Información como la dirección IP del visitante, los puntos finales accedidos, los datos de entrada, etc., junto con una marca de tiempo, permite la identificación de patrones de ataque de amenazas. Si no se implementan mecanismos de registro, sería difícil identificar al atacante y sus detalles. Hoy en día, los marcos web más recientes pueden registrar automáticamente las solicitudes en diferentes niveles como error, depuración, información, etc. Estos errores se pueden registrar en una base de datos o archivo o incluso pasar a una solución SIEM para un análisis detallado.
Impacto probable
Incapacidad de identificar al atacante o al hacker detrás del ataque.
Ejemplo práctico
- Continúe usando el navegador Chrome y Talend API Tester para la depuración en la máquina virtual .
- Anteriormente, la empresa MHT ha sido susceptible a múltiples ataques, sin que se haya podido identificar al responsable exacto. Por lo tanto, se le asignó a Bob la tarea de crear un punto final de API/apirule10/logging (GET) que registrará los metadatos de los usuarios (dirección IP, versión del navegador, etc.) y los guardará en la base de datos (como se muestra a continuación).
- Posteriormente también se decidió que lo mismo se enviaría a una solución SIEM para su correlación y análisis.
Medidas de mitigación
- Garantizar el uso del sistema de Gestión de Información de Seguridad y Eventos ( SIEM ) para la gestión de registros.
- Realice un seguimiento de todos los accesos denegados, intentos de autenticación fallidos y errores de validación de entrada, utilizando un formato importado por SIEM y suficientes detalles para identificar al intruso.
- Trate los registros como datos confidenciales y garantice su integridad en reposo y en tránsito. Además, implemente alertas personalizadas para detectar actividades sospechosas.
Responda las preguntas a continuación
¿Los registros de la API deberían ser accesibles públicamente para que el atacante sepa que están siendo registrados (sí/no)?
nay
¿Cuál es el código de respuesta HTTP en caso de registro exitoso de la información del usuario?
200
Conclusión
Uf. Eso fue simple. Sería correcto decir que más de la mitad de la lista de los 10 principales problemas de seguridad de API de OWASP está relacionada con la autorización y la autenticación . Lo más común es que los sistemas API sean atacados por fallos en los mecanismos de autorización y autenticación, así como por configuraciones de seguridad incorrectas.
En resumen, los desarrolladores de API deben protegerlas de acuerdo con las mejores prácticas de ciberseguridad . Módulos como el inicio de sesión, el acceso basado en roles y la configuración del perfil de usuario, entre otros, deben tener mayor importancia, ya que los actores maliciosos suelen atacar endpoints conocidos para acceder al sistema.
¡Estén atentos! Y sigan desarrollando API seguras.
Sigan entrenando, Hacketones, Nos vemos en el próximo laboratorio!!!