Seguridad en desarrollo de aplicaciones Web (página 2)

Partes: 1, 2

No mantiene por sí mismo el estado de la sesión – un atacante no tiene que emular mecanismos de mantenimiento de sesión, basta con emitir un request para lograr el cometido. Mecanismos como el uso de cookies permiten simular una sesión virtual intercambiando información adicional en cada request/response, pero no son efectivas si no se las implementa bien, e introducen problemas adicionales de seguridad y privacidad.

Existen muchas excepciones y variantes adicionales a estos elementos; en particular se utiliza ampliamente SSL como protocolo de encriptación a nivel de transporte en las comunicaciones cliente–servidor. Como explicaremos a continuación, esto está lejos de resolver todas las vulnerabilidades de la aplicación.

Mitos sobre la seguridad web

El usuario solamente enviará entradas esperadas – HTML admite el uso de tags que manipulan la entradas a la aplicación, por ejemplo si la aplicación utiliza campos ocultos para enviar información sensible estos pueden ser fácilmente manipulados desde el cliente.

La validación se puede realizarse únicamente del lado del cliente con JavaScript – si no se efectúa niguna validación del lado del servidor, cualquier atacante que evite esta validación (para nada difícil de lograr) tendrá acceso total a toda la aplicación.

El uso de firewalls es suficiente – como explicamos anteriormente, si el firewall tiene que habilitar los puertos 80 y/o 443 para que la aplicación sea accesible al exterior, no podrá hacer nada para detectar entradas maliciosas del cliente, y por supuesto no es protección contra ataques internos.

El uso de SSL es una solución suficiente – SSL simplemente cubre el request/response HTTP dificultando la intercepcion del tráfico entre cliente y servidor, pero no agrega seguridad al servidor ni evita el envío de código malicioso desde el cliente.

Amenazas comunes

Los múltiples ataques externos a los que puede estar expuesto un sitio web son usualmente clasificados en 6 categorías principales. Indicaremos cada una y los tipos de ataques más típicos que incluyen, y a continuación describiremos en mayor detalle cuatro de ellos.

Autenticación: son las que explotan el método de validación de la identidad de un usuario, servicio o aplicación

Fuerza Bruta

Autenticación insuficiente

Débil validación de recuperación de Password

Autorización: explotan el mecanismo de un sitio web de determinar si un usuario o servicio tiene los permisos necesarios para ejecutar una acción.

Predicción de Credenciales o Sesión

Autorización insuficiente

Expiración de Sesión insuficiente

Fijado de Sesión

