OWASP

OWASP

1. El Open Web Application Security Project (OWASP)o el Proyecto Abierto de seguridad de aplicaciones web es un proyecto de código abierto dedicado a determinar y combatir las causas que hacen que el software sea inseguro.

2. Vulnerabilidades en Seguridad de Aplicaciones

   • Inyección
     • Características
       • Los datos suministrados por el usuario no son validados, filtrados o sanitizados por la aplicación.
       • Se invocan consultas dinámicas o no parametrizadas, sin codificar los parámetros de forma acorde al contexto.
         • Se utilizan datos dañinos dentro de los parámetros de búsqueda en consultas Object-Relational Mapping (ORM), para extraer registros adicionales sensibles.
           • Los datos dañinos se usan directamente o se concatenan, de modo que el SQL o comando resultante contiene datos y estructuras con consultas dinámicas, comandos o procedimientos almacenados
     • Prevenciones y Soluciones
       • La opción preferida es utilizar una API segura, que evite el uso de un intérprete por completo y proporcione una interfaz parametrizada
         • Realice validaciones de entradas de datos en el servidor, utilizando "listas blancas".
           • Para cualquier consulta dinámica residual, escape caracteres especiales utilizando la sintaxis de caracteres específica para el intérprete que se trate
             • Utilice LIMIT y otros controles SQL dentro de las consultas para evitar la fuga masiva de registros en caso de inyección SQL.
   • Pérdida de Autenticación
     • Características
       • Permite ataques automatizados como la reutilización de credenciales conocidas, cuando el atacante ya posee una lista de pares de usuario y contraseña válidos.
         • Permite ataques de fuerza bruta y/o ataques automatizados
           • Permite contraseñas por defecto, débiles o muy conocidas, como “Password1”, “Contraseña1” o “admin/admin”.
             • Posee procesos débiles o inefectivos en el proceso de recuperación de credenciales, como “respuestas basadas en el conocimiento”, las cuales no se pueden implementar de forma segura.
               • Almacena las contraseñas en texto claro o cifradas con métodos de hashing débiles
                 • No posee autenticación multi-factor o fue implementada de forma ineficaz.
                   • Expone Session IDs en las URL, no la invalida correctamente o no la rota satisfactoriamente luego del cierre de sesión o de un periodo de tiempo determinado.
     • Prevenciones y soluciones
       • Implemente autenticación multi-factor para evitar ataques automatizados, de fuerza bruta o reúso de credenciales robadas
         • No utilice credenciales por defecto en su software, particularmente en el caso de administradores.
           • Implemente controles contra contraseñas débiles.
             • Mediante la utilización de los mensajes genéricos iguales en todas las salidas, asegúrese que el registro, la recuperación de credenciales y el uso de APIs, no permiten ataques de enumeración de usuarios
               • Limite o incremente el tiempo de respuesta de cada intento fallido de inicio de sesión.
                 • 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.
   • Exposicíon de datos sensibles
     • Características
       • Lo primero es determinar las necesidades de protección de los datos en tránsito y en almacenamiento. Por ejemplo, contraseñas, números de tarjetas de crédito, registros médicos, información personal y datos sensibles del negocio requieren protección adicional, especialmente si se encuentran en el ámbito de aplicación de leyes de privacidad.
         • ¿Se transmite datos en texto claro? Esto se refiere a protocolos como HTTP, SMTP, TELNET, FTP. El tráfico en Internet es especialmente peligroso.
           • ¿Se utilizan algoritmos criptográficos obsoletos o débiles, ya sea por defecto o en código heredado? Por ejemplo MD5, SHA1, etc.
             • ¿Se utilizan claves criptográficas predeterminadas, se generan o reutilizan claves criptográficas débiles, o falta una gestión o rotación adecuada de las claves?
               • Por defecto, ¿se aplica cifrado? ¿se han establecido las directivas de seguridad o encabezados para el navegador web?
                 • ¿El User-Agent del usuario (aplicación o cliente de correo), verifica que el certificado enviado por el servidor sea válido?
     • Prevenciones y soluciones
       • Clasifique los datos procesados, almacenados o transmitidos por el sistema
         • Aplique los controles adecuados para cada clasificación.
           • No almacene datos sensibles innecesariamente.
             • Cifre todos los datos sensibles cuando sean almacenados.
               • Cifre todos los datos en tránsito utilizando protocolos seguros como TLS con cifradores que utilicen Perfect Forward Secrecy (PFS), priorizando los algoritmos en el servidor
                 • Utilice únicamente algoritmos y protocolos estándares y fuertes e implemente una gestión adecuada de claves.
                   • Deshabilite el almacenamiento en cache de datos sensibles

3. Entidades Externas XML

   • Características
     • La aplicación acepta XML directamente, carga XML desde fuentes no confiables o inserta datos no confiables en documentos XML.
       • Cualquiera de los procesadores XML utilizados en la aplicación o los servicios web basados en SOAP, poseen habilitadas las definiciones de tipo de documento (DTDs).
         • La aplicación utiliza SAML para el procesamiento de identidades dentro de la seguridad federada o para propósitos de Single Sign-On (SSO).
           • La aplicación utiliza SOAP en una versión previa a la 1.2 y, si las entidades XML son pasadas a la infraestructura SOAP, probablemente sea susceptible a ataques XXE.
             • Ser vulnerable a ataques XXE significa que probablemente la aplicación también es vulnerable a ataques de denegación de servicio, incluyendo el ataque Billion Laughs.
   • Prevenciones y soluciones
     • De ser posible, utilice formatos de datos menos complejos como JSON y evite la serialización de datos confidenciales.
       • Actualice los procesadores y bibliotecas XML que utilice la aplicación o el sistema subyacente.
         • Deshabilite las entidades externas de XML y procesamiento DTD en todos los analizadores sintácticos XML en su aplicación
           • Implemente validación de entrada positiva en el servidor (“lista blanca”), filtrado y sanitización para prevenir el ingreso de datos dañinos dentro de documentos, cabeceras y nodos XML.
             • Verifique que la funcionalidad de carga de archivos XML o XSL valide el XML entrante, usando validación XSD o similar

4. Pérdida de Control de Acceso

   • Características
     • Pasar por alto las comprobaciones de control de acceso modificando la URL, el estado interno de la aplicación o HTML, utilizando una herramienta de ataque o una conexión vía API.
       • Permitir que la clave primaria se cambie a la de otro usuario, pudiendo ver o editar la cuenta de otra persona
         • Elevación de privilegios. Actuar como un usuario sin iniciar sesión, o actuar como un administrador habiendo iniciado sesión como usuario estándar.
           • Manipulación de metadatos, como reproducir un token de control de acceso JWT (JSON Web Token), manipular una cookie o un campo oculto para elevar los privilegios, o abusar de la invalidación de tokens JWT
             • La configuración incorrecta de CORS permite el acceso no autorizado a una API.
               • Forzar la navegación a páginas autenticadas como un usuario no autenticado o a páginas privilegiadas como usuario estándar
                 • Acceder a una API sin control de acceso mediante el uso de verbos POST, PUT y DELETE.
   • Prevenciones y Soluciones
     • Con la excepción de los recursos públicos, la política debe ser denegar de forma predeterminada.
       • Implemente los mecanismos de control de acceso una vez y reutilícelo en toda la aplicación, incluyendo minimizar el control de acceso HTTP (CORS).
         • Los controles de acceso al modelo deben imponer la propiedad (dueño) de los registros, en lugar de aceptar que el usuario puede crear, leer, actualizar o eliminar cualquier registro.
           • Los modelos de dominio deben hacer cumplir los requisitos exclusivos de los límites de negocio de las aplicaciones.
             • Deshabilite el listado de directorios del servidor web y asegúrese que los metadatos/fuentes de archivos (por ejemplo de GIT) y copia de seguridad no estén presentes en las carpetas públicas
               • Registre errores de control de acceso y alerte a los administradores cuando corresponda (por ej. fallas reiteradas).
                 • Limite la tasa de acceso a las APIs para minimizar el daño de herramientas de ataque automatizadas.

5. Configuración de Seguridad Incorrecta

   • Características
     • Falta hardening adecuado en cualquier parte del stack tecnológico, o permisos mal configurados en los servicios de la nube
       • Se encuentran instaladas o habilitadas características innecesarias (ej. puertos, servicios, páginas, cuentas o permisos).
         • Las cuentas predeterminadas y sus contraseñas siguen activas y sin cambios.
           • El manejo de errores revela a los usuarios trazas de la aplicación u otros mensajes demasiado informativos
             • Para los sistemas actualizados, las nuevas funciones de seguridad se encuentran desactivadas o no se encuentran configuradas de forma adecuada o segura
               • Las configuraciones de seguridad en el servidor de aplicaciones, en el framework de aplicación (ej., Struts, Spring, ASP.NET), bibliotecas o bases de datos no se encuentran especificados con valores seguros.
                 • El servidor no envía directrices o cabeceras de seguridad a los clientes o se encuentran configurados con valores inseguros.
                   • El software se encuentra desactualizado o posee vulnerabilidades
   • Prevenciones y soluciones
     • Proceso de fortalecimiento reproducible que agilice y facilite la implementación de otro entorno asegurado.
       • Use una plataforma minimalista sin funcionalidades innecesarias, componentes, documentación o ejemplos.
         • Siga un proceso para revisar y actualizar las configuraciones apropiadas de acuerdo a las advertencias de seguridad y siga un proceso de gestión de parches.
           • La aplicación debe tener una arquitectura segmentada que proporcione una separación efectiva y segura entre componentes y acceso a terceros, contenedores o grupos de seguridad en la nube (ACLs).
             • Envíe directivas de seguridad en los clientes.
               • Utilice un proceso automatizado para verificar la efectividad de los ajustes y configuraciones en todos los ambientes.

6. Cross-Site Scripting (XSS)

   • Características
     • XSS Reflejado: la aplicación o API utiliza datos sin validar, suministrados por un usuario y codificados como parte del HTML o Javascript de salida.
       • XSS Almacenado: la aplicación o API almacena datos proporcionados por el usuario sin validar ni sanear, los que posteriormente son visualizados o utilizados por otro usuario o un administrador.
         • XSS Basados en DOM: frameworks en JavaScript, aplicaciones de página única o APIs incluyen datos dinámicamente, controlables por un atacante.
   • Prevenciones y soluciones
     • Utilizar frameworks seguros que, por diseño, automáticamente codifican el contenido para prevenir XSS, como en Ruby 3.0 o React JS
       • Codificar los datos de requerimientos HTTP no confiables en los campos de salida HTML (cuerpo, atributos, JavaScript, CSS, o URL) resuelve los XSS Reflejado y XSS Almacenado.
         • Aplicar codificación sensitiva al contexto, cuando se modifica el documento en el navegador del cliente, ayuda a prevenir DOM XSS.
           • Habilitar una Política de Seguridad de Contenido (CSP) es una defensa profunda para la mitigación de vulnerabilidades XSS

7. Deserialización Insegura

   • Características
     • Ataques relacionados con la estructura de datos y objetos; donde el atacante modifica la lógica de la aplicación o logra una ejecución remota de código que puede cambiar el comportamiento de la aplicación durante o después de la deserialización.
       • Ataques típicos de manipulación de datos; como ataques relacionados con el control de acceso, en los que se utilizan estructuras de datos existentes pero se modifica su contenido.
   • Prevenciones y soluciones
     • El único patrón de arquitectura seguro es no aceptar objetos serializados de fuentes no confiables o utilizar medios de serialización que sólo permitan tipos de datos primitivos.

8. Uso de Componentes con Vulnerabilidades Conocidas

   • Características
     • No conoce las versiones de todos los componentes que utiliza (tanto del lado del cliente como del servidor). Esto incluye componentes utilizados directamente como sus dependencias anidadas.
       • El software es vulnerable, no posee soporte o se encuentra desactualizado.
         • No se analizan los componentes periódicamente ni se realiza seguimiento de los boletines de seguridad de los componentes utilizados.
           • No se parchea o actualiza la plataforma subyacente, frameworks y dependencias, con un enfoque basado en riesgos.
             • No asegura la configuración de los componentes correctamente
   • Prevenciones y soluciones
     • Remover dependencias, funcionalidades, componentes, archivos y documentación innecesaria y no utilizada.
       • Utilizar una herramienta para mantener un inventario de versiones de componentes
         • Monitorizar continuamente fuentes como CVE y NVD en búsqueda de vulnerabilidades en los componentes utilizados.
           • Obtener componentes únicamente de orígenes oficiales utilizando canales seguros.
             • Supervisar bibliotecas y componentes que no poseen mantenimiento o no liberan parches de seguridad para sus versiones obsoletas o sin soporte.

9. Registro y Monitoreo Insuficientes

   • Características
     • Eventos auditables, tales como los inicios de sesión, fallos en el inicio de sesión, y transacciones de alto valor no son registrados.
       • Advertencias y errores generan registros poco claros, inadecuados o ninguno en absoluto.
         • Registros en aplicaciones o APIs no son monitoreados para detectar actividades sospechosas
           • Los registros son almacenados únicamente de forma local.
             • Los umbrales de alerta y de escalamiento de respuesta no están implementados o no son eficaces.
               • Las pruebas de penetración y escaneos utilizando herramientas DAST (como OWASP ZAP) no generan alertas.
                 • La aplicación no logra detectar, escalar o alertar sobre ataques en tiempo real.
   • Prevenciones y soluciones
     • Asegúrese de que todos los errores de inicio de sesión, de control de acceso y de validación de entradas de datos del lado del servidor se pueden registrar para identificar cuentas sospechosas
       • Asegúrese de que las transacciones de alto impacto tengan una pista de auditoría con controles de integridad para prevenir alteraciones o eliminaciones.
         • Asegúrese que todas las transacciones de alto valor poseen una traza de auditoría con controles de integridad que permitan detectar su modificación o borrado, tales como una base de datos con permisos de inserción únicamente u similar.
           • Establezca una monitorización y alerta efectivos de tal manera que las actividades sospechosas sean detectadas y respondidas dentro de períodos de tiempo aceptables
             • Establezca o adopte un plan de respuesta o recuperación de incidentes, tales como NIST 800-61 rev.2 o posterior