Vulnerabilidad

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.