Ataques Lógicos : explotan la lógica de la aplicación (el flujo procedural utilizado por la aplicación para efectuar cierta acción.

Abuso de funcionalidad

Denial of Service

Insuficiente Anti-Automatismo

Insuficiente validación de procesos

Manipulación de entradas (URL, campos)

Ataques al cliente : atacan al usuario de la aplicación.

Content Spoofing

Cross-Site Scripting

Ejecución de comandos : ataques diseñados para ejecutar comandos remotos en el servidor.

Buffer Overflow

Format String

LDAP Injection

Ejecucuón de Comandos (OS Commanding)

SQL Injection

SSI Injection

XPath Injection

Robo de Información : ataques que apuntan a adquirir información específica sobre el sitio web.

Indexado de directorio

Caminos transversales

Predicción de ubicación de recursos

Escape de información

Los ataques que vamos a describir son SQL Injection, Manipulación de entradas, Ejecución de Comandos, y Cross Site Scripting

SQL Injection

SQL Injection es una vulnerabilidad que afecta aplicaciones a nivel de base de datos. Dicha vulnerabilidad consiste en enviar instrucciones SQL adicionales a partir de parámetros entrada ingresados por el usuario.

Al "inyectar" el código SQL malicioso dentro de estos campos, el código "invasor" se ejecuta dentro del código SQL propio de la aplicación para alterar su funcionamiento normal, de acuerdo con el propósito del atacante.

SQL Injection es un problema de seguridad que debe ser tomado en cuenta por el programador para prevenirlo. La vulnerabilidad ocurre cuando la aplicación ejecuta una sentencia SQL que utiliza el valor de campos de entrada sin validarlos correctamente.

Permiten al atacante saltar restricciones de acceso, elevar privilegios del usuario, extracción de información de la base de datos, ejecución de comandos dentro del servidor. Incluso es posible destruir parte la base de datos de la aplicación (por ejemplo insertando una sentencia Drop Table).

Ejemplo

Consideremos un simple form de autenticación de usuario contra base de datos

Username: Administrador

Password: xxxxxxx

El form anterior ejecuta la siguiente consulta SQL:

Select idusuario from tabla_usuarios

Where nombre_usuario="$usuario"

And clave="$clave"

Si en lugar del password esperado se ingresa lo siguiente

Username: Administrador

Password: " or "1"="1

La consulta que realmente se ejecuta es la siguiente:

Select idusuario from tabla_usuarios

Where nombre_usuario="Administrador"

And clave="" or "1"="1";

Contramedidas

Los riesgos de SQL Injection pueden superarse relativamente fácil con cambios de programación simples, que sin embargo requieren considerable disciplina de los programadores para aplicar los métodos siguientes para cada procedimiento y función accesibles de la red.

Variables de alcance: La más poderosa protección contra el SQL Injection es utilizar solamente variables de alcance para imposibilitar la concatenación de instrucciones SQL donde puedan aplicarse variables en las instrucciones anexadas.

Validación de la entrada: es necesaria una validación fuerte en lado de servidor para entrada de usuario, validación de datos filtrar la entrada del usuario de caracteres SQL, verificar tanto el tamaño como el tipo de los datos y sintaxis de las entradas de usuario. Este punto se aplica a muchos ataques similares, en particular lo reafirmaremos para los próximos ataques analizados.

Mensajes de error: Los mensajes de error a menudo revelan demasiada información que puede ser útil al atacante (nombres de tablas, campos, vistas); por lo tanto no se deberá exponer al usuario final los mensajes de error devueltos por el gestor de la base de datos.

Los mensajes de errores de la base de datos deberían ser notificados solamente a los administradores de la aplicación.

Manipulación de parámetros

Es un conjunto de técnicas que atacan la lògica de negocio de la aplicación, tomando ventaja del uso de campos ocultos o fijos para la transferencia de información sensible entre browser y servidor. En particular, tags ocultos en un form, cookies o parámetros anexados a la URL son fácilmente modificables por un atacante.

Vamos a analizar dos tipos en particular: manipulación de campos ocultos y manipulación de URL

Manipulación de campos ocultos

Cualquiera de los valores que se almacenan en los campos de un form pueden ser manipulados por un atacante. En particular los campos ocultos son usualmente atractivos para su manipulación ya que muchos desarrolladores los utilizan para información confidencial de estatus de algún objeto sobre el que se está trabajando.

La manipulación de estos campos es tan simple como salvar la página, editar el valor de estos campos en su código HTML y recargarla en el browser.

Ejemplo

Un form de orden de productos incluye el siguiente campo oculto

Basta con modificar este campo para que, a menos que exista una validación posterior del lado del servidor, la aplicación cobre por el artículo el precio dispuesto por el usuario.

Manipulación de URL

Los forms HTML envían sus resultados usando uno de dos métodos posibles: GET o POST. Si el método es GET, todos los parámetros del form y sus valores correspondientes aparecen en cadena de búsqueda del siguiente URL que el usuario ve. Esta cadena puede ser fácilmente manipulable

Ejemplo 1

Un sitio web permite a un usuario autenticado seleccionar una de sus cuentas a partir de un combo, y debitar un monto fijo de esa cuenta. Cuando se presiona Submit en el browser, se solicita la siguiente URL:

http://www.mydomain.com/example.asp?accountnumber=12345&debitamount=1

Un usuario malicioso puede modificar los parámetros de la URL (accountnumber and debitamount), para debitar otra cuenta:

http://www.mydomain.com/example.asp?accountnumber=67891&creditamount=9999

Existen otros parámetros URL que podrian ser modificados, tales como atributos y módulos internos. Los atributos son parámetros únicos que caracterizan el comportamiento de la página que se envía.

Ejemplo 2

Una aplicación web para compartir contenidos permite únicamente al creador del mismo modificarlo, y chequea si el usuario que accede una entrada es el autor o no. Un usuario normal solicitaría el siguiente link:

http://www.mydomain.com/getpage.asp?id=77492&mode=readonly

Un usuario malicioso puede modificar el parámetro mode a readwrite para obtener permisos indebidos sobre el contenido.

Ejecución de comandos

Las técnicas de manipulación de entrada vistas son sólo algunas que llevan a la posibilidad de ejecutar remotamente comandos del Sistema Operativo de la víctima.

Determinados caracteres especiales pueden ser interpretados por scripts de validación poco seguros como una instrucción al SO de esperar un comando arbitrario a continuación. En particular, el punto y coma o la barra | son en Unix caracteres que permiten encadenar comandos. Por tanto incluir en el campo de entrada un ; seguido del comando que se desea ejecutar puede tener éxito si el mecanismo de validación no es lo bastante robusto.

Ejemplo

La aplicación recibe un número de 8 dígitos cuando el usuario selecciona una opción de menú. El form HTML llama a un script escrito en comandos de Shell pasándole por parámetro este número. El código HTML desplegado por el browser tiene esta forma:

Jones Energy Services Co.

el atacante guarda este form en su máquina y lo modifica agregándole un comando arbitrario:

Jones Energy Services Co.

el atacante abre su copia del form desde su máquina y selecciona la opción correspondiente.

el script pasa el número normalmente, y pasa al siguiente comando en la cadena, que es ejecutado en el servidor y abre una terminal en el mismo dándole al atacante completo acceso.

Contramedidas

En la mayoría de los ataques de inyección de comandos, es necesario tener conciencia de que todo dato hacia y desde un browser puede ser modificado. Por ende, la validación propiamente dicha de cada dato de entrada debe darse en el servidor, fuera del control del usuario.

Adicionalmente el servidor debería además configurarse para requerir una autenticación debida al nivel del directorio para cada archivo en el mismo. Aún así esta solución no es perfecta, por lo que es conveniente que el usuario utilizado por la aplicación sobre el servidor tenga los permisos mínimos necesarios, para minimizar el posible impacto.

Cross Site Scripting (XSS)

Esta amenaza surge de los riesgos inherentes de permitir a un servidor web enviar código ejecutable (en cualquier lenguaje de scripting embebido en HTML) a un browser. Cuando a un script de una página se le permite acceder a datos de otra página u objeto, existe la posibilidad de que un sitio web malicioso, lo utilice para obtener información confidencial.

El cross site scripting, aprovecha las vulnerabilidades en los mecanismos de validación de interaccion entre paginas y objetos y en lenguajes scripting que ejecutan en el cliente.

Existe tres tipos conocidos que vulnerabilidades que implican

Tipo 1 – XSS local

En esta categoría el problema reside en el propio script del lado del ciente de la página. Por ejemplo si un fragmento de JavaScript accede un parámetro de un request HTML y lo utiliza para escribir HTML en su propia página, no codificándolo como entidades HTML, se presenta la vulnerabilidad. Estos datos serán reinterpretados por los browsers como HTML, que podría incluir código adicional (maligno).

Tipo 2 – XSS reflejado

Este es el tipo más común, también es conocido como no-persistente. La vulnerabilidad se presenta cuando los datos provistos por el cliente es utilizada inmediatamente por scripts del lado del servidor para generar la página de resultados. Si datos no validados provistos por el cliente son incluidos en la página de resultados sin una codificación apropiada, es posible insertar codígo desde el lado del cliente. Basta con un poco de ingeniería social para llevar a un usuario desprevenido a seguir un link malicioso que inserte este código en la página de resultados, obteniendose acceso total a su contenido.

Tipo 3 – XSS persistente

Este tipo incluye los ataques más poderosos. La vulnerabilidad existe cuando los datos provistos por el cliente a la aplicación es almacenada persistentemente en el servidor, y accesible a varios usuarios del sitio sin codificación de entidades HTML – por ejemplo message boards. El atacante puede insertar un script una única vez, y con esto le basta para alcanzar a un gran número de usuarios, sin requerir mucho esfuerzo de ingeniería social. Los métodos de inserción son variados y no es necesario utilizar la aplicación misma para explotar la vulnerabilidad.

Ejemplos

Presentaremos un ejemplo de cada uno de los tipos mencionados anteriormente.

Ejemplo1 – XSS local

Atacante envía a usuario, via email u otro mecanismo, la URL de una página fraudulenta.

Usuario cliquea en el link

Un código JavaScript en la página abre una página HTML vulnerable local a la máquina del usuario.

La página HTML es obligada a ejecutar código JavaScript en la localidad de la máquina del usuario

El atacante puede ahora ejecutar comandos en la máquina del usuario con los permisos de éste.

Ejemplo 2 – XSS reflejado

El usuario visita frecuentemente un website particular. El servidor de este sitio le permite al usuario loguearse con un ID/pswd propio y almacena información confidencial (tarjeta de crédito).

El atacante verifica una vulnerabilidad de XSS reflejada en el servidor.

El atacante genera una URL y la envía al usuario simulando ser el servidor del sitio (mediante spoofing).

El usuario visita esta URL estando logueado en el servidor.

Un script maligno embebido en la URL se ejecuta en el browser del usuario tal como si proviniera del servidor, obteniendo información confidencial del usuario y enviandola al servidor web del atacante.

Ejemplo 3 – XSS persistente

El servidor de un sitio web permite a sus usuarios publicar mensajes y otros contenidos en el mismo para acceso de otros miembros.

El atacante detecta una vulnerabilidad de XSS persistente en el servidor.

El atacante postea un mensaje con un script insertado, asegurándose que muchos otros usuarios del sitio querrán leerlo por cualquier motivo.

Mediante el simple acceso al mensaje, el script insertado puede hacer que cookies de sesión u otra información de autenticación podría enviarse al servidor web del atacante.

El atacante podria ahora loguearse como otros usuarios al sitio

Contramedidas

Preferentemente no debería permitirse código HTML en los campos de entrada, en caso de que se necesitara, deberían de validarse los tags, descartando aquellos que pudieran ser peligrosos, adicionalmente también se deben descartar caracteres potencialmente peligrosos como -,",",?,&,<,>,etc.

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.