Seguridad en desarrollo de aplicaciones Web (página 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.

Bibliografía

Hacking Exposed Web Applications

Joel Scambray and Mike Shema 

McGraw-Hill/Osborne © 2002

XSS, Ejecución de parámetros, SQL
Injection

Improving Web Application Security: Threats and
Countermeasures

Microsoft Corporation 

Microsoft Press © 2003

Introducción, tipos de amenazas, mitos sobre
seguridad

Auditing Web Applications

Nilesh Chaudhari

www.paladion.net/pdf/WebAppSec-ISACA-08-29.ppt

Amenazas inherentes, SQL Injection

Web Applications Checklist

Krishni Naidu

www.sans.org/score/checklists/WebApplicationChecklist.doc

Puntos de auditoría

Autor:

Sebastián Lopez

Universidad Católica del Uruguay

Facultad de Ingeniería y
Tecnologías

Ingeniería en Informática

Octubre 2006