Tema 7 Flashcards
¿Cómo se puede saber si una app es vulnerable a inyección?
La mejor manera de saber si una aplicación es vulnerable a inyección es verificar que todo uso de los intérpretes claramente separe datos no confiables del comando o consulta
– Para consultas SQL, esto significa utilizar variables parametrizadas en todas las consultas preparadas y procedimientos almacenados, como así también evitar consultas dinámicas
¿Cómo se puede evitar la inyección?
– 1. La opción preferida es utilizar una API segura que evite el uso del
intérprete completamente o provea una interfaz parametrizada
– 2. Si una no se encuentra disponible API parametrizada,se debe eliminar los caracteres especiales utilizando una sintaxis de escape especial para dicho intérprete
– 3. Una validación positiva de entradas con una apropiada canonicalización está también recomendado, pero no es una defensa completa ya que muchas aplicaciones requieren caracteres especiales en sus entradas. OWASP’s ESAPI tiene una librería extensible de rutinas de validación de entradas para Java
¿Cómo se sabe si hay vulnerabilidades para Pérdida de autenticación y gestión de sesiones?
– 1. ¿Están siempre las credenciales protegidas cuando se
almacenan utilizando un hash o cifrado? (Consulte el punto A7)
– 2. ¿Se pueden adivinar o sobrescribir las credenciales a través de funciones débiles de gestión de la cuenta (por ejemplo, registro de usuarios, cambiar contraseñas, recuperación de contraseñas, identificadores débiles de sesión)?
– 3. ¿Se muestran los identificadores de sesión en la dirección URL (por ejemplo, re-escritura de la dirección)?
– 4. ¿Son los identificadores de sesión vulnerables a ataques de
fijación de la sesión?
– 5. ¿Caducan las sesiones y pueden los usuarios cerrar sus sesiones?
– 6. ¿Se rotan los identificadores de sesiones después de una autenticación correcta?
– 7. ¿Se envían las contraseñas, identificadores de sesión y otras credenciales únicamente mediante conexiones TLS? (Consulte la sección A9)
¿Cómo se puede proteger de Pérdida de autenticación y gestión de sesiones?
– 1. Un único conjunto de controles de autenticación fuerte y gestión de
sesiones. Dichos controles deberán conseguir:
o a) Reunir todos los requisitos de gestión de sesiones y autenticación definidos en el Application Security Verification Standard (ASVS) de OWASP, secciones V2 (Autenticación) y V3(Gestión de sesiones)
o b) Tener un interfaz simple para los desarrolladores. Considerar ESAPI Authenticator y las APIs de usuario como buenos ejemplos a emular, utilizar o sobre los que partir
– 2. Se debe hacer especial hincapié en evitar vulnerabilidades de XSS que podrían ser utilizadas para robar identificadores de sesión.(Consulte el apartado A2)
¿Qué hay que cuidar en Cross-Site Scripting?
Es necesario asegurarse que todos los datos de entrada suministrados por el usuario enviados al navegador sean seguros (a través de validación de entradas) y que las entradas de usuario sean escapadas de manera apropiada antes de que sean incluidas en la página de salida
• Una apropiada codificación de salida asegura que los datos de entrada sean siempre tratados como texto en el navegador, en lugar de contenido activo que puede ser ejecutado
¿Cómo se puede proteger de Cross-Site Scripting?
– 1. La opción preferida es escapar todos los datos no confiables basados en el contexto HTML (cuerpo, atributo, JavaScript, CSS, o URL) donde los serán ubicados.
oLos desarrolladores necesitan incluir esta técnica en sus aplicaciones al menos que el framework de intefaz de usuario lo realice por ellos (véase la Hoja de Trucos de Prevención XSS para mayor información sobre técnicas de escape de datos)
– 2. Una validación de entradas positiva o whitelist con apropiada canonicalización y decodificación es también recomendable ya que ayuda a proteger contra XSS, pero no es una defensa completa ya que muchas aplicaciones requieren caracteres especiales en sus entradas
o Tal validación debería, tanto como sea posible, decodificar cualquier entrada codificada y luego validar la longitud, caracteres, formato, y cualquier regla de negocio en dichos datos antes de aceptar la entrada
¿Cómo saber si mi app es vulnerable a Referencia directa insegura a objetos?
La mejor manera de poder comprobar si una aplicación es vulnerable a referencias inseguras a objetos es verificar que todas las referencias a objetos tienen las protecciones apropiadas
¿Cómo proteger una app para Referencia directa insegura a objetos
– 1. Utilizar referencias indirectas por usuario o sesión:
o Esto evitaría que los atacantes accedieran directamente a recursos no autorizados
o Por ejemplo, en vez de utilizar la clave del recurso de base de datos, se podría utilizar una lista de 6 recursos que utilizase los números del 1 al 6 para indicar cuál es el valor elegido por el usuario.
» La aplicación tendría que realizar la correlación entre la referencia indirecta con la clave de la base de datos correspondiente en el servidor. ESAPI de OWASP incluye relaciones tanto secuenciales como aleatorias de referencias de acceso que los desarrolladores pueden utilizar para eliminar las referencias directas a objetos
– 2. Comprobar el acceso
– Cada uso de una referencia directa a un objeto de una fuente que no es de confianza debe incluir una comprobación de control de acceso para asegurar que el usuario está autorizado a acceder al objeto solicitado
¿Cuáles son los principales peligros de Configuración de seguridad incorrecta?
– 1. ¿Tiene implementados procesos que permitan mantener actualizado el software de su organización?. Esto incluye el sistema operativo, los servidores web/aplicación, los sistemas DBMS, las aplicaciones y todas las bibliotecas de código
– 2. ¿Todo lo innecesario ha sido deshabilitado, eliminado o desinstalado (p.e. puertos, servicios, páginas, cuentas de usuario, privilegios)?
– 3. ¿Ha cambiado, o deshabilitado, las contraseñas de las cuentas predeterminadas?
– 4. ¿Ha configurado el sistema de gestión de errores para prevenir que se acceda de forma no autorizada a los mensajes de error?
– 5. ¿Se han comprendido y configurado de forma adecuada las características de seguridad de las bibliotecas y ambientes de desarrollo (p.e. Struts, Spring, SEAM, ASP.NET)?
– Se requiere un proceso concertado, repetible y replicable; para desarrollar y mantener una correcta configuración de seguridad de la aplicación
¿Qué se recomienda para evitar Configuración de seguridad incorrecta?
– 1. Un proceso repetible que permita configurar, rápida y fácilmente, entornos asegurados. Los entornos de desarrollo, pruebas y producción deben estar configurados de la misma forma. Este proceso debe ser automatizado para minimizar el esfuerzo requerido en la configuración de un nuevo entorno
– 2. Un proceso para mantener y desplegar todas actualizaciones y parches de software de manera oportuna. Este proceso debe seguirse en cada uno de los ambientes de trabajo. Es necesario que se incluya las actualizaciones de todas las bibliotecas de código
– 3. Una arquitectura robusta de la aplicación que provea una buena separación y seguridad entre los componentes
– 4. Considerar la realización periódica de exploraciones (scan) y auditorías para ayudar a detectar fallos en la configuración o parches faltantes
¿Qué aspectos facilitan la Exposición de datos sensibles?
– 1. ¿Se almacenan en texto claro a largo plazo, incluyendo sus respaldos?
– 2. ¿Se transmite en texto claro, interna o externamente. El tráfico por Internet es especialmente peligroso?
– 3. ¿Se utiliza algún algoritmo criptográfico débil/antiguo?
– 4. ¿Se generan claves criptográficas débiles, falta una adecuada rotación o
gestión de claves?
– 5. ¿Se utilizan tanto cabezales como directivas de seguridad del navegador cuando son enviados o provistos por él mismo?
¿Cómo se puede evitar la Exposición de datos sensibles?
– 1. Considere las amenazas de las cuáles protegerá los datos (ej: atacante interno, usuario externo), asegúrese de cifrar los datos sensibles almacenados o en tráfico de manera como manera de defenderse de estas amenazas
– 2. No almacene datos sensibles innecesariamente. Descártelos apenas sea posible. Datos que no se poseen no pueden ser robados
– 3. Asegúrese de aplicar algoritmos de cifrado fuertes y estándar, así como claves fuertes y gestiónelas de forma segura
– 4. Asegúrese que las claves se almacenan con un algoritmo especialmente diseñado para protegerlas
– 5. Deshabilite el autocompletar en los formularios que recolectan datos sensibles. Deshabilite también el cacheado de páginas que contengan datos sensibles
¿Qué aspectos demuestran Ausencia de control de acceso a las funciones?
– 1. ¿La interfaz de usuario muestra la navegación hacia funcionalidades no
autorizadas?
– 2. ¿Existe autenticación del lado del servidor o se han perdido las comprobaciones de autorización?
– 3. ¿Los controles del lado del servidor se basan exclusivamente en la información proporcionada por el atacante?
¿Cómo se evita la Ausencia de control de acceso a las funciones?
- El proceso para gestión de accesos y permisos debería ser actualizable y auditable fácilmente. No lo implementes directamente en el código sin utilizar parametrizaciones
- La implementación del mecanismo debería negar todo acceso por defecto, requiriendo el establecimiento explícito de permisos a roles específicos para acceder a cada funcionalidad
- Si la funcionalidad forma parte de un workflow, verifica y asegúrate que las condiciones del flujo se encuentren en el estado apropiado para permitir el acceso
¿Cómo se sabe si existe vulnerabilidad a Falsificación de peticiones en sitios cruzados (CSRF)?
• La forma más sencilla de revisar la vulnerabilidad en una aplicación es verificando si cada enlace, y formulario contiene un testigo (token) no predecible para cada usuario:
– Si no se tiene dicho testigo, los atacantes pueden falsificar peticiones. Se debe concentrar el análisis en enlaces y formularios que invoquen funciones que permitan cambiar estados
– Tales funciones son los objetivos más importantes que persiguen los ataques CSRF
