OWSAP (The Open Web Application Security Project) ha lanzado un top 10 de las vulnerabilidades más críticas en las páginas web. Hoy en día, donde la World Wide Web crece a pasos agigantados los problemas de seguridad en las páginas web cada vez son más grandes.
Hoy les dejo esta información que es de mucha ayuda para aquellos dueños de sitios web o en su defecto los webmaster de esos sitios. Les dejaré las cinco primeras vulnerabilidades, este post será dividido en tres partes para que puede tratar de explicar y desarrollar cada vulnerabilidad para su mejor comprensión y prevenir mejor estas vulnerabilidades sin agobiarlos de tanta información en un post.
OWASP Top Ten 2013 Project
1. Inyecciones de código
El atacante envía simples ataques basados en texto que explotan la sintaxis. Casi cualquier fuente de datos puede ser un vector de inyección, incluyendo fuentes internas.
¿Cómo sucede?
Las fallas de inyección ocurren cuando una aplicación envía datos no confiables a un intérprete. Las fallas de inyección son muy frecuentes, sobre todo en el código heredado. A menudo se encuentran en SQL, LDAP o consultas XPath, comandos del sistema operativo, los analizadores XML, los argumentos del programa, etc. Las fallas de inyección son fáciles de descubrir al examinar el código, pero más difícil a través de pruebas. Scáners y fuzzers pueden ayudar a encontrar a los atacantes.
Consecuencias:
La inyección puede causar la pérdida de datos o la corrupción, la falta de rendición de cuentas, o la denegación de acceso. La inyección a veces puede llevar a la toma de posesión del servidor.
¿Cómo saber si eres vulnerable a las inyecciones?
La mejor manera de saber si una aplicación es vulnerable a la inyección es verificar que todo uso de intérpretes separa claramente los datos no confiables desde el comando o consulta. Para las llamadas SQL, esto significa utilizar variables bind en todas las sentencias preparadas y procedimientos almacenados, evitando consultas dinámicas. La comprobación del código es una forma rápida y precisa para ver si la aplicación utiliza intérpretes de forma segura. Las herramientas de análisis de código pueden ayudar a un analista de seguridad de encontrar el uso de intérpretes y rastrear el flujo de datos a través de la aplicación. Las pruebas de penetración pueden validar estas cuestiones por la elaboración de las hazañas que confirman la vulnerabilidad. El análisis dinámico automatizado que ejerce la aplicación puede ayudar a determinar si existen algunos errores de inyección explotables. Los scanners no siempre pueden llegar a intérpretes y tienen dificultades para detectar si un ataque tuvo éxito. La prueba de gestión de errores hace que los errores de inyección sean fácil de descubrir.
¿Cómo evitar una inyección de código?
La prevención de inyección requiere mantener los datos privados separados de comandos y consultas.
1.La opción preferida es usar una API de seguridad que evite el uso de la totalidad o que el intérprete proporcione una interfaz parametrizada. Tengan cuidado con las APIs, tales como las de procedimientos almacenados, que son parametrizados, porque todavía pueden presentar inyección debajo de la capucha.
2.Si una API con parámetros no está disponible, deben ser cuidadosos con que no se escapen caracteres especiales usando la sintaxis de escape específico para ese intérprete. ESAPI de OWASP proporciona muchas de estas rutinas donde se escapan .
3.También se recomienda usar una "lista blanca" de validación de entrada positiva o canonización apropiada, pero no es una defensa completa ya que muchas aplicaciones requieren caracteres especiales en sus aportaciones. ESAPI de OWASP tiene una biblioteca ampliable de | lista de rutinas de validación de entrada blancas .
EJEMPLOS:
La aplicación utiliza los datos que no son de confianza en la construcción de la siguiente llamada de SQL vulnerables:
String query = "SELECT * FROM cuentas DONDE custID = '" + request.getParameter ("id") + "'";
El atacante modifica el parámetro 'id' en su navegador para enviar: 'o '1' = '1. Esto cambia el significado de la consulta para devolver todos los registros de la base de datos de las cuentas, en lugar de sólo hacer la llamada como cliente.
http://example.com/app/accountView?id = 'o '1' = '1
En el peor de los casos, el atacante utiliza esta debilidad para llamar procedimientos especiales almacenados en la base de datos que permiten una absorción completa de la base de datos y, posiblemente, el servidor que aloja la base de datos.
2. Autenticación y Gestión de Sesiones
¿Qué es?
A esta vulnerabilidad se le reconoce cuando un usuario anónimo intenta introducirse a través de la cuenta de otro o del administrador para robar las cuentas de otros usuarios. Algunos expertos en seguridad opinan que incluso para mantener o seguir las acciones de ciertos usuarios.
¿Cómo sucede?
Normalmente estos ataques suceden después de un ataque SQL o por Phishing, así obteniendo el usuario y la contraseña para después poder acceder a la cuenta para su manipulación. Desarrolladores con frecuencia construyen sistemas de gestión de sesiones y autenticación personalizada, pero la construcción de estos correctamente es difícil. Como resultado, estos esquemas personalizados con frecuencia tienen deficiencias en áreas tales como cierre de sesión, administración de contraseñas, tiempos de espera, el remember me, la pregunta secreta, cuenta de actualización, etc encontrar tales defectos a veces puede ser difícil, ya que cada aplicación es única.
Consecuencias
Tales defectos pueden permitir que algunas o incluso todas las cuentas sean atacadas. Una vez conseguido esto, el atacante puede hacer lo que sea sin que la víctima pueda hacer algo. Las cuentas con privilegios son con frecuencia son blanco de ataques.
¿Cómo saber si eres vulnerable?
Los principales activos de protección son las credenciales y los identificadores de sesión.
¿Las credenciales de autenticación siempre están protegidos cuando se almacena utilizando hash o cifrado? ¿Pueden las credenciales adivinar o sobrescrirse por funciones débiles de gestión (por ejemplo, la creación de cuentas, cambio de contraseña, recuperar la contraseña, ID de sesión débiles)?
¿Son los identificadores de sesión expuestas en la dirección URL (por ejemplo, la reescritura de URL)?
¿Son los identificadores de sesión vulnerables a la fijación de sesión ataques?
¿Cómo puedo evitar este ataque?
. Un único conjunto de controles de autenticación y gestión de sesiones fuertes controles deben esforzarse por:
1. Cumplir con todos los requisitos de autenticación y gestión de sesiones definidas en OWASP Aplicación Verificación de seguridad estándar (ASVS) áreas V2 (autenticación) y V3 (Gestión de la sesión).
2. Tener una interfaz sencilla para los desarrolladores. Considere el autenticador ESAPI y APIs usuario como buenos ejemplos a imitar, usar o aprovechar.
3. También se deben hacer grandes esfuerzos para evitar fallas de XSS que pueden ser utilizados para robar los identificadores de sesión.
Entradas
0 comentarios:
Publicar un comentario