Los Diez Riesgos Más Importantes en Aplicaciones WEB Top 10-2010 A1-Inyección (SQL,OS Y LDPA) Oscar William Monsalve Luis Alberto Suarez Jorge Eliecer Betancur Diana Marcela Usuga G.
Contenido Presentación Objetivo Acerca de OWASP Oswasp La Guía de Desarrollo La Guía de Revisión de Código La Guía de Pruebas Top Vulnerabilidades Owasp para el año 2010 Riesgos de Seguridad Aplicaciones Web Qué son los riesgos de seguridad en las aplicaciones? Agujeros de Seguridad Clasificación de las Amenazas Seguridad
Inyección A1-Inyección Soy Vulnerable Como puedo evitar esto Ejemplos de escenarios de ataque Tipos de Fallas de Inyección Inyección SQL Inyección LDAP Inyección de Código SSI Inyección Xpath Dudas e inquietudes
Objetivos Identificar todos los tipos conocidos de ataque a la seguridad de las aplicaciones web. Desarrollar una forma estructurada de organizar los tipos de ataque, enfocándonos principalmente el la Inyección
Acerca de OWASP
OWASP La Open Web Application Security Project (OWASP) es una organización a nivel mundial centrada en proveer asistencia para mejorar la seguridad de nuestras aplicaciones. Su principal misión es difundir información sobre vulnerabilidades y fallos en su guía para que las organizaciones y los desarrolladores puedan aplicarla para evitar riesgos reales de seguridad. Todo el material que generan se encuentra disponible bajo una licencia Open Source. Al tratarse de una organización que no está vinculada con empresas de servicios informáticos ni de software sus publicaciones son absolutamente independientes y no aceptan presiones de ningún tipo. Fundamentalmente, su proyecto se basa en estos productos: Guía de Desarrollo, Guía de Pruebas de aplicaciones y la Guía de revisión de código, así como un ranking de las vulnerabilidades más activas durante un año.
La Guía de Desarrollo Esta guía es un compendio de buenas costumbres y de sugerencias a implantar en el proceso de codificación de aplicaciones web para poder generar aplicaciones de calidad en cuanto a seguridad se refiere. Son directrices que evitan malos hábitos contando cómo se deben codificar diferentes patrones y soluciones teniendo siempre en mente la posibilidad de un ataque de alta capacidad técnica. La Guía de Revisión del Código De igual manera, disponen de una guía para revisar el código que ya está generado, porque a veces no somos nosotros los que codificamos sino que la aplicación ya existe o se ha comprado. Esta guía se divide en metodologías, pistas para recorrer el código yendo lo más directo posible al problema y la magnífica lista de malas prácticas en el desarrollo de diversos lenguajes (Java,ASP,PHP,C,C++ y SQL).
La Guía de Pruebas La guía de pruebas se encuentra a punto de pasar a versión 4, estando disponible en este momento la versión 3 en forma de wiki, puede ser la más interesante de las tres. Nos resume y muestra los posibles puntos de entrada en las aplicaciones y cómo explotarlos. Los ejemplos son muy gráficos y están muy bien explicados, llegando a dar miedo y producir el efecto de creo que esto lo tengo hecho mal en varios sitios, lo que se conoce como Dios mío! Pero que he hecho!.
Top vulnerabilidades OWASP para el año 2010 El 19 de abril de 2010 terminaron de recopilar y afinar los resultados para 2010, que son los siguiente : A1: Inyección (SQL,OS,LDAP) A2: Secuencia de comandos en sitios cruzados (XXS) A3: Pérdida de Autenticación y Gestión de Sesiones A4: Referencia Directa Insegura a Objetos A5: Falsificación de Peticiones en Sitios Cruzados (CSRF) A6: Defectuosa Configuración de Seguridad A7: Almacenamiento Criptográfico inseguro A8: Falta de restricción de acceso a URL A9: Protección insuficiente en la capa de transporte A10: Redirecciones y Reenvíos no validos
Riesgos de Seguridad Aplicaciones Web
Qué son los riesgos de seguridad en las aplicaciones? Los atacantes pueden potencialmente usar muchas rutas a través de sus propias aplicaciones para causar daño en su negocio u organización. Cada una de las cuales puede ser no lo suficientemente serio como para merecer atención. OWASP se enfoca en identificar los riesgos más seros para un amplio espectro de organizaciones, cada uno provee información genérica acerca de la debilidad e impacto técnico utilizando un esquema basado en la metodología de evaluación de riesgos
Agujero de Seguridad Un agujero de seguridad es un fallo en un programa que permite mediante su explotación violar la seguridad de un sistema informático, se ha comenzado a aplicar a los servicios web, tales como páginas web, correo, IRC, MSN, chat, etc., con el objetivo de obtener información de personas que usen el servidor. A las personas que buscan errores en los sitios webs se les llama hackers, y a las que aprovechan dichas fallas para su beneficio particular, en contra del bien común, se les llama crackers. Vulnerabilidad Causas Los agujeros de seguridad suelen generarse en la negligencia o la inexperiencia de un programador. Puede haber otras causas ligadas al contexto. Una vulnerabilidad por lo general permite que el atacante pueda engañar a la aplicación, por ejemplo, esquivando los controles de acceso o ejecutando comandos en el sistema donde se aloja la aplicación, algunas vulnerabilidades se producen cuando la entrada de un usuario no es controlada, permitiendo la ejecución de comandos o solicitudes SQL (conocidos como Inyección SQL).
Identificación y corrección de vulnerabilidades Hay muchas herramientas que pueden facilitar el descubrimiento de vulnerabilidades en sistemas informáticos, algunas permiten su supresión. Pero, si bien estas herramientas pueden proporcionar a un auditor una buena visión general de este tipo de vulnerabilidades potenciales, no pueden sustituir el juicio humano. Confiar en escáneres automáticos de la vulnerabilidad producirá muchos falsos positivos y una visión limitada de los problemas presentes en el sistema. Ejemplos de vulnerabilidades Los agujeros de seguridad de aquí debajo se encuentran entre los más conocidos: Desbordamiento de búfer Inyección SQL Cross Site Scripting
Clasificación de las Amenazas Autenticación Fuerza Bruta 1 Un ataque de fuerza bruta es un proceso automatizado de prueba y error utilizado para adivinar un nombre de usuario, contraseña, número de tarjeta de crédito o clave criptográfica. Autenticación Insuficiente 2 La autenticación insuficiente ocurre cuando un sitio web permite a un atacante acceder a contenido sensible o funcionalidades sin haberse autenticado correctamente. Débil Validación en la Recuperación de Contraseñas 3 La débil validación en la recuperación de contraseñas se produce cuando un sitio web permite a un atacante obtener, modificar o recuperar, de forma ilegal, la contraseña de otro usuario. Autorización Predicción de Credenciales/Sesión 4 La predicción de credenciales/sesión es un método de secuestro o suplantación de un usuario del sitio web. Autorización Insuficiente 5 La autorización insuficiente se produce cuando un sitio web permite acceso a contenido sensible o funcionalidades que deberían requerir un incremento de las restricciones en el control de acceso. Expiración de Sesión Insuficiente 6 La expiración de sesión insuficiente se produce cuando un sitio web permite a un atacante reutilizar credenciales de sesión o IDs de sesión antiguos para llevar a cabo la autorización. Fijación de Sesión 7 La fijación de sesión es una técnica de ataque que fuerza al ID de sesión de un usuario a adoptar un valor determinado.
Ataques en la parte cliente Suplantación de Contenido 8 La suplantación de contenido es una técnica de ataque utilizada para engañar al usuario haciéndole creer que cierto contenido que aparece en un sitio web es legítimo, cuando en realidad no lo es. Cross-site Scripting 9 Cross-site Scripting (XSS) es una técnica de ataque que fuerza a un sitio web a repetir código ejecutable facilitado por el atacante, y que se cargará en el navegador del usuario. Ejecución de comandos Desbordamiento de Buffer 10 La explotación de un desbordamiento de buffer es un ataque que altera el flujo de una aplicación sobreescribiendo partes de la memoria. Ataques de Formato de Cadena 11 Los ataques de formato de cadena alteran el flujo de una aplicación utilizando las capacidades proporcionadas por las librerías de formato de cadenas para acceder a otro espacio de memoria. Inyección LDAP 12 La inyección LDAP es una técnica de ataque usada para explotar sitios web que construyen sentencias LDAP a partir de datos de entrada suministrados por el usuario. Comandos de Sistema Operativo 13 Los comandos de sistema operativo es una técnica de ataque utilizada para explotar sitios web mediante la ejecución de comandos de sistema operativo a través de la manipulación de las entradas a la aplicación. Inyección de código SQL 14 La inyección de código SQL es una técnica de ataque usada para explotar sitios web que construyen sentencias SQL a partir de entradas facilitadas por el usuario. Inyección de código SSI 15 La inyección de código SSI (Server-side Include) es una técnica de explotación en la parte servidora que permite a un atacante enviar código a una aplicación web, que posteriormente será ejecutado localmente por el servidor web. Inyección XPath 16 La inyección XPath es una técnica de ataque utilizada para explotar sitios web que construyen consultas Xpath con datos de entrada facilitados por el usuario.
Revelación de información Indexación de Directorio 17 La indexación/listado automático de directorio es una función del servidor web que lista todos los ficheros del directorio solicitado si no se encuentra presente el fichero de inicio habitual. Fuga de Información 18 La fuga de información se produce cuando un sitio web revela información sensible, como comentarios de los desarrolladores o mensajes de error, que puede ayudar a un atacante para explotar el sistema. Path Traversal 19 La técnica de ataque Path Traversal fuerza el acceso a ficheros, directorios y comandos que potencialmente residen fuera del directorio document root del servidor web. Localización de Recursos Predecibles 20 La localización de recursos predecibles es una técnica de ataque usada para descubrir contenido y funcionalidades ocultas en el sitio web. Ataques lógicos Abuso de Funcionalidad 21 El abuso de funcionalidad es una técnica de ataque que usa las propias capacidades y funcionalidades de un sitio web para consumir, estafar o evadir mecanismos de control de acceso. Denegación de Servicio 22 La denegación de servicio (Denial of Service, DoS) es una técnica de ataque cuyo objetivo es evitar que un sitio web permita la actividad habitual de los usuarios. Anti-automatización Insuficiente 23 La anti-automatización insuficiente se produce cuando un sitio web permite a un atacante automatizar un proceso que sólo debe ser llevado a cabo manualmente. Validación de Proceso Insuficiente 24 La validación de proceso insuficiente se produce cuando un sitio web permite a un atacante evadir o engañar el flujo de control esperado por la aplicación.
Seguridad En el desarrollo de una aplicación Web siempre se debe considerar lo siguiente: Seguridad: Característica que indica que un sistema esta libre de todo peligro, daño o riesgo. Fiabilidad: Probabilidad de que un sistema se comporte tal y como se espera de el. Confidencialidad: La información en un sistema de cómputo y la transmitida por un medio de comunicación, ha de ser accedida SÓLO por los actores autorizados. Integridad: La información sólo puede ser modificada por actores autorizados. Disponibilidad: La información ha de permanecer accesible a los actores autorizados.
Inyección
A1- Inyección Las fallas de inyección, tales como SQL, OS y LDAP, ocurren cuando datos no confiables son enviados a un interprete como parte de un comando o consulta. Los datos hostiles del atacante pueden engañar al interprete en ejecutar comandos no intencionados o acceder a datos no autorizados.
Considerar cualquier persona que pueda enviar datos no confiables al sistema, incluyendo usuarios externos, internos y administradores. El atacante envía simples cadenas de texto que explotan la sintaxis del interprete atacado. Casi cualquier fuente de datos puede ser un vector de inyección, incluyendo fuentes internas. Las fallas de inyección ocurren cuando una aplicación envía datos no confiables a un interprete. Las fallas de inyección son muy prevalentes, particularmente en código legado, el cual es frecuentemente encontrado en consultas SQL, LDAP, XPath, comandos de SO, argumentos de programa, etc. Las fallas de inyección son fácil de descubrir cuando se examina el código, pero mas difícil a través de testeos. Los scanners y fuzzers pueden ayudar a los atacantes a descubrir estas fallas. Una falla de inyección puede resultar en perdida o corrupción de datos, falta de integridad, o negación de acceso. Una falla de inyección puede algunas veces llevar a la toma de posesión completa del servidor. Considerar el valor para el negocio de los datos afectados y la plataforma corriendo el interprete. Todos los datos pueden ser robados, modificados, o eliminados. Puede su reputación ser dañada?
Soy Vulnerable? La mejor manera de saber si una aplicación es vulnerable a inyección es verificar que todo uso de los interpretes claramente separe datos no confiables del comando o consulta. Para llamados SQL, esto significa utilizar variables parametrizadas en todas las declaraciones preparadas y procedimientos almacenados, como así también evitar consultas dinámicas. Revisar el código es una manera fácil y efectiva para ver si la aplicación utiliza los interpretes de manera segura. Las herramientas de análisis de código pueden ayudar a un analista de seguridad a encontrar la utilización de interpretes y rastrear el flujo de datos en la aplicación. Los testeos de penetración pueden validar estos problemas a través de fallas especialmente hechas a mano que confirman la vulnerabilidad.
Como puedo evitar esto? Prevenir la inyección requiere mantener los datos no confiables separados de comandos y consultas. 1.La opción preferida es utilizar una API segura que evite el uso del interprete completamente o provea una interface parametrizada. Sea cuidadoso con APIs, tales como procedimientos almacenados, que son parametrizados, pero que aun pueden introducir inyección implícitamente. 2.Si una API parametrizada no se encuentra disponible, usted debe cuidadosamente escapar los caracteres especiales utilizando una sintaxis de escape especial para dicho interprete. OWASP s ESAPIposee algunas de estas rutinas de escape. 3.Una validación positiva de entradas con una apropiada canonicalización es también recomendado, pero no es una defensa completa ya que muchas aplicaciones requieren caracteres especiales en sus entradas. OWASP s ESAPItiene una librería extensible de rutinas de validación de entradas.
Ejemplos de escenarios de ataque La aplicación utiliza datos no confiables en la construcción de la siguiente consulta vulnerable SQL: String query = "SELECT * FROM accounts WHEREcustID='" + request.getparameter("id") +"'"; El atacante modifica el parámetro id en su navegador para enviar: ' or '1'='1. Esto cambia el significado de la consulta devolviendo todos los registros de la tabla ACCOUNTS en lugar de solo el cliente solicitado. http://example.com/app/accountview?id=' or '1'='1 En el peor caso, el atacante utiliza esta vulnerabilidad para invocar procedimientos almacenados especiales en la base de datos que permiten la toma de posesión de la base de datos y posiblemente también al servidor que aloja la misma.
Tipos de Fallas de Inyección
Inyección SQL La inyección de código SQL es una técnica de ataque usada para explotar sitios web que construyen sentencias SQL directamente a partir de datos facilitados por el usuario. Cuando una aplicación web no realiza de la forma apropiada el saneamiento de los datos facilitados por el usuario, es posible para un atacante alterar la construcción de las sentencias SQL. Cuando el atacante puede modificar una sentencia SQL, el proceso se ejecutará con los mismos permisos que el componente que ejecutó el comando (por ejemplo: servidor de base de datos, servidor de aplicaciones web, servidor web, etc.). El impacto de este ataque le puede permitir al atacante obtener control total sobre la base de datos o también ejecutar comandos en el sistema. Las mismas técnicas de explotación avanzadas disponibles en la inyección LDAP pueden ser aplicadas de forma similar en la inyección de código SQL.
La inyección SQL es fácil de evitar, por parte del programador, en la mayoría de los lenguajes de programación que permiten desarrollar aplicaciones web. En la siguiente sección se trata brevemente ese tema. Algunas formas de evitar la Inyección SQL PHP En el lenguaje PHP, hay diferentes funciones que pueden servir de ayuda para usar con distintos sistemas de gestión de bases de datos. Para MySQL, la función a usar es mysql_real_escape_string: $query_result = mysql_query("select * FROM usuarios WHERE nombre = \"". mysql_real_escape_string($nombre_usuario). "\"");
Java En lenguaje Java, se puede usar la clase PreparedStatement En lugar de: Connection con = (acquire Connection) Statement stmt = con.createstatement(); ResultSet rset = stmt.executequery("select * FROM usuarios WHERE nombre = '" + nombreusuario + "';"); se puede usar parametrización o escape de variables, como se indica en los siguiente apartados. Parametrización de sentencias SQL Connection con = (acquire Connection) PreparedStatement pstmt = con.preparestatement("select * FROM usuarios WHERE nombre =?"); pstmt.setstring(1, nombreusuario); ResultSet rset = pstmt.executequery();
Ejemplo Una autenticación basada en web podría usar un código similar al siguiente: En este código, el desarrollador está tomando los datos facilitados por el usuario desde el formulario y concatenándolos directamente en la consulta SQL. Suponiendo que un atacante envía un usuario y contraseña similares a los siguientes: Login: ' OR ''=' Password: ' OR ''= Esto provocará que la consulta SQL resultante sea:
En lugar de comparar los datos suministrados por el usuario con las entradas en la tabla Users, la consulta compara '' (cadena vacía) con '' (cadena vacía). Esto devolverá un resultado True y el atacante iniciará sesión con el primer usuario de la tabla Users. Existen dos métodos ampliamente conocidos de inyección de código SQL: inyección normal de código SQL e inyección ciega de código SQL. El primero es la inyección de código SQL en la cual el atacante puede formatear su consulta para emparejarla con la del desarrollador, utilizando la información contenida en los mensajes de error que son devueltos en la respuesta.
Inyección normal de código SQL Agregando una sentencia union select al parámetro, el atacante puede realizar pruebas para ver si puede obtener acceso a la base de datos: http://example/article.asp?id=2+union+all+select+name+from+sysobjects El servidor SQL podría retornar un error similar al siguiente:
Esto le informa al atacante que ahora debe adivinar el número correcto de columnas para que la sentencia SQL se ejecute correctamente. Inyección ciega de código SQL En la inyección ciega de código SQL, en vez de retornar un error de base de datos, el servidor retorna una página de error amigable al usuario, informándole que ha ocurrido un error. En este escenario, la inyección de codigo SQL todavía es posible, pero no es sencilla de detectar. Una forma habitual de detectar la inyección ciega de código SQL es añadir una sentencia de verdadero o falso en el valor del parámetro Ejecutando la siguiente petición en un sitio web: http://example/article.asp?id=2+and+1=1 debería retornar la misma página web que: http://example/article.asp?id=2 porque la sentencia SQL 'and 1=1' siempre es verdadera. Ejecutando la siguiente petición en un sitio web: http://example/article.asp?id=2+and+1=0.
causaría que el sitio web retornara un error amigable o ninguna página. Esto es así porque la sentencia SQL "and 1=0" siempre es falsa. Una vez que el atacante descubre que un sitio es vulnerable a inyección ciega de código SQL, puede explotar esta vulnerabilidad más fácilmente que, en algunos casos, usando inyección normal de código SQL.
Inyección LDAP La inyección LDAP es una técnica de ataque usada para explotar sitios web que construyen sentencias LDAP directamente desde datos facilitados por el usuario. Cuando una aplicación web no realiza un saneamiento adecuado de los datos facilitados por el usuario, es posible para un atacante alterar la construcción de la sentencia LDAP. Cuando un atacante puede modificar una sentencia LDAP, el proceso se ejecutará con los mismos permisos del componente que ejecutó el comando. (por ejemplo: servidor de base de datos, servidor de aplicación web, servidor web, etc.). Esto puede causar graves problemas de seguridad donde los permisos establecen derechos de consulta, modificación o eliminación de cualquier elemento dentro del árbol LDAP. Las mismas técnicas avanzadas de explotación disponibles para inyección de código SQL pueden ser aplicadas de forma similar a la inyección LDAP.
Ejemplo Código vulnerable con comentarios:
Viendo el código, observamos en la linea 10 que la variable username está inicializada con el valor del parámetro usuario y luego rápidamente validada para ver si el valor es nulo. Si el valor no es nulo, la variable username es usada para inicializar la variable filter en la linea 18. Esta nueva variable es utilizada directamente para construir una consulta LDAP que será usada en la llamada a SearchFilter en la linea 27. En este escenario, el atacante tiene control completo sobre lo que será consultado en el servidor LDAP, y obtendrá el resultado de la consulta cuando el código llegue de la linea 32 hasta la 40, donde todos los resultados y sus atributos son mostrados al usuario.
Ejemplo de ataque http://example/ldapsearch.asp?user=* En el ejemplo anterior, enviamos el carácter * en el parámetro user el cual acabará en la variable filter en el código que será inicializado con (uid=*). La sentencia LDAP resultante hará retornar al servidor cualquier objeto que contenga un atributo uid.
Inyección de código SSI La inyección de código SSI (server-side Include) es una técnica de explotación en la parte del servidor que permite a un atacante enviar código a la aplicación web, el cual será luego ejecutado localmente por el servidor. La inyección de código SSI explota la vulnerabilidad introducida por una aplicacion web que no realiza de forma adecuada el saneamiento de los datos facilitados por el usuario, antes de que sean insertados en un archivo HTML interpretado por el servidor. Antes de servir una pagina web HTML, un servidor web puede interpretar y ejecutar sentencias SSI. En algunos casos (por ejemplo: foros, libros de visitas, sistemas de administracion de contenido, etc.) una aplicación web insertará los datos facilitados por el usuario en el código fuente de una página web. Si un atacante envia una sentencia SSI, podría tener la capacidad de ejecutar comandos arbitrarios de sistema operativo, o incluir el contenido de un archivo restringido la siguiente vez que la página sea servida.
Ejemplo La siguiente etiqueta SSI puede permitir a un atacante obtener el listado del directorio raíz en un sistema basado en Unix. La siguiente etiqueta SSI puede permitir a un atacante obtener la cadena de conexión a la base de datos, u otros datos sensibles que se encuentren dentro de un archivo de configuración de.net.
Inyección XPath La inyección XPath es una técnica de ataque usada para explotar sitios web que construyen consultas XPATH directamente a partir de datos facilitados por los usuarios. La sintaxis tiene una cierta semejanza a una consulta SQL, y de hecho, es posible formar consultas tipo SQL en un documento XML usando XPath. Por ejemplo, supongamos que un documento XML contiene elementos de nombre user, cada uno de los cuales contiene tres sub elementos - name, password y account. La siguiente expresión XPatch retorna el número de cuenta del usuario cuyo nombre es "jsmith" y su contraseña es "Demo1234" (o retorna una cadena vacía si no existe el usuario)
Si una aplicación construye consultas XPath de forma dinámica concatenando datos inseguros facilitados por el usuario, resulta posible para un atacante inyectar datos en la consulta que permitan que la nueva consulta formada con esos datos sea interpretada de forma diferente a la intención del programador. Ejemplo Consideremos una aplicación web que usa XPath para consultar un documento XML y obtener el número de cuenta a partir de un usuario y contraseña enviados por el cliente. Esta aplicación podría concatenar directamente estos valores en la consulta XPath creando un agujero de seguridad. Ejemplo (usando Microsoft ASP.NET y C#):
Cuando este código es ejecutado, un atacante puede inyectar expresiones XPath, como por ejemplo: facilitando el siguiente valor como nombre de usuario: ' or 1=1 or ''=' Esto causa que la semántica del XPath original cambie, por eso siempre retorna el primer número de cuenta en el documento XML. La consulta en este caso será: La cual es idéntica (dado que la expresión es evaluada como verdadera en todos los nodos) a: string(//user/account/text()) y retorna la primera instancia de //user/account/text(). El ataque resulta en que el atacante inicia sesión (como el primer usuario listado en el documento XML), aunque el atacante no facilite ningún nombre de usuario y contraseña válidos.
Videos donde se Muestra Inyección SQL
Dudas e Inquietudes
Fin de la Presentación Gracias!