Broken Acces Control (Control de Acceso Roto):
El control de acceso aplica una política tal que los usuarios no pueden actuar fuera de sus permisos previstos. Las fallas generalmente conducen a la divulgación, modificación o destrucción no autorizada de todos los datos oa la realización de una función comercial fuera de los límites del usuario. Las vulnerabilidades comunes de control de acceso incluyen:
Violación del principio de privilegio mínimo o denegación por defecto, donde el acceso solo debe otorgarse para capacidades, roles o usuarios particulares, pero está disponible para cualquiera.
Omitir las comprobaciones de control de acceso mediante la modificación de la URL (alteración de parámetros o navegación forzada), el estado interno de la aplicación o la página HTML, o mediante el uso de una herramienta de ataque que modifica las solicitudes de API.
Permitir ver o editar la cuenta de otra persona, al proporcionar su identificador único (referencias de objetos directos inseguros)
Acceso a la API sin controles de acceso para POST, PUT y DELETE.
Elevación de privilegio. Actuar como usuario sin haber iniciado sesión o actuar como administrador cuando se ha iniciado sesión como usuario.
Manipulación de metadatos, como la reproducción o manipulación de un token de control de acceso JSON Web Token (JWT), o una cookie o un campo oculto manipulado para elevar los privilegios o abusar de la invalidación de JWT.
La configuración incorrecta de CORS permite el acceso a la API desde orígenes no autorizados/no confiables.
Forzar la navegación a páginas autenticadas como usuario no autenticado o a páginas privilegiadas como usuario estándar.
Como prevenir
El control de acceso solo es efectivo en el código del lado del servidor confiable o API sin servidor, donde el atacante no puede modificar la verificación de control de acceso o los metadatos.
Excepto para los recursos públicos, denegar por defecto.
Implemente mecanismos de control de acceso una vez y reutilícelos en toda la aplicación, incluida la minimización del uso compartido de recursos de origen cruzado (CORS).
Los controles de acceso al modelo deben imponer la propiedad de los registros en lugar de aceptar que el usuario pueda crear, leer, actualizar o eliminar cualquier registro.
Los modelos de dominio deben hacer cumplir los requisitos de límite comercial de aplicaciones únicas.
Deshabilite la lista de directorios del servidor web y asegúrese de que los metadatos del archivo (p. ej., .git) y los archivos de copia de seguridad no estén presentes en las raíces web.
Registrar fallas de control de acceso, alertar a los administradores cuando corresponda (por ejemplo, fallas repetidas).
Tasa de límite API y acceso al controlador para minimizar el daño de las herramientas de ataque automatizado.
Los identificadores de sesión con estado deben invalidarse en el servidor después de cerrar la sesión. Los tokens JWT sin estado deberían ser de corta duración para minimizar la ventana de oportunidad para un atacante. Para los JWT de mayor duración, se recomienda encarecidamente seguir los estándares de OAuth para revocar el acceso.
Los desarrolladores y el personal de control de calidad deben incluir una unidad de control de acceso funcional y pruebas de integración.
Opinión personal
Cryptographic Failures (Fallas Criptográficas):
Lo primero es determinar las necesidades de protección de los datos en tránsito y en reposo. Por ejemplo, las contraseñas, los números de tarjetas de crédito, los registros de salud, la información personal y los secretos comerciales requieren protección adicional, principalmente si esos datos están sujetos a las leyes de privacidad, por ejemplo, el Reglamento General de Protección de Datos (GDPR) de la UE, o regulaciones, por ejemplo, la protección de datos financieros. como el estándar de seguridad de datos PCI (PCI DSS). Para todos estos datos:
¿Se transmite algún dato en texto claro? Esto se refiere a protocolos como HTTP, SMTP, FTP que también usan actualizaciones de TLS como STARTTLS. El tráfico de Internet externo es peligroso. Verifique todo el tráfico interno, por ejemplo, entre balanceadores de carga, servidores web o sistemas back-end.
¿Se utilizan protocolos o algoritmos criptográficos antiguos o débiles de forma predeterminada o en código antiguo?
¿Están en uso las claves criptográficas predeterminadas, se generan o reutilizan claves criptográficas débiles, o falta una gestión o rotación de claves adecuada? ¿Se registran las claves criptográficas en los repositorios de código fuente?
¿No se aplica el cifrado, por ejemplo, faltan directivas de seguridad o encabezados de encabezados HTTP (navegador)?
¿El certificado del servidor recibido y la cadena de confianza están debidamente validados?
¿Se ignoran, reutilizan o no se generan los vectores de inicialización lo suficientemente seguros para el modo criptográfico de operación? ¿Se está utilizando un modo de operación inseguro como ECB? ¿Se usa el cifrado cuando el cifrado autenticado es más apropiado?
¿Se utilizan contraseñas como claves criptográficas en ausencia de una función de derivación de clave base de contraseña?
¿Se utiliza la aleatoriedad con fines criptográficos que no fueron diseñados para cumplir con los requisitos criptográficos? Incluso si se elige la función correcta, ¿debe ser sembrada por el desarrollador y, de no ser así, el desarrollador ha sobrescrito la funcionalidad de siembra fuerte integrada con una semilla que carece de suficiente entropía/imprevisibilidad?
¿Se utilizan funciones hash en desuso, como MD5 o SHA1, o se utilizan funciones hash no criptográficas cuando se necesitan funciones hash criptográficas?
¿Están en uso métodos de relleno criptográfico en desuso, como PKCS número 1 v1.5?
¿Son explotables los mensajes de error criptográficos o la información del canal lateral, por ejemplo, en forma de ataques de oráculo de relleno?
Como prevenir
Clasificar los datos procesados, almacenados o transmitidos por una aplicación. Identifique qué datos son confidenciales de acuerdo con las leyes de privacidad, los requisitos reglamentarios o las necesidades comerciales.
No almacene datos confidenciales innecesariamente. Deséchelo lo antes posible o use tokenización compatible con PCI DSS o incluso truncamiento. Los datos que no se retienen no se pueden robar.
Asegúrese de cifrar todos los datos confidenciales en reposo.
Asegúrese de que se implementen algoritmos, protocolos y claves estándar sólidos y actualizados; utilizar una gestión de claves adecuada.
Cifre todos los datos en tránsito con protocolos seguros como TLS con cifrado de confidencialidad directa (FS), priorización de cifrado por parte del servidor y parámetros seguros. Aplique el cifrado mediante directivas como HTTP Strict Transport Security (HSTS).
Deshabilite el almacenamiento en caché para las respuestas que contienen datos confidenciales.
Aplicar los controles de seguridad requeridos según la clasificación de datos.
No utilice protocolos heredados como FTP y SMTP para transportar datos confidenciales.
Almacene contraseñas utilizando funciones de hashing saladas y adaptables sólidas con un factor de trabajo (factor de demora), como Argon2, scrypt, bcrypt o PBKDF2.
Los vectores de inicialización deben elegirse de forma adecuada para el modo de operación. Para muchos modos, esto significa usar un CSPRNG (generador de números pseudoaleatorios criptográficamente seguro). Para los modos que requieren un nonce, el vector de inicialización (IV) no necesita un CSPRNG. En todos los casos, el IV nunca debe usarse dos veces para una clave fija.
Utilice siempre cifrado autenticado en lugar de solo cifrado.
Las claves deben generarse criptográficamente al azar y almacenarse en la memoria como matrices de bytes. Si se utiliza una contraseña, debe convertirse en una clave a través de una función de derivación de clave base de contraseña adecuada.
Asegúrese de que se utilice la aleatoriedad criptográfica cuando corresponda y de que no se haya sembrado de forma predecible o con baja entropía. La mayoría de las API modernas no requieren que el desarrollador genere CSPRNG para obtener seguridad.
Evite las funciones criptográficas obsoletas y los esquemas de relleno, como MD5, SHA1, PKCS número 1 v1.5.
Verifique de forma independiente la eficacia de la configuración y los ajustes.
Opinión personal
Injection (Inyección)
Una aplicación es vulnerable a un ataque cuando:
La aplicación no valida, filtra ni desinfecta los datos proporcionados por el usuario.
Las consultas dinámicas o las llamadas no parametrizadas sin escape consciente del contexto se utilizan directamente en el intérprete.
Los datos hostiles se utilizan dentro de los parámetros de búsqueda de mapeo relacional de objetos (ORM) para extraer registros confidenciales adicionales.
Los datos hostiles se utilizan o concatenan directamente. El comando SQL o contiene la estructura y los datos maliciosos en consultas dinámicas, comandos o procedimientos almacenados.
Algunas de las inyecciones más comunes son SQL, NoSQL, comando OS, asignación relacional de objetos (ORM), LDAP e inyección de lenguaje de expresión (EL) o biblioteca de navegación de gráficos de objetos (OGNL). El concepto es idéntico entre todos los intérpretes. La revisión del código fuente es el mejor método para detectar si las aplicaciones son vulnerables a las inyecciones. Se recomienda encarecidamente la prueba automatizada de todos los parámetros, encabezados, URL, cookies, JSON, SOAP y entradas de datos XML. Las organizaciones pueden incluir herramientas de prueba de seguridad de aplicaciones estáticas (SAST), dinámicas (DAST) e interactivas (IAST) en la canalización de CI/CD para identificar fallas de inyección introducidas antes de la implementación de producción.
Como prevenir
Prevenir la inyección requiere mantener los datos separados de los comandos y consultas:
La opción preferida es usar una API segura, que evita usar el intérprete por completo, proporciona una interfaz parametrizada o migra a herramientas de mapeo relacional de objetos (ORM).
Nota: Incluso cuando están parametrizados, los procedimientos almacenados aún pueden introducir inyección SQL si PL/SQL o T-SQL concatenan consultas y datos o ejecutan datos hostiles con EXECUTE IMMEDIATE o exec().Utilice una validación de entrada positiva del lado del servidor. Esta no es una defensa completa ya que muchas aplicaciones requieren caracteres especiales, como áreas de texto o API para aplicaciones móviles.
Para cualquier consulta dinámica residual, escape los caracteres especiales usando la sintaxis de escape específica para ese intérprete.
Nota: las estructuras SQL, como los nombres de las tablas, los nombres de las columnas, etc., no se pueden escapar y, por lo tanto, los nombres de estructuras proporcionados por el usuario son peligrosos. Este es un problema común en el software de redacción de informes.Utilice LIMIT y otros controles de SQL dentro de las consultas para evitar la divulgación masiva de registros en caso de inyección de SQL.
No hay comentarios:
Publicar un comentario