MÉTODOS DE SEGURIDAD EN LA WEB
Introducción a la Seguridad en Sistemas Web
Un efecto secundario del crecimiento exponencial que ha
tenido el Internet es la privacidad de información tanto personal como
profesional. En Internet encontramos funcionando a tiendas en línea, negocios
que mueven grandes cantidades de dinero, redes de los servicios que habilitan
el comercio a nivel internacional así como sitios de redes sociales que
contienen información muy delicada de la vida privada de sus miembros.
Mientras más se conecta el mundo, la necesidad de seguridad
en los procedimientos usados para compartir la información se vuelve más importante.
Desde muchos puntos de vista, podemos creer sin dudar que el punto más crítico
de la seguridad del Internet, lo tienen las piezas que intervienen de forma
directa con las masas de usuarios, los servidores web.
Respecto a los servidores web, es común escuchar sobre
fallas en los sistemas de protección de los servidores más frecuentemente
utilizados (Apache, IIS, etc.), o en los lenguajes de programación en los que
son escritas las aplicaciones que son ejecutadas por estos servidores. Pero es
un hecho, que la mayoría de los problemas detectados en servicios web no son
provocados por fallas intrínsecas de ninguna de estas partes, ya que una gran
cantidad de los problemas se generan por malos usos por parte de los
programadores.
Problemas principales en
la Programación de Sistemas Web
Una gran parte de los problemas de seguridad en las
aplicaciones web son causados por la falta de seguimiento por parte del
programador en los siguientes aspectos:
- Entradas
al sistema
- Salidas
del sistema
Quizás uno de los consejos de seguridad en PHP más conocido
en cualquier foro de Internet es el uso del parámetro register_globals que
es considerado a priori por muchos administradores como un defecto en la
configuración y muy probablemente sin entender con cabalidad que es lo que
implica esta configuración.
El tener habilitado este parámetro oculta el origen
de los datos. Si se encuentra habilitado, no podemos saber como es que una
variable entró al sistema (si lo hizo por medio de una petición GET o POST por
ejemplo) y contribuye a la pérdida del control por parte del programador sobre
los procesos a los que se ha sometido cada variable para librarla de riesgos
potenciales para la aplicación.
Otro aspecto importante además de los procesos de
verificación que se deben de tener para con las entradas y salidas del sistema
lo representa la fuga de información útil para un posible ataque sobre nuestro
sistema. En este punto, los mensajes de error enviados por el servidor, que
suelen ser de gran utilidad durante el proceso de desarrollo de la aplicación,
se vuelven contra nosotros cuando siguen apareciendo en una aplicación que se
encuentra en la etapa de producción, por lo que es necesario deshabitar todos
estos mensajes y editar algunos otros (como los que se envían cuando el
servidor no encuentra algún archivo en particular) que también pueden ser
utilizados por los atacantes para obtener información sobre nuestro sistema.
Practicas básicas de Seguridad Web
Balancear Riesgo y Usabilidad
Si bien la usabilidad y la seguridad en una aplicación web
no son necesariamente mutuamente excluyentes, algunas medidas tomadas para
incrementar la seguridad con frecuencia afectan la usabilidad. Al igual que
debemos pensar en las maneras en que usuarios ilegítimos nos pueden atacar,
también debemos considerar la facilidad de uso para los usuarios legítimos.
La recomendación inicial sería tratar de usar medidas de
seguridad que sean transparentes a los usuarios. Por ejemplo, la solicitud de
un nombre de usuario y una contraseña para registrarse en un sistema son
procedimientos esperados y lógicos por parte del usuario.
Rastrear el paso de los Datos
La medida más importante como desarrollador preocupado por
la seguridad que podemos tomar es mantener conocimiento de los pasos que ha
recorrido la información en todo momento. Conocer de donde vinieron los datos y
hacia donde van. En muchas ocasiones lograr esto puede ser complicado,
especialmente sin un conocimiento profundo de como funcionan los sistemas Web.
En las aplicaciones web, existen maneras de distinguir los
orígenes de los datos y poder así reconocer cuando los datos pueden ser dignos
de confianza y cuando no. Ante todo, debemos recordar que la desesperación y la
paranoia con mucha frecuencia nos dirigen a complicaciones y errores.
Particularmente para PHP existen arreglos
superglobales como $_GET, $_POST y $_COOKIE entre
otros que sirven para identificar de forma clara las entradas enviadas por le
usuario. Si esto lo combinamos con una convención estricta para el nombrado de
las variables podemos así tener un control sobre el origen de los datos usados
en el código.
Además de entender los orígenes de la información, tiene
también igual importancia entender cuales son las salidas que tiene ésta de la
aplicación.
Filtrar Entradas
El filtrado es una de las piedras angulares de la seguridad
en aplicaciones web. Es el proceso por el cual se prueba la validez de los
datos. Si nos aseguramos que los datos son filtrados apropiadamente al entrar,
podemos eliminar el riesgo de que datos contaminados y que reciben confianza
indebida sean usados para provocar funcionamientos no deseados en la
aplicación.
El proceso de filtrado debe estar conformado por los
siguientes pasos:
- Identificar
la entrada.
- Filtrado
de la entrada.
- Distinguir
entre datos que ya han pasado por el filtro y los que no.
Por lo general, se considera más seguro tratar a los datos
provenientes de bases de datos como entradas, aunque supuestamente sean bases
seguras y en las que debiéramos tener confianza, esto se debe a que es mejor
tener redundancia para evitar problemas en el caso de que la base de datos
fuera vulnerada.
Existen además muchos puntos de vista diferentes sobre como
realizar el filtrado o proceso de limpieza. Lo que usualmente se recomienda es
ver al filtrado como un proceso de inspección, no debemos tratar de corregir
los datos, es mejor forzar a los usuarios a jugar con las reglas válidas.
Otro aspecto a considerar en el proceso de filtrado es el
uso de listas blancas, listas negras o una combinación de ambas.
Al usar listas blancas asumimos que los datos son inválidos
a menos que prueben ser validos al encontrarse patrones coincidentes en la
lista blanca. Una limitante de usar este punto de vista es considerar inválidos
datos que debieron considerarse válidos pero que no fueron tomados en cuenta
patrones similares al construir la lista blanca. Dentro de todo, cometer un
error de este tipo es preferible que considerar válidos datos que no debieron
considerarse así.
Una vez concluido el paso del filtrado solo resta usar
convenciones apropiadas en el nombramiento de las variables para poder
distinguir las que ya han sido filtradas. Una recomendación sería guardar las
variables que ya hayan sido filtradas en un arreglo de fácil identificación
(como
$limpio).
Escapar salidas
Otra piedra angular de la seguridad en aplicaciones web es
el proceso de escapado y su contraparte para codificar o decodificar caracteres
especiales de tal forma que su significado original sea preservado.
El proceso de escapado debe estar compuesto a su vez por los
siguientes pasos:
Identificar las salidas. Escapar las salidas. Distinguir
entre datos escapados y noescapados.
Para escapar las salidas, primero debemos identificarlas.
En PHP una forma de identificar salidas hacia el cliente es
buscar por líneas como:
echo
print
printf
<?=
Además debemos considerar otro tipo de salidas como los
datos que son enviados a otros sistemas como bases de datos, etc. El proceso de
escapado debe adecuarse al tipo de salida de que se trate (si es al cliente, a
la base de datos, etc.). Para la mayoría de los destinatarios, existen
funciones nativas en PHP para esta finalidad.
La salida más común es el cliente, y para él existe en PHP
la función htmlentities() que probablemente es la mejor función para escapar
este tipo de salidas. Una recomendación adicional con respecto esta función es
especificar los parámetros opcionales apropiados con la codificación de
carácter empleada en la cabecera de la aplicación (Content-Type).
Para distinguir entre los datos que han sido escapados de
los que no es recomendable también usar una convención de nombres. Para el caso
de contenido escapado con la función htmlentities() se puede usar un arreglo en
especial al que podríamos llamar $html.
Otro destinatario común son las bases de datos, sin embargo
cada tipo de manejador (MySQL, PostgreSQL, etc.) puede presentar sus detalles,
por lo que es necesario una función de escapado apropiada para cada caso. Para
los usuarios de MySQL, la función recomendada es mysql_real_escape_string().
Clasificación de Ataques
Ataques URL de tipo Semántico
Este tipo de ataques involucran a un usuario modificando la
URL a modo de descubrir acciones a realizar originalmente no planeadas para él.
Los parámetros que son enviados directamente desde la URL son enviados con el
método GET y aunque los parámetros que son enviados con este método sólo son un
poco más fáciles de modificar que los enviados en forma oculta al usuario en el
navegador, esta exposición adicional de los parámetros tiene consecuencias,
como cuando queda registrada la URL con todo y estos parámetros quizás privados
en buscadores como Google.
Ataques al subir archivos
Existen algunos ataques que aprovechan la posibilidad de la
aplicación de subir archivos al servidor. Estos ataques funcionan de la
siguiente manera:
Generalmente PHP almacena los archivos subidos en un carpeta
temporal, sin embargo es común en las aplicaciones cambiar la localización del
archivo subido a una carpeta permanente y leerlo en la memoria. Al hacer este
tipo de procedimientos debemos revisar el parámetro que hará referencia al
nombre del archivo, ya que puede ser truqueado a modo de apuntar a archivos de
configuración del sistema (como
/etc/passwd en sistemas Unix).
Ataques de Cross-Site Scripting
XSS es un tipo de vulnerabilidad de seguridad informática
típicamente encontrada en aplicaciones web que permiten la inyección de código
por usuarios maliciosos en páginas web vistas por otros usuarios.
Los atacantes típicamente se valen de código HTML y de
scripts ejecutados en el cliente.
Una vulnerabilidad de este tipo puede ser usada por los
atacantes para burlar los controles de acceso comunes, como la muy conocida
Same Origin Policy. Recientemente este tipo de ataques han sido explotados para
crear poderosos ataques de phishing y de abusos en el navegador.
Desde la liberación del lenguaje JavaScript, se previeron
los riesgos de permitir a un servidor Web enviar código ejecutable al
navegador. Un problema se presenta cuando los usuarios tienen abiertos varias
ventanas de navegador, en algunos casos un script de una página podría acceder
datos en otra página u objeto, observando el peligro de que un sitio malicioso
intentara acceder datos sensibles de esta forma. Por ello se introdujo la
política same-origin. Esencialmente esta política permite la interacción entre
objetos y páginas, mientras estos objetos provengan del mismo dominio y en el
mismo protocolo. Evitando así que un sitio malicioso tenga acceso a datos
sensibles en otra ventana del navegador vía JavaScript.
A partir de entonces se han introducido otros mecanismos y
políticas de control en los navegadores y en los lenguajes en el lado del
cliente, para proteger a los usuarios de sitios maliciosos.
Las vulnerabilidades XSS pueden ser vistas como técnicas de
evasión de las políticas de protección. Encontrando formas ingeniosas de
inyectar códigos maliciosos en las páginas servidas por otros dominios, un
atacante puede ganar privilegios a datos sensibles, cookies de sesión y otros
objetos.
Tipos de vulnerabilidad XSS
Existen tres diferentes tipos de vulnerabilidades XSS:
Tipo 0
También conocido como basado en el DOM o Local. Con este
tipo de vulnerabilidad, el problema existe en el script del lado del cliente.
Si un código de JavaScript accede a una URL como un
parámetro de una petición al servidor y utiliza esta información para escribir
HTML en la misma página sin ser codificada empleando entidades HTML, existe un
agujero XSS, dado que estos datos escritos serán interpretados por los
navegadores como código HTML que puede incluir en si código adicional del lado
del cliente.
Los ataques de este tipo pueden devenir en la ejecución
remota de comandos. En el caso de que el atacante suba un sitio malicioso, que
contenga un link a una página vulnerable en el sistema de archivos del cliente,
resultando en la ejecución con privilegios del navegador del sistema. De esta
manera no sólo se pasan las restricciones de comunicación entre dominios.
Tipo 1
A este tipo de agujero XSS se le conoce también como no
persistente o reflejado, y es por mucho el más común. Estos agujeros aparecen
cuando los datos provistos por un cliente web son usados inmediatamente en el
lado del servidor para generar una página de resultados para el usuario. Si los
datos no validados por el usuario son incluidos en la página resultante sin
codificación HTML, se le permite al cliente inyectar código en la página
dinámica.
Un ejemplo clásico de este tipo es en los motores de
búsqueda, si alguno busca una cadena que incluya caracteres especiales HTML,
comúnmente la cadena de búsqueda será formateada para representar lo que se
buscó, o al menos incluirá los términos de la búsqueda en la caja de texto para
ser editados. Si las ocurrencias de los términos no son codificados como
entidades HTML existe un agujero XSS.
Esto no parecería un problema dado que los usuarios son los
únicos que pueden inyectar código en sus propias páginas. Pero con un pequeño
esfuerzo de ingeniería social, un atacante puede convencer a alguien de seguir
una URL que se encargue de inyectar el código en esta página de resultados,
dando al atacante acceso completo al contenido de la página.
La mejor forma de proteger una aplicación de ataques XSS es
asegurarse de que la aplicación valide todas las cabeceras, cookies, queries a
la base de datos, campos de las formas (entre estos los campos ocultos). Es
decir, todos los parámetros entrantes teniendo como referencia una
especificación rigurosa de lo que debe ser permitido.
De ninguna manera el proceso de validación debe intentar
identificar el contenido peligroso y removerlo, filtrarlo o sanearlo. Existen
muchos tipos de contenido activo o peligros y muchas maneras de codificarlo
para burlar los filtros para este tipo de contenido.
Se recomienda ampliamente utilizar un esquema positivo de
política de seguridad (listas blancas) que especifique de forma clara lo único
que es permitido.
Las políticas de lista negra son complicadas de mantener
actualizadas y siempre con posibilidades de quedar incompletas.
Codificar la salidas que dependan de los datos provistos por
el usuario es una manera eficaz de evitar vulnerabilidades XSS previniendo la
transmisión de scripts insertados a usuarios en una forma ejecutable.
Las aplicaciones pueden ganar protección de los ataques
basados en JavaScript convirtiendo los caracteres especiales en su equivalente
codificado en entidad HTML.
- <
< or <
- >
> or >
- &
& or &
- "
" or "
- '
' or '
- (
(
- )
)
- #
#
- %
%
- ;
;
- +
+
- -
No creamos que con la codificación de las salida con esta
lista negra es una protección suficiente. Es preferible utilizar un esquema de
lista blanca como la función HTMLEntityEncode de Java.
Además es crucial deshabilitar el soporte de HTTP TRACE en
los servidores web (Apache, IIS, etc.) al hacerlo evitaremos que el servidor
devuelva los parámetros de la solicitud errónea recibida.
Cross-Site Request Forgeries
Este tipo de ataque permite al atacante enviar peticiones
HTTP a voluntad desde la máquina de la víctima. Por la naturaleza de este tipo
de ataques, es difícil determinar cuando una petición HTML se ha originado por
un ataque de este tipo.
Cuando un atacante conoce el formato que debe tener una URL
para lograr la ejecución de una acción en el sistema, ha logrado encontrar la
posibilidad de explotar este tipo de ataques. Ahora lo que necesita el atacante
es simplemente hacer que una víctima visite la URL.
Un recurso que se utiliza comúnmente para realizar este tipo
de ataques en tener embebida la petición en una imagen.
El atacante sólo necesita crear alguna etiqueta HTML del
siguiente tipo:
<img
src="http://ejemplo.org/compra.php?param=valor¶m2=valor"
/>
Existen acciones que podemos tomar para contrarrestar este
tipo de ataques, una de estas es preferir el método POST para el procesamiento
de formas en lugar del GET, otra posibilidad es solicitar confirmación por
parte del solicitante antes de realizar los procesos (a costa de reducir la
usabilidad en la aplicación).
Otra posibilidad es considerar sospechosa una petición que
no ha sido el resultado de una demanda previa de la forma necesaria para enviar
esa petición.
Envío de Formas falsificadas
Falsificar una forma es casi tan fácil como manipular una
URL. En el fondo, el envío de una forma emplea el mismo mecanismo, la petición
HTTP enviada por el navegador al servidor. El formato con el que va a contar la
petición se encuentra predeterminado por la forma y algunos de los datos
enviados en la petición son dados por el usuario.
Un atacante podría copiar el código fuente de una página,
salvarla en su equipo, y modificar el atributo de la acción que realizará la
forma incluyendo ahora la ruta absoluta de la página originalmente deseada.
Ahora el atacante puede quitar restricciones originales que se hubieran
ejecutado en el cliente, como el tamaño máximo de un archivo adjunto,
desactivar la validación de datos en el lado del cliente, alterar los elementos
ocultos o los tipos de datos de los elementos de la forma. Operando de esta
forma podemos enviar datos arbitrarios al servidor, de una manera sencilla y
sin el uso de herramientas sofisticadas.
Este tipo de falsificaciones es algo que no podemos
prevenir, pero es algo que debemos tomar en cuenta. Mientras tengamos el poder
de filtrar las entradas, los usuarios deben jugar con nuestras reglas.
Peticiones HTTP Falsificadas
Un ataque más sofisticado que el anterior es enviar
peticiones falsas empleando herramientas especiales para este propósito. La
existencia de este tipo de ataques es una prueba determinante de que los datos
enviados por los usuarios no son dignos de ninguna confianza.
¿Como puede un atacante enviar una petición HTTP falsa de
forma arbitraria? El proceso es simple. Empleando una herramienta de línea de
comandos presente en la mayoría de las plataformas se posibilita la
comunicación directa con un servidor remoto, conectándonos en el puerto en el
cual el servidor escucha (para servicios web típicamente es el puerto 80).
Los dos últimos tipos de ataques mencionados son una muestra
de que el usuario no esta obligado a enviar la información siguiendo las reglas
que han sido definidas en la aplicación. En realidad un atacante puede
confeccionar a gusto sus peticiones HTTP, la fortaleza de nuestro sistema será
medible por su capacidad de detectar que peticiones recibidas deben ser
escuchadas y procesadas de acuerdo a los parámetros y valores de éstos que es
esperable recibir.
Seguridad de las Aplicaciones y su relación con las Bases
de Datos
La mayoría de las aplicaciones web son usadas como un
conducto entre muchas fuentes de datos y el usuario, esto es, las aplicaciones
web son usadas frecuentemente para interactuar con una base de datos.
Aunque el tema de la seguridad en las bases de datos merece
un tratamiento diferente al de las aplicaciones web, se encuentran íntimamente
relacionados.
Como hemos mencionado en secciones anteriores, toda entrada
al sistema debe ser filtrada, y toda salida escapada. Lo mismo aplica cuando
las entradas o salidas son de o hacia una base de datos.
Muchos programadores no dan importancia al filtrado de datos
provenientes de una consulta a la base de datos, debido a que consideran a esta
fuente como confiable. Aunque el riesgo a primera vista parecería menor, es una
práctica recomendable no confiar en la seguridad de la base de datos e
implementar la seguridad a fondo y con redundancia. Si algún dato malicioso
pudiera haber sido inyectado a la base de datos, nuestra lógica de filtrado
puede percatarse de ello, pero sólo si se ha implementado este mecanismo.
Exposición de Credenciales de Acceso
Uno de los asuntos principales a ser cuidados cuando se
utiliza una base de datos es el almacenamiento de las credenciales de acceso a
ella.
Por conveniencia, estos datos son almacenados en un archivo
como db.inc.
<?php
$db_user = 'myuser'; $db_pass = 'mypass'; $db_host =
'127.0.0.1';
$db = mysql_connect($db_host, $db_user, $db_pass); ?>
Los datos de usuario y password son sensibles, por lo que
deben tener garantizada una atención especial. Su presencia en el código fuente
es un riesgo inevitable.
Si miramos en el archivo por default http.confg de Apache,
encontramos que el tipo default es text/plain. Esto significa un riesgo si el
archivo db.inc se localiza en la raíz del directorio. Todo recurso localizado
en la raíz tiene una dirección URL y como Apache no tiene un tipo de contenido
asociado a los archivos .inc la respuesta del servidor será devolver el
contenido en texto plano del archivo, en donde se podrían observar las credenciales
del servidor.
La mejor solución a este problema es almacenar los archivos
a incluir en otro lugar fuera del directorio raíz. No es necesario tenerlos en
algún lugar en particular en el sistema de archivos para ser capaces de
incluirlos o requerirlos, solo es necesario garantizar que el servidor tenga
privilegios de lectura.
De hecho únicamente debemos localizar en la raíz los
recursos que deseemos sean accesibles, es un directorio público.
Si por alguna razón no fuera posible localizar al archivo fuera
del directorio raíz, es necesario configurar Apache para rechazar las
peticiones de recursos con extensión .inc:
<Files
~ "\.inc$"> Order allow,deny Deny from all </Files>
SQL Injection
La inyección de código SQL es una de las vulnerabilidades
más comunes en aplicaciones PHP. Una vulnerabilidad de SQL Injection requiere
dos fallas por parte del programador:
- Fallas
en el filtrado de los datos.
- Fallas
en el escapado de los datos al enviarlos a la base de datos (escapado de
salida).
Ninguno de estos pasos cruciales debe ser omitido, y los dos
pasos requieren especial atención para poder minimizar los errores.
Afortunadamente los ataques de SQL Injection son fácilmente evitables, mientras
filtremos y escapemos las salidas. Filtrar las entradas depende enteramente en
el tipo de los datos a filtrar, el escapado por su parte requiere una sola
función. Existen funciones predefinidas para cada tipo de base de datos, pero
de no encontrar ninguna, la función addslashes() puede ser un buen último
recurso.
Exposición de datos
Una de las preocupaciones más comunes relacionadas con las
bases de datos es la exposición de datos sensibles. Al almacenar números de
tarjetas de crédito, o algo tan delicado, es preferible asegurarse que los
datos almacenados en la base de datos se encuentran seguros e inaccesibles
incluso para los administradores de la base.
Una buena recomendación es encriptar los datos más
sensibles, de esta manera si la base de datos llega a ser comprometida el
desastre será menor. Un ejemplo de esta técnica es almacenar las contraseñas de
usuario convertidas con md5. De esta manera, los cadenas de las claves
almacenadas en la base de datos como md5 no son útiles al atacante para conocer
contraseñas que le permitirían el acceso al sistema ya que no es posible
conocer la cadena de texto original.
- Páginas
Privadas y los Sistemas de Autenticación
La autenticación es el proceso por el cual la identidad de
un usuario en el sistema es validada. Comúnmente el procedimiento involucra un
nombre de usuario y una contraseña a revisar. Una vez autenticado el usuario es
registrado (logeado) como un usuario que se ha autenticado. Muchas aplicaciones
tienen recursos que son accesibles sólo para los usuarios autenticados,
recursos que son accesibles únicamente para los administradores y recursos
totalmente públicos.
El control de acceso debe encontrarse totalmente integrado
al diseño original. No debe ser algo improvisado sobre una aplicación ya
existente.
Ataques de Fuerza Bruta
Un ataque de este tipo agota todas las posibilidades sin
preocuparse por cuales opciones son las que tienen mayor probabilidad de
funcionar.
En los términos del control de acceso, generalmente
encontramos al atacante intentando registrarse mediante un gran número de
pruebas. En algunos casos el atacante puede conocer nombres de usuario válidos
y la contraseña es la única parte que se trata de adivinar.
Limitar el número de intentos que se le permite al usuario
tratar de adivinar es una medida efectiva en contra de estos ataques, pero
tiene por desventaja de poder afectar el uso del sistema a usuarios legítimos.
Una propuesta un poco más considerada con el usuario seria intentar encontrar
patrones en las peticiones enviadas por el atacante y únicamente bloquear el
uso de la cuenta para peticiones que cumplan con dicho patrón, de esta forma se
interfiere menos el uso al usuario legítimo.
Otra opción sería imponer un intervalo de tiempo pequeño
(ejemplo 15 segundos) que se debe esperar para poder intentar registrarse en el
sistema de nuevo después de una falta en la autenticación. De esta manera, se
niega el acceso sin importar si se presentaron las credenciales fue correcta,
por supuesto que no se le dice al atacante la razón por la que se le negó el
acceso para evitar lo intente de nuevo cuando haya terminado el plazo de
espera. Trabajando de esta forma, se busca reducir el tiempo útil que tiene el
atacante para intentar adivinar las credenciales de acceso.
Espionaje de Contraseñas (Password Sniffing)
Cuando un atacante tiene los medios para analizar el t?afico
entre los usuarios y el servidor de la aplicación, debemos preocuparnos por la
exposición que pueden tener los datos en el trayecto, sobretodo cuando se trata
de credenciales de acceso.
Una manera efectiva de prevenir este tipo de problemas es
usar SSL para proteger los contenidos enviados en las peticiones y respuestas
en HTTP. Debemos considerar utilizar esta tecnología tanto para cuando se
envíen las credenciales de acceso como los identificadores de una sesión ya
establecida, de esta forma evitamos un secuestro de la sesión.
Usar SSL para proteger el envío de HTML es además una medida
útil para brindar confianza a los usuarios de enviar sus datos cuando ven en su
navegador el uso de https.
Registros persistentes
Cuando un usuario permanece en el estado de registrado
después de un tiempo no razonable (cuando la sesión expiró por ejemplo),
tenemos un problema de registros persistentes.
Este tipo de problemas disminuyen la seguridad de nuestro
mecanismo de autenticación. Generalmente estos problemas son causados por una
cookie persistente, o un ticket enviado al usuario para hacer referencia a la
sesión de registro establecida que no se considera como expirado jamás o que no
cambia en cada nuevo registro establecido por el usuario.
Si el ticket de acceso permanece constante para cualquier
sesión establecida tenemos un problema serio, la manera más sencilla de
evitarlo es haciéndolo dependiente de una variable aleatoria.
Otra medida recomendable es requerir la contraseña del
usuario cuando vaya a realizar alguna tarea administrativa importante en el
sistema. Con este esquema se permite el acceso únicamente a los recursos que no
son tan sensibles.
Otro paso indispensable es efectivamente eliminar la cookie
de acceso cuando un usuario solicita salir del sistema.
Conclusiones
La seguridad en aplicaciones Web involucra principalmente al
desarrollador, aunque con gran frecuencia se encuentran defectos que pueden ser
aprovechados por atacantes en las tecnologías en que se basan los sistemas web, la atención principal
debe dirigirse a los defectos propios al desarrollo nuestras aplicaciones.
La
variedad de problemas es grande, pero las medidas para evitar la mayoría de
estos problemas son las mismas (filtrar y escapar), con las debidas
precauciones y considerando los efectos que entradas contaminadas pueden
provocar en el funcionamiento de la aplicación para cada caso podemos disminuir
la probabilidad de sufrir ataques. Otro tipo de problemas, como los procesos de
autenticación tienen consideraciones propias que debemos implementar para hacer
más robusta y confiable nuestra aplicación.
ELABORADO POR: YURIZBETH PRÓSPERO BARRAZA
SAJAX (que significa “Simple Ajax Toolkit”) es un desarrollador de código abierto para acelerar la creación de aplicaciones Ajax. Soporta los principales tecnologías como ASP, Cold Fusion, PHP, Perl, Python y Ruby.
