WEB Diez vulnerabilidades de seguridad (OWASP Top 10) y registros de pruebas de penetración

1. Introducción

        Cada año, el OWASP (Open Web Application Security Project) publica las 10 principales vulnerabilidades de seguridad. Representa un amplio consenso sobre los riesgos de seguridad más críticos para las aplicaciones web. Comprender los diez tipos principales de vulnerabilidades WEB y ser bueno para descubrir vulnerabilidades en las pruebas de penetración son los requisitos básicos para el personal de la industria de la seguridad.

2. TOP 10 DE OWASP

2.1 OWASP Top10 2022

1. Control de acceso roto
2. Mecanismo de encriptación ineficaz
3. Inyección
4. Diseño inseguro
5. Configuración incorrecta de seguridad 6.
Componentes vulnerables y obsoletos
7. Fallas de identificación y autenticación
8. Fallas de integridad de datos y software 9. Falla
de monitoreo y registro de seguridad
10. Servidor Falsificación de solicitud secundaria (SSRF)

2.2 Breve introducción de OWASP Top10

2.2.1 Control de acceso roto

        El control de acceso aplica políticas para evitar que los usuarios operen fuera de sus permisos especificados. Debido a las vulnerabilidades de acceso, los usuarios no autenticados o no deseados pueden obtener acceso a datos y procesos confidenciales y configuraciones de privilegios de usuario. La manipulación de metadatos, incluida la alteración o la reproducción de tokens de control de acceso JSON Web Token (JWT), o la modificación de cookies o campos ocultos para elevar los privilegios o explotar la invalidación de JWT, son ejemplos de vulnerabilidades de control de acceso. El segundo ejemplo es una violación del Principio de denegación predeterminado. El acceso debe otorgarse solo a roles, capacidades o usuarios específicos, pero todos tienen acceso. Dichos errores podrían dar a los atacantes un fácil acceso a todo lo que quieran. Sin embargo, los mecanismos de seguridad de acceso inadecuados y los problemas de administración de identidades o contraseñas se pueden evitar aplicando métodos de codificación seguros y tomando precauciones, como deshabilitar las cuentas y restricciones de administrador e instalar la autenticación multifactor.

        Otras técnicas de prevención incluyen:

        - Hacer cumplir los mecanismos de control de acceso solo una vez y reutilizarlos durante la aplicación para reducir el uso compartido de recursos de origen cruzado (CORS).
       - El modelo de dominio debe imponer restricciones diferentes a las restricciones comerciales de la aplicación.
       - Restrinja el acceso a las interfaces de programación de aplicaciones (API) y los controladores para mitigar el impacto de las herramientas de ataque automatizadas.
       - Registra fallas en el control de acceso y alerta a los administradores según sea necesario.
       - Los controles de acceso al modelo deben hacer cumplir la propiedad de los registros, en lugar de otorgar a los usuarios permiso para crear, ver, modificar o eliminar cualquier información.

2.2.2 Fallo del mecanismo de confidencialidad

        El punto aquí es que los errores de contraseña, o la falta de ellos, a menudo exponen datos confidenciales. Los siguientes son ejemplos típicos de divulgación de información confidencial

        Fichas de sesión
        ID de inicio de sesión y contraseñas
        Transacciones en línea
        Información personal (red de servicio de conmutación o SSN, registros médicos, etc.)
        Por ejemplo, una aplicación podría usar el cifrado automático de la base de datos para cifrar de forma segura los datos de la tarjeta de crédito. Desafortunadamente, cuando se accede a esta información, se descifra inmediatamente, lo que provoca errores de inyección SQL para extraer la información de la tarjeta de crédito en texto sin cifrar, lo que podría ser aprovechado por intrusos.

Estos fallos se pueden evitar utilizando las siguientes técnicas preventivas:

        - Debe almacenar las contraseñas utilizando un algoritmo hash sólido, salado y adaptable con un factor de demora, como scrypt, Argon2, PBKDF2 o bcrypt -
        Debe evitarse el Protocolo de transferencia de archivos (FTP) y el Protocolo simple de transferencia de correo (SMTP) al transferir datos confidenciales Los protocolos más antiguos como SMTP)
        (se recomienda implementar el cifrado autenticado en lugar de solo usar el cifrado
        ) deben generar una clave aleatoria criptográfica y almacenarla como una matriz de bytes. Si usa una frase de contraseña, debe cambiarla a algo como una clave usando un algoritmo de creación de claves basado en frases de contraseña

2.2.3 Inyección

La inyección (o inyección SQL) es un ataque de base de datos contra un sitio web que utiliza lenguaje de consulta estructurado (SQL) para obtener información o realizar actividades que normalmente requieren una cuenta de usuario autenticada. Es difícil para los programas interpretar estos códigos a partir de su propio código, lo que permite a los atacantes realizar ataques de inyección para acceder a áreas protegidas y datos confidenciales haciéndose pasar por usuarios confiables. La inyección incluye inyección SQL, inyección de comando, inyección CRLF, inyección LDAP, etc.

Algunas técnicas de prevención incluyen:

        - Una alternativa mucho más preferible es usar una API que evite el intérprete por completo, proporcione una API parametrizada o transloque a una herramienta de mapeo relacional de objetos (ORM).
       - Se recomienda una validación de entrada agresiva del lado del servidor. Muchas aplicaciones, incluidos los campos de texto y las API para aplicaciones móviles, requieren caracteres especiales.
        -Usar LIMIT y otras restricciones de SQL en las consultas es una excelente manera de evitar una gran cantidad de exposición de datos en caso de inyección de SQL.

2.2.4 Diseño inseguro

        Esta es una categoría completamente nueva para 2021 que se enfoca en fallas de diseño y arquitectura y requiere un mayor uso del modelado de amenazas, recomendaciones de seguridad de diseño y arquitecturas de referencia. El diseño inseguro es una categoría amplia que abarca problemas como "diseño de control faltante o inadecuado". Eso no significa que el diseño inseguro esté en la raíz de todas las otras diez categorías principales de riesgo.

        No es lo mismo un diseño inseguro que una implementación insegura. Incluso cuando el diseño es seguro, las fallas de implementación pueden generar vulnerabilidades. Por otro lado, un diseño defectuoso no puede compensarse con una implementación perfecta, porque no existen las protecciones de seguridad necesarias para proteger contra amenazas específicas.

        Estas amenazas se pueden evitar empleando las siguientes técnicas preventivas:

        -Configure y use un ciclo de vida de desarrollo seguro con la ayuda de expertos de AppSec para evaluar y crear protecciones de seguridad y privacidad.
        - Se recomienda el modelado de amenazas para la autenticación de claves, el control de acceso, la lógica de la aplicación y los procesos fundamentales.
        -Incluir términos y controles de seguridad en las historias de usuario.
        - El diseño de aislamiento de inquilinos en todos los niveles también se considera un enfoque preventivo práctico.

2.2.5 Error de configuración de seguridad

        Los problemas generales de configuración de seguridad, como los controles de acceso mal configurados, crean peligros significativos al proporcionar a los atacantes un acceso rápido y fácil a los datos críticos y las áreas del sitio.

Soluciones comunes:

        - Un proceso de fortalecimiento sistemático permite una implementación rápida y sencilla de entornos seguros. La configuración de los entornos de desarrollo, control de calidad y funcionamiento debe ser similar, con diferentes permisos de usuario.
        - Es ideal para automatizar el proceso para configurar un nuevo entorno seguro, ahorrando el tiempo y el esfuerzo necesarios. Las características y marcos no utilizados deben eliminarse o no instalarse. Una plataforma principal sin características, componentes, documentación o demostraciones innecesarias reduce la probabilidad de vulnerabilidades de configuración.

2.2.6 Componentes vulnerables y obsoletos

        Los problemas generales de configuración de seguridad, como los controles de acceso mal configurados, crean peligros significativos al proporcionar a los atacantes un acceso rápido y fácil a los datos críticos y las áreas del sitio.

Soluciones comunes:

        - Un proceso de fortalecimiento sistemático permite una implementación rápida y sencilla de entornos seguros. La configuración de los entornos de desarrollo, control de calidad y funcionamiento debe ser similar, con diferentes permisos de usuario.
        - Es ideal para automatizar el proceso para configurar un nuevo entorno seguro, ahorrando el tiempo y el esfuerzo necesarios. Las características y marcos no utilizados deben eliminarse o no instalarse. Una plataforma principal sin características, componentes, documentación o demostraciones innecesarias reduce la probabilidad de vulnerabilidades de configuración.

2.2.7 Fallo de identificación y autenticación

        Ahora incluye CWE relacionados con problemas de identificación. Los problemas de seguridad surgen cuando los atacantes obtienen acceso a la información del usuario, la recuperación de contraseñas, las sesiones de identificación y otras credenciales de inicio de sesión. Como su nombre lo indica, las fallas de identidad y autenticación incluyen piratas informáticos que explotan dichas vulnerabilidades para aprovechar la autenticación insuficiente.

        Si la aplicación permite ataques automáticos como el relleno de credenciales (cuando el atacante tiene acceso a listas reales de usuarios y contraseñas) o contraseñas predefinidas, débiles y comunes (como "Password1" o "admin/admin"), estos pueden ser signos de una falla de autenticación

        Para evitar estos peligros, se deben tener en cuenta las siguientes precauciones:

        -Se debe usar la autenticación multifactor cuando sea factible para evitar el relleno automatizado de credenciales, los ataques de fuerza bruta y la reutilización de credenciales robadas.
        - Mejora la seguridad de las contraseñas al comparar las contraseñas nuevas o modificadas con una base de datos de las 10 000 peores contraseñas.
        -Usar el mismo mensaje para cada resultado ayuda a prevenir ataques de enumeración de cuentas en la recuperación de contraseñas, registro y rutas de API.
No instale ninguna credencial predeterminada, especialmente para usuarios administrativos.

2.2.8 Problemas de integridad de datos y software

        A medida que se almacena más y más información confidencial en bases de datos, vulnerable a violaciones de seguridad, el tema de la integridad de los datos se vuelve crítico para el software.

        Esta es una nueva categoría que se enfoca en asumir la integridad de las actualizaciones de software, los datos críticos y los programas de CI/CD sin validarlos. Un ejemplo es cuando una aplicación usa extensiones, módulos o repositorios de redes de entrega de contenido (CDN) o fuentes no autorizadas. Los procesos de integración continua/entrega continua ( CI/CD ) sin protección pueden aumentar el riesgo de código malicioso, sistemas comprometidos o acceso no autorizado.

Las técnicas de prevención incluyen:

        - Uno puede usar medidas tales como firmas digitales para confirmar que los datos o el software provienen de la fuente prevista sin ninguna manipulación.
        - Se pueden utilizar herramientas de seguridad para la cadena de suministro de software, como OWASP CycloneDX u OWASP Dependency-Check, para garantizar que los componentes no contengan fallas de diseño.
        - Es necesario asegurarse de que los flujos de trabajo de CI/CD tengan la segmentación, el control de acceso y la parametrización necesarios para proteger la integridad del código durante las operaciones de configuración e implementación.
        - Los datos compilados sin firmar o sin cifrar no deben enviarse a clientes que no sean de confianza a menos que se haya probado su integridad o firmado digitalmente para identificar cambios o duplicaciones de datos.

2.2.9 Supervisión y registro del registro de seguridad fallidos

        La falta de seguimiento en presencia de comportamientos y eventos sospechosos puede ampliar el intervalo de tiempo no supervisado, lo que permite que las infracciones de seguridad pasen desapercibidas durante más tiempo que con un mejor registro. Esta sección OWASP Top 10 2021 está diseñada para ayudar a identificar, escalar y resolver infracciones recientes. Sin registro y monitoreo, es imposible detectar brechas de seguridad.

        -Confirme que todos los problemas de autenticación, sistemas de seguridad de acceso y verificación de datos del lado del servidor se registren con suficiente información del usuario para detectar cuentas sospechosas o fraudulentas y se almacenen el tiempo suficiente para permitir una investigación completa retrasada.
        -Asegúrese de que los registros se creen en un formato consumible por el sistema de gestión de registros.
        -Cree o aplique políticas para la recuperación de incidentes y los esfuerzos de respuesta, como NIST 800-61r2 o posterior.
        -Asegúrese de que los datos de registro estén codificados correctamente para evitar intrusiones o amenazas cibernéticas a los sistemas de monitoreo.

2.2.10 Falsificación de solicitud de servidor (SSRF)

        Los resultados de esta categoría muestran una cobertura de prueba superior a la media, una incidencia razonablemente baja y un índice de utilización y de impacto superior a la media. SSRF se desarrolló donde la consulta del lado del servidor no autentica la URL proporcionada por el usuario. Esto permite que un atacante engañe a una aplicación para que transmita solicitudes falsificadas a una ubicación no deseada, incluso si esa ubicación está protegida por una red privada virtual (VPN), un firewall o una lista de control de acceso a la red (ACL).

        La obtención de direcciones URL se ha convertido en una situación típica a medida que las nuevas aplicaciones en línea brindan funciones convenientes para los usuarios finales. En consecuencia, la prevalencia de SSRF está aumentando. Además, debido a los servicios en la nube y las complejidades del diseño, la fuerza de SSRF está aumentando. Con esto en mente, tales ataques pueden evitarse empleando las siguientes técnicas preventivas:

        - Para limitar el impacto de SSRF, las funciones de acceso a recursos remotos deben separarse en diferentes redes.
       - Instale una configuración de firewall "denegar por defecto" o una regla de control de acceso a la red para bloquear todo el tráfico web excepto el tráfico interno requerido.
        - En el caso de (TOCTOU), para evitar la reasignación de DNS y los ataques de "verificar tiempo, usar tiempo", es mejor prestar atención a la precisión de la URL.

2.3 Referencia

Las 10 principales vulnerabilidades de seguridad de las aplicaciones web_Diez vulnerabilidades web_crazy_itman's Blog-CSDN Blog

Introducción a OWASP Top 10 2022 - El fin del mundo y tu blog - CSDN Blog

3. Un registro de una prueba de penetración WEB

        Recientemente hice una prueba de penetración WEB. Realice aquí un registro resumido de los problemas detectados.

1. Copie una determinada URL de un usuario autorizado y, después de descubrir que un usuario no autorizado ha iniciado sesión, modifique la URL al contenido recién copiado y descubra que es posible iniciar sesión. (control de acceso roto)

2. Inicie sesión con la cuenta del cliente A, use la función de registro de búsqueda, use el cartero para modificar la identificación de la cuenta en la solicitud HTTP a la cuenta del cliente B y descubra que se puede ver el registro de B. (control de acceso roto)

3. Puede falsificar arbitrariamente la carga útil jwt, encontrar que el mensaje puede ser decodificado y codificado por BASE64, y obtener la decodificación de las llaves donde se encuentra "alg", cambiar el valor de "alg" en el texto sin formato a "ninguno ", y vuelva a codificarlo en "ey****", reemplace el valor del encabezado jwt (Autorización) con "ey****", y la carga útil de jwt se puede configurar arbitrariamente. (control de acceso roto)

4. Use una identificación de rol para llamar a cualquier API pública. Obtenga la identificación del rol del encabezado de respuesta. Vuelva a llamar a la API con el nuevo ID de rol y coloque el nuevo ID de rol en el encabezado de la solicitud. Los resultados cambiarán. (control de acceso roto)

5. El ID de cliente de entrada de la API pública se puede inyectar a través del encabezado "cliente - ID". Los encabezados de entrada no se validan antes de su uso. Este es un problema importante de fuga de datos. Solo cuando se recupera la identificación del cliente, un inquilino puede llamar a la API pública para obtener los datos de otro inquilino. (control de acceso roto)

1. Prepare dos inquilinos: el inquilino A y el inquilino B.
2. Use "cid": "cid of A" para llamar a la API "https://....../audit/logs"
3. Agregue "***-id-cliente": "cid de B" en el encabezado.
4. Obtuvo con éxito la información del registro de auditoría de B.

6. Los encabezados de entrada no se validan antes de su uso. Este es un problema importante de fuga de datos. Siempre que se pueda recuperar la identificación del cliente, un arrendatario puede llamar a la API pública para obtener datos de otros arrendatarios. (control de acceso roto)

1. Use el uic_token correcto en el encabezado para llamar a la API "http://......./notifications/counts"
2. Obtenga la identificación del cliente de la respuesta
3. Coloque la identificación del cliente obtenida en el paso 2 en el encabezado para llamar a la API

7. El atacante puede obtener diferentes permisos de función modificando la identificación de la función. (control de acceso roto)

        1. Use el permiso de una identificación de rol para llamar a la API.

        2. Obtenga la identificación del rol del encabezado de respuesta.

        3. Use la nueva identificación de función para volver a llamar a la API (obtenida en el paso 2) y coloque la nueva identificación de función en el encabezado de la solicitud. Los permisos cambiarán.

8. Al realizar una consulta sin especificar el ui-token, aún se puede consultar la solicitud. (control de acceso roto)

Uic-token se usa para la verificación CSRF, si no se especifica este token, puede haber un ataque CSRF

9. La sesión no se terminó correctamente. Después de cerrar sesión, la sesión sigue siendo válida y se puede usar para realizar solicitudes de API de interfaz de usuario. (identificación y autenticación fallidas)

1. Primero cierre la sesión actual.

2. Llame a la API con la cookie anterior y el token ui, la solicitud aún es exitosa.

10. En el modo de depuración, la contraseña se muestra en la consola (identificación y autenticación fallidas)

La contraseña es información confidencial; el atacante puede iniciar sesión directamente en la consola después de obtener esta contraseña

        1. Inicie sesión en el portal con el rol de "sin permiso".

        2. Abra el enlace https://....../#/admin/logs

        3. Active el modo de depuración y seleccione la consola.       

        4. Ingrese algunas palabras clave y "busque", mostrará la contraseña en la consola web.

11. Al llamar a la API de autenticación de front-end sin una cookie, la respuesta indicará que falta "x-account-id". Si no se requiere autenticación, la identificación de la cuenta se puede configurar a través del encabezado x-account-id. (identificación y autenticación fallidas)

12. Llame a la API del conector del producto front-end, hay un campo de token en la respuesta que no se usa en la página. Problema de fuga de credenciales. (identificación y autenticación fallidas)

13. Los registros de auditoría se pueden eliminar (diseño inseguro)

Los piratas informáticos pueden eliminar los registros de auditoría (DELETE https://…) al realizar algunas operaciones riesgosas.

14. Los atacantes pueden enviar correos electrónicos de prueba con frecuencia, lo que puede causar DOS y spam. (diseño inseguro)

        Inicie el portal a través de "Camp Admin". Vaya a Cuentas->Notificaciones, seleccione un elemento y haga clic en "Enviar correo electrónico de prueba" con frecuencia dentro de 1 minuto.

15. Inyección reflexiva de secuencias de comandos en sitios cruzados (XSS). (inyección)

Esta es una inyección reflexiva de secuencias de comandos entre sitios. XSS se puede usar para robar cookies en un dominio vulnerable y potencialmente obtener acceso no autorizado a la sesión de autenticación de un usuario, alterar/destruir el contenido de una página web vulnerable o comprometer el navegador web de un usuario. Si un atacante modifica el campo de zona horaria en la solicitud, insertando JavaScript para robar cookies, es posible obtener el control si logra que la víctima visite su URL.

        1. En la configuración de la consola, al guardar la configuración. Hay un valor de campo en la carga útil de la solicitud POST que se puede usar para inyectar

<script>alerta(\"0\");</script>

16. Los componentes de las aplicaciones web son vulnerables a los ataques de secuencias de comandos entre sitios (XSS). (inyección)

Los componentes de aplicaciones web son vulnerables a los ataques de secuencias de comandos entre sitios (XSS). Aprovechando este problema, un atacante puede proporcionar un código de sitio del lado del cliente arbitrario (JavaScript, VBScript, etc.) en los parámetros de entrada de la aplicación que finalmente se procesarán y ejecutarán en el navegador web del usuario final.

La página info.html es vulnerable a la inyección de enlaces basada en DOM, que cuando se hace clic puede provocar un ataque entre sitios. XSS se puede usar para robar cookies en el dominio vulnerable y potencialmente obtener acceso no autorizado a la sesión de autenticación del usuario después de comprometer el contenido de la página web vulnerable o comprometer el navegador web del usuario. Una táctica común es volver a pintar las páginas vulnerables en dominios confiables para falsificar el tiempo de espera real de la sesión y las páginas de inicio de sesión para obtener las contraseñas de los usuarios.

        1. Inicie sesión en el portal con la función "Administrador del campamento". ,

        2. Cerrar sesión en el portal

        3. Ingrese la URL https://********/info.html#/redirect?url=javascript:alert(0) para inyectar el script

17. Los detalles de la respuesta pueden revelar información sobre la aplicación, lo que aumenta las posibilidades de descubrir las vulnerabilidades existentes. (desconfiguración de seguridad)

Los detalles de la respuesta pueden revelar información sobre la aplicación, lo que aumenta las posibilidades de descubrir cualquier vulnerabilidad existente.

Al llamar a la API con un cuerpo incorrecto, el resultado de la respuesta contiene detalles de la aplicación.

18. El encabezado CSP no se agrega ni se configura como un valor seguro, lo que cargará recursos a la información del sitio que no es de confianza, lo que generará XSS y otras vulnerabilidades relacionadas. (desconfiguración de seguridad)

La política de seguridad de contenido (CSP) es una capa adicional de seguridad que ayuda a detectar y mitigar ciertos tipos de ataques. Incluyendo (pero no limitado a) cross-site scripting (XSS) y ataques de inyección de datos. Estos ataques se utilizan para todo, desde el robo de datos hasta la desfiguración de sitios web o la distribución de malware. CSP proporciona un conjunto estándar de encabezados HTTP que permiten a los propietarios de sitios web declarar las fuentes de contenido que los navegadores pueden cargar en esa página; los tipos cubiertos incluyen JavaScript, CSS, marcos HTML, fuentes, imágenes y objetos incrustables.

19. Debido a una configuración incorrecta de Cross Origin Resource Sharing (CORS) en el servidor web, es posible que el navegador web no pueda cargar los datos. Access-Control-Allow-Origin: *No es seguro para datos confidenciales. (desconfiguración de seguridad)

Una configuración incorrecta de CORS en el servidor web permite solicitudes de lectura de origen cruzado de dominios de terceros arbitrarios donde se utilizan API no autenticadas. Sin embargo, las implementaciones del navegador web no permiten que terceros arbitrarios lean las respuestas de las API autenticadas. Esto reduce el riesgo hasta cierto punto. Esta configuración incorrecta podría ser utilizada por atacantes para acceder a datos que están disponibles de manera no autenticada, pero que utilizan otras formas de seguridad, como la inclusión en listas blancas de direcciones IP.

20. No usar la política de seguridad HSTS (Configuración incorrecta de la seguridad)

HTTP Strict Transport Security (HSTS) es un mecanismo de política de seguridad web mediante el cual los agentes de usuario (como los navegadores web) que un servidor web declara obedecer solo interactúan con él mediante conexiones HTTPS seguras (es decir, la capa HTTP está sobre TLS/SSL). HSTS es un protocolo de seguimiento de estándares IETF, especificado en RFC 6797.

La falta de este encabezado pone al servidor web en riesgo de ser utilizable para el tráfico HTTP normal.

21. Todos pueden descargar cualquier archivo al servidor, puede reemplazar el archivo y afectar la aplicación, otros clientes pueden hacer que el archivo se ejecute con un virus. (desconfiguración de seguridad)

       1. Abra el portal v1 con el rol de "Administrador".

        2. Busque la URL de obtención del archivo en el portal.

        3. Use el método PUT para enviar cualquier archivo a la URL, por ejemplo, test.js. Puede obtener este archivo con el método get.

22. Http se puede usar para hacer llamadas API (error de configuración de seguridad)

Una API puede usar Postman para enviar solicitudes http

No hay encabezado "Strict-Transport-Security" en los encabezados de respuesta. El encabezado "Strict-Transport-Security" restringe el sitio solo a HTTPS, y cualquier intento futuro de acceder a él mediante HTTP debe convertirse automáticamente a HTTPS.

4. Finalmente

        Los principales tipos de seguridad web cambian ligeramente de un año a otro. El dominio de los tipos más comunes de vulnerabilidades WEB es una base importante para el desarrollo del trabajo de penetración.