TOP 10 2007- FALLA DE RESTRICCIÓN DE ACCESO A URL Comúnmente, la única protección de una URL, es que el enlace a esa página no se muestre a usuarios no autorizados. Sin embargo, un atacante motivado, habilidoso o simplemente con suerte, puede ser capaz de encontrar el acceso a estas páginas, invocar funciones, y visualizar información. La seguridad por oscuridad no es suficiente para proteger la funcionalidad e información en una aplicación. La revisión de control de acceso debe ser realizada antes de que una petición a una función sensible se conceda, lo cual asegura que el usuario está autorizado para acceder a esa función. Contenido 1 Entornos afectados 2 Vulnerabilidad 3 Verificando la seguridad 4 Protección 5 Ejemplos 6 Referencias Conclusión. Entornos afectados Todos los entornos de aplicaciones Web son vulnerables a las fallas de restricciones de acceso a URL. Vulnerabilidad El método primario de ataque para esta vulnerabilidad es llamado "navegación forzada", que abarca adivinado de enlaces y técnicas de fuerza bruta para encontrar paginas desprotegidas. Las aplicaciones permiten con frecuencia que el código de control de acceso se desarrolle y se separe a través de código fuente, dando como resultado un modelo complejo que sea difícil de entender para los desarrolladores y para los especialistas de la seguridad también. Esta complejidad hace que sea probable que se produzcan errores de páginas perdidas, dejándolas expuestas Algunos ejemplos comunes de estos defectos incluyen: URL "ocultas" o "especiales", suministradas sólo a administradores o usuarios con privilegios, pero accesibles a todos los usuarios si ellos saben que existen, tales como /administrar/agregarusuario.php o /aprobarTransferencia.do. Esto es particularmente predominante con código de menú. Las aplicaciones a menudo permiten el acceso a archivos "ocultos", tales como XML estáticos o reportes generados por el sistema, confiando en la seguridad por oscuridad para ocultarlos. Código que implementa una política de control de acceso pero no esta actualizado o es insuficiente. Por ejemplo, imagine /aprobarTransferencia.do que alguna vez estuvo disponible para todos los usuarios, pero desde que los controles de SOX fueron traídos, se supone que solo está disponible a los 'aprobadores'. Una solución podría haber sido la de no presentarlo a usuarios no autorizados, pero actualmente no hay un control de acceso implementado, cuando se solicite esa página. Código que evalúa privilegios en el cliente pero no en el servidor, como en este ataque en MacWorld 2007 que permite la aprobación de pases "Platinum" por valor de $1700 a través de JavaScript en el navegador en lugar de en el servidor. Verificando la seguridad El objetivo es verificar que el control de acceso se aplique de forma consistente en la capa de presentación y la lógica de negocio en todas las URL en la aplicación. Enfoques automatizados: Los escáneres de vulnerabilidades y los motores de análisis estático tienen dificultades con la verificación de control de acceso a URLs, pero por razones diferentes. Los escáneres de vulnerabilidades tienen dificultades para adivinar las páginas ocultas y determinar qué páginas se deben permitir para cada usuario, mientras que los motores de análisis estático batallan para identificar los controles de acceso personalizado en el código y vincular la capa de presentación con la lógica de negocio. Enfoques manuales: El método más exacto y eficiente consiste en utilizar una combinación de revisión de código y pruebas de seguridad para verificar el mecanismo de control de acceso. Si el mecanismo es centralizado, la verificación puede ser bastante eficaz. Si el mecanismo esta distribuido a través de todo el código fuente, la verificación puede llevar más tiempo. Si el mecanismo se aplica de manera externa, la configuración debe ser examinada y probada. Protección Tomarse el tiempo para planificar la autorización creando una matriz para definir los roles y las funciones de la aplicación es un paso clave en el logro de la protección contra las fallas de restricción de acceso a URL. Las aplicaciones Web deben hacer cumplir el control de acceso en cada URL y en las funciones de negocio. No basta con poner el control de acceso en la capa de presentación y dejar la lógica de negocio sin protección. Tampoco es suficiente revisar una sola vez durante el proceso para garantizar que el usuario esta autorizado, y no volver a comprobar en las etapas subsiguientes. De lo contrario, un atacante simplemente evitará el paso donde la autorización es revisada, y falsificara los valores de los parámetros indicados para continuar en el siguiente paso. Habilitar control de acceso a URLs requiere una planificación cuidadosa. Entre las consideraciones más importantes se encuentran las siguientes: Garantizar la matriz de control de acceso como parte del negocio, la arquitectura y el diseño de la aplicación. Garantizar que todas las URLs y las funciones de negocio estén protegidas por un control de acceso eficaz que verifique el rol y los derechos del usuario antes de ejecutar cualquier proceso. Asegúrese de que este se hace durante cada paso, y no sólo una vez al principio de un proceso con etapas intermedias. Realice una prueba de intrusión antes de la implantación o entrega del código para asegurar que la aplicación no puede ser usada de manera malintencionada por un atacante experto motivado. Preste mucha atención al incluir archivos de librerías, especialmente si tienen una extensión ejecutable tal como .php. Cuando sea posible, deben mantenerse fuera del directorio raíz de la Web. Se debe verificar que no están siendo accedidas directamente, por ejemplo, revisando una constante que solo puede ser creada por el llamante de la biblioteca. No asuma que pasarán desapercibidas para los usuarios las URLs ocultas o las APIs. Siempre asegúrese de que las acciones administrativas o de altos privilegios están protegidas. Bloquear el acceso a todos los tipos de archivo que su aplicación no deberá servir nunca. Lo ideal sería que este filtro siga el método "aceptar buenos conocidos" y sólo permita tipos de archivos que usted tiene la intención de servir, por ejemplo .html, .pdf, .php. Esto bloqueara cualquier intento de acceder archivos de bitácora, archivo XML, etc., que nunca tuvo la intención de servir directamente. Manténgase al día con la protección antivirus y parches a los componentes, tales como procesadores de XML, los procesadores de texto, procesadores de imagen, etc., que manejan la información de usuario suministrada. Ejemplos http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0147 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0131 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1227 Referencias CWE: CWE-325 (Direct Request), CWE-288 (Authentication Bypass by Alternate Path), CWE-285 (Missing or Inconsistent Access Control) WASC Threat Classification: http://www.webappsec.org/projects/threat/classes/predictable_resource_locatio n.shtml OWASP, http://www.owasp.org/index.php/Forced_browsing OWASP Guide, http://www.owasp.org/index.php/Guide_to_Authorization VOCABULARIO URLs: URL son las siglas de Localizador de Recurso Uniforme (en inglés Uniform Resource Locator), la dirección global de documentos y de otros recursos en la World Wide Web. html, .pdf, .php HTML, siglas de HyperText Markup Language («lenguaje de marcado de hipertexto»), es el lenguaje de marcado predominante para la elaboración de páginas web. PDF (sigla del inglés portable document format, formato de documento portátil) es un formato de almacenamiento de documentos, desarrollado por la empresa Adobe Systems. Este formato es de tipo compuesto (imagen vectorial, mapa de bits y texto). PHP es un lenguaje de programación interpretado, diseñado originalmente para la creación de páginas web dinámicas XML, siglas en inglés de eXtensible Markup Language ('lenguaje de marcas extensible'), es un metalenguaje extensible de etiquetas desarrollado por el World Wide Web Consortium (W3C). Es una simplificación y adaptación del SGML y permite definir la gramática de lenguajes específicos (de la misma manera que HTML es a su vez un lenguaje definido por SGML). Por lo tanto XML no es realmente un lenguaje en particular, sino una manera de definir lenguajes para diferentes necesidades[cita requerida]. La interfaz de programación de aplicaciones de Windows, cuyo nombre en inglés es Windows API (Windows application programming interface), es un conjunto de funciones residentes en bibliotecas (generalmente dinámicas, también llamadas DLL por sus siglas en inglés, término usado para referirse a éstas en Windows) que permiten que una aplicación corra bajo un determinado sistema operativo. Puntos importantes en una auditoria de aplicaciones Web Con las amenazas y controles concretos analizados en la sección anterior en mente, surge la cuestión de qué es lo que debería considerarse a la hora de auditar la seguridad de una aplicación web. Con esto no nos referimos únicamente a una auditoría oficial externa, sino también a elementos que un administrador de seguridad de una empresa debería considerar para determinar las vulnerabilidades de sus sistemas, tanto potenciales (en etapa de desarrollo) como actuales en producción. Existen muchas guías y "checklists" elaborados por empresas y organizaciones sobre este tema, generales o enfocadas a la seguridad lógica o algún otro aspecto en particular, así como específicas a alguna plataforma o no. En particular hemos optado por destacar los siguientes aspectos: Fase de Requerimientos Deben analizarse los requerimientos de usuario y debe verificarse que se incluyan los siguientes elementos: Los recursos y valores (assets) involucrados deben estar debidamente identificados Cómo y en qué condiciones se usará la aplicación Usuarios, roles y permisos deben estar definidos, especificando claramente requerimientos de autenticación y autorización Cuestiones de seguridad legales y relativas al negocio – traza de auditoría, firmas digitales, nivel de encriptación, bitácoras y soporte para no-repudio, etc. Controles de autenticación Si la autenticación en mediante un form, asegurar que los forms sensitivos estén protegidos. Asegurar que el código incluye líneas para reenviar al usuario al form de login si la autenticación falla. Asegurar que la información de autenticación del usuario se almacene en variables de sesión. Control de caracteres especiales La codificación del set de caracteres de cada página debe ser determinada explícitamente por el servidor web. Durante el desarrollo se deben definir procesos de identificación y filtrado de caracteres especiales. Esto debería incluir caracteres tales como: ?<, ?> , ?& , ?" " , tabulaciones, %, paréntesis, _ , /, etc Los elementos dinámicos de salida deben estar codificados, y en particular deben codificarse URL"s y páginas HTML. También deben examinarse cuidadosamente las cookies aceptadas y revisarse las técnicas de filtrado que aseguren que no se almacene contenido peligroso en ellas. Control de Logs La aplicación debe generar archivos de log y la información relativa al acceso a cada recurso debe quedar registrada en los mismos con detalle suficiente para ser útiles. Ej. deben registrarse intentos de login fallidos, creación de conexiones de BD, operaciones rechazadas, etc. Fase de Testing Durante el testeo de la aplicación deben utilizarse scanners de seguridad de aplicación tales como AppScan de Sanctum, Retina de eEye, o Web Inspect de SPI Dynamics. El desarrollador debe considerar en su totalidad las implicaciones de los datos de entrada en términos de URL, métodos, cookies, headers y campos HTTP. Durante el testing deberán analizarse la mayor cantidad de escenarios posibles, y en particular situaciones tales como: si el cliente modifica la URL podría acceder a la sesión de otro usuario? También deben testearse casos como campos de entrada que pudieran desbordar un buffer, o inyectar una sentencia SQL. Documentación Además de la información necesaria para otras áreas, la documentación deberá incluir: •configuración recomendada de servidor y aplicación •permisos sobre cada recurso •especificación de recursos sensibles involucrados •procedimientos adecuados para operar y efectuar cambios. Mensajes de error Es necesario verificar que los mensajes de error de la aplicación no proporcionen información sensible que pudieran utilizarse para vulnerarla, por ejemplo: •rutas físicas •arquitectura de la plataforma tablas de la Base de Datos La configuración del servidor relativa a errores debe ser revisada y conocerse con exactitud como los errores son manejados. Bajo IIS por ejemplo, debe optarse por mensajes de error genéricos al cliente en lugar de mensajes detallados de ASP. Control de tags maliciosos Debe existir un proceso para que los desarrolladores aseguren que las páginas generadas dinámicamente no contengan tags indeseables. Los desarrolladores deben también restringir las variables a los caracteres explícitamente permitidos y hacer que esas variables sean chequeadas durante la generación de la página de salida. Encriptación (SSL) Si bien se lo comentó como insuficiente para proteger un sitio por sí misma, sigue siendo necesaria la encriptación para la transferencia de Ids y passwords a través de internet. Logins de aplicación El código no debe ejecutarse en el servidor de aplicación con el usuario root/administrador, así como no debe acceder a la BD con la cuenta de administrador (ej usuario sa en SQLserver) . ASP/JSP La información sensible sobre credenciales (username/password) para acceder a directorios de membresías y Bases de Datos no debe estar escrita en el código de la página (hardcoded). Controles específicos de Java Verificar que se utilizan los paquetes jave.security, java.security.acl and java.security.interfaces para habilitar permisos y agregar usuarios. En el archivo java.security properties debería incluirse la línea Package.access=Package#1 [,Package#2,...,Package#n] , para proteger el acceso a cada paquete. El security manager debe habilitarse si está disponible. Utilizar el parámetro –Djava.security.debug=help en el inicio para que la salida incluya información de acces y seguridad relevante. La clase SecureRandom debería utilizarse para generar números aleatorios. Chequear el classpath para evitar acceso a clases innecesarias. Revisar los componentes (EJB u otros) y asegurar que el descriptor de cada uno contiene el código que asegura que únicamente el administrador tiene acceso a métodos restringidos. Revisar los archivos de propiedades del servidor J2EE para verificar que sólo administradores autorizados están incluidos en el grupo admin. Controles específicos de Perl Los scripts de Perl deben ejecutarse en modo Tainted (parámetro –T). En este modo se asume que toda la entrada del cliente es "contaminada" y potencialmente dañina a menos que explícitamente el programador la autorize. Puede ejecutarse un script para verificar que una variable contiene datos inseguros, y la presencia de los mismos debe convertir a toda la expresión que los contenga como insegura. Los chequeos de "contaminación" de archivos deben efectuarse sobre los nombres de archivo suministrados por el usuario. Cuando se utiliza un fork a un proceso hijo debe utilizarse la sintaxis abierta que conecta al hijo directamente con el padre y le asigna menos privilegios con respecto a éste. Conclusiones Hemos analizado simplemente algunos de los múltiples aspectos relativos a la seguridad en las aplicaciones web. Aunque claramente se cubrió una pequeña parte del tema, fue suficiente para comprobar lo fácilmente que puede ser vulnerada una aplicación cuando no se le asigna una prioridad adecuada a los controles de seguridad en las distintas etapas de desarrollo. La presente realidad de la industria atenta contra la posibilidad de implementar estos controles en forma adecuada, en particular la creciente complejidad y variedad de tecnologías incrementa de la misma forma la variedad de puntos vulnerables y técnicas de ataque. Muchas de las vulnerabilidades que se pueden presentar son propias de la plataforma sobre la que se desarrolla la aplicación (Sistema Operativo, software de base, herramientas de desarrollo), otras son negligencia por parte de jefes de proyecto, arquitectos, diseñadores, programadores, administradores y usuarios del sistema. Vimos varias medidas de control, que deben ser implementadas en el marco de políticas de seguridad establecidas, ejecutadas en varias fases distintas del ciclo de vida de la aplicación, y controladas por un auditor, que permiten disminuir considerablemente los riesgos e impacto de estas amenazas vistas, aunque difícilmente sea posible asegurar la invulnerabilidad de una aplicación.