Los 10 riesgos más críticos en Aplicaciones Web

1. Los atacantes tienen acceso a millones de combinaciones de pares de usuario y contraseña conocidas (debido a fugas de información), además de cuentas administrativas por defecto.

   Nota:

   •  Pueden realizar ataques mediante herramientas de fuerza bruta o diccionarios para romper los hashes de las contraseñas.
   1. Los atacantes pueden detectar la autenticación defectuosa utilizando medios manuales y explotarlos utilizando herramientas automatizadas con listas de contraseñas y ataques de diccionario.

      Nota:

      • Los errores de pérdida de autenticación son comunes debido al diseño y la implementación de la mayoría de los controles de acceso. La gestión de sesiones es la piedra angular de los controles de autenticación y está presente en las aplicaciones.
      1. Los atacantes solo tienen que obtener el acceso a unas pocas cuentas o a una cuenta de administrador para comprometer el sistema.

         Nota:

         •  Dependiendo del dominio de la aplicación, esto puedo permitir robo de identidad, lavado de dinero y la divulgación de información sensible protegida legalmente.
         1. Permite ataques automatizados como la reutilización de credenciales conocidas
            1. Permite ataques de fuerza bruta y/o ataques automatizados.
               1. Permite contraseñas por defecto, débiles o muy conocidas, como “Password1”, “Contraseña1” o “admin/admin”
                  1. Posee procesos débiles o inefectivos en el proceso de recuperación de credenciales

                     Nota:

                     • Ejm “respuestas basadas en el conocimiento”, las cuales no se pueden implementar de forma segura.
                     1. Almacena las contraseñas en texto claro o cifradas con métodos de hashing débiles

                        Nota:

                        • (vea A3:2017-Exposición de Datos Sensibles).
                        1. No posee autenticación multi-factor o fue implementada de forma ineficaz.
                           1. Expone Session IDs en las URL
                              1. Implemente autenticación multi-factor para evitar ataques automatizados, de fuerza bruta o reúso de credenciales robadas.
                                 1. No utilice credenciales por defecto en su software, particularmente en el caso de administradores
                                    1. Implemente controles contra contraseñas débiles.

                                       Nota:

                                       •  Cuando el usuario ingrese una nueva clave, la misma puede verificarse contra la lista del Top 10.000 de peores contraseñas.
                                       1. Alinear la política de longitud, complejidad y rotación de contraseñas

                                          Nota:

                                          • Con las recomendaciones de la Sección 5.1.1 para Secretos Memorizados de la Guía NIST 800-63 B's u otras políticas de contraseñas modernas, basadas en evidencias
                                          1. Mediante la utilización de los mensajes genéricos iguales en todas las salidas

                                             Nota:

                                             • Asegúrese que el registro, la recuperación de credenciales y el uso de APIs, no permiten ataques de enumeración de usuarios.
                                             1. Limite o incremente el tiempo de respuesta de cada intento fallido de inicio de sesión.

                                                Nota:

                                                • Registre todos los fallos y avise a los administradores cuando se detecten ataques de fuerza bruta.
                                                1. Utilice un gestor de sesión en el servidor, integrado, seguro y que genere un nuevo ID de sesión aleatorio con alta entropía después del inicio de sesión.

                                                   Nota:

                                                   •  El Session-ID no debe incluirse en la URL, debe almacenarse de forma segura y ser invalidado después del cierre de sesión o de un tiempo de inactividad determinado por la criticidad del negocio.

Nota:

• La confirmación de la identidad y la gestión de sesiones del usuario son fundamentales para protegerse contra ataques relacionados con la autenticación.

Nota:

• No la invalida correctamente o no la rota satisfactoriamente luego del cierre de sesión o de un periodo de tiempo determinado. 

1. Vector de ataque
   1. Variables de entorno, parámetros, servicios web externos e internos, y todo tipo de usuarios

      Nota:

      • Los defectos de inyección ocurren cuando un atacante puede enviar información dañina a un intérprete
2. Debilidades de seguridad
   1. Los defectos de inyección ocurren cuando un atacante puede enviar información dañina a un intérprete

      Nota:

      • Los errores de inyección son fáciles de descubrir al examinar el código y los escáneres y fuzzers ayudan a encontrarlos.
3. Impacto
   1. Divulgación, pérdida o corrupción de información, pérdida de auditabilidad, o denegación de acceso.

      Nota:

      • El impacto al negocio depende de las necesidades de la aplicación y de los datos
4. Vulnerabilidad

   Nota:

   • Las organizaciones pueden incluir herramientas de análisis estático (SAST) y pruebas dinámicas (DAST) para identificar errores de inyecciones recientemente introducidas y antes del despliegue de la aplicación en producción
   1. Los datos suministrados por el usuario no son revisados
   2. Se invocan consultas dinámicas o no parametrizadas
   3. Se utilizan datos dañinos dentro de los parámetros de búsqueda en consultas (ORM)
   4. Los datos dañinos se usan directamente o se concatenan
5. Como se previene
   1. Utilizar una API segura

      Nota:

      • Incluso cuando se parametrizan, los procedimientos almacenados pueden introducir una inyección SQL si el procedimiento PL/SQL o T-SQL concatena consultas y datos, o se ejecutan parámetros utilizando EXECUTE IMMEDIATE o exec().
   2. Validaciones de entradas de datos en el servidor, utilizando "listas blancas".
   3. Para una consulta dinámica residual, utilice la sintaxis de caracteres

      Nota:

      •  La estructura de SQL como nombres de tabla, nombres de columna, etc. no se pueden escapar y, por lo tanto, los nombres de estructura suministrados por el usuario son peligrosos. Este es un problema común en el software de redacción de informes.
   4. Utilice LIMIT y otros controles SQL