Criptonomicón

Suscripción gratis

Susurros

Ariadn@

¿Intimidad?

Artículos

Seguridad

Acceso a BD

Autenticación

Comercio-e

Linux

Navegación segura

Control de acceso

CGI

Java

JavaScript

Cookies

Crashes

Agujeros

Spam

Remailers

Anonimato

Correo seguro

Web seguro

Consejos prácticos

Referencias

Libro de Visitas

Control de acceso

Limitaciones de estos métodos

Nombres 

Localización 

JavaScript 

Java 

ASP 

CGI 

Limitaciones 

Listado de directorios

Si en la ventana de URL se introduce el nombre de un directorio, puede ocurrir que aparezcan listados los contenidos de ese directorio, con sus carpetas y ficheros. En estas circunstancias, estos esquemas de protección resultarían inútiles, ya que se podría ver el nombre de los ficheros (o lo que es lo mismo, las claves).

Solución
En la configuración del servidor está disponible la posibilidad de deshabilitar el listado de directorios, así como la presentación por defecto de un fichero cuando se solicite el nombre del directorio. Este fichero suele llamarse index.html o default.htm y si no está presente, aparecerá una página de error en vez de listarse el contenido del fichero.

Bookmarking

Una vez que un usuario ha accedido a la página protegida, es decir, una vez que conoce su URL, nada impide que lo guarde en su lista de marcadores y acceda a él en el futuro sin pasar antes por el proceso de autenticación. Es más, podría desde una página Web poner un enlace a la página o fichero protegido en cuestión, de manera que cualquier usuario podría acceder a él sin autenticarse antes.

Solución
Cambiar frecuentemente la clave/nombre del fichero a proteger, de manera que no se pueda acceder directamente a la página sin pasar antes por el proceso de autenticación (al menos no por mucho tiempo).

En ASP no existe este problema, siempre que el proceso de autenticación se embeba en la misma página que se desea proteger.

Utilizando CGI como se ha descrito, tampoco existe tal problema.

Listado del código fuente

No hay que perder de vista el hecho de que en Java el proceso de compilación no oculta completamente el código fuente del programa, ya que el fichero objeto contiene mucha información, hasta el punto de que puede decompilarse sin problemas usando alguno de los muchos decompiladores que existen. Por lo tanto, no hay que olvidar que el usuario firmemente determinado será capaz de obtener el código fuente más tarde o más temprano, por lo que no conviene dejar en él material sensible ni claves en claro. Hay quien cifra las claves, pero dado que la propia clave de cifrado debe estar embebida en el código para que éste funcione, no se trata tampoco de una solución robusta.

En ASP, se descubrió en julio de 1998 un importante agujero de seguridad: basta con añadir "::$DATA" a continuación de una dirección URL en la ventanita "Dirección" de nuestro navegador, para que en vez de ejecutarse en el servidor la página de servidor activa (ASP), se descargue en un fichero su código fuente, en lugar de descargarse el resultado de su ejecución. Según qué información protegiera la página ASP, este fallo permitiría acceder a la misma si trataba de información estática (texto o imágenes), resultando inútil para información activa (acceso a una base de datos).

Solución
En Java, se pueden utilizar ofuscadores de código, que dificultan la labor de decompilación.

En ASP, se debe instalar el parche de Microsoft para evitar este fallo o impedir la lectura de ficheros ASP, habilitando sólo su ejecución.

Cookies

El problema más importante que plantean las cookies es que la información de nombre y clave quedan guardados en el disco duro, de manera que cualquier persona que disponga de acceso físico al mismo será capaz de leerla y por consiguiente entrar a ese servicio.

Por otro lado, no todos los navegadores soportan cookies, o bien su aceptación está desactivada en muchos de ellos.

Solución
Respecto al acceso físico a la cookie, la única solución consiste en que el usuario proteja convenientemente sus archivos sensibles cuando no los esté utilizando.

En cuanto a los usuarios que desactivan la navegación con cookies, se les debe avisar del propósito de estas cookies para que no desconfíen de ellas y las habiliten mientras navegan por nuestras páginas. Los monstruos de galletas son otra solución aceptable.

En cualquier caso, el uso de cookies es más una conveniencia que una necesidad, por lo que si un usuario no puede o no quiere aceptar cookies, los métodos que las utilizan no dejarían de funcionar, sino que se verían obligados a autenticarse para cada documento protegido que quisieran visualizar.

Se puede obtener más información sobre las cookies en el curso sobre cookies.

Autocompletar contraseñas

Internet Explorer 5.0 incorpora la posibilidad de recordar los campos que se rellenan en un formulario, incluidas las contraseñas. Esta característica, que puede resultar muy cómoda para una persona que es la única usuaria de un ordenador, abre un importante problema de seguridad cuando son varios los usuarios que navegan desde la misma cuenta en el ordenador.

Cuando un usuario visita una página en la que se le pide login y password, tras haberlos introducido, le aparecerá una ventana en la que se le pregunta si desea que Windows recuerde la contraseña para no tener que escribirla la próxima vez que visite esa página. En caso afirmativo, quedará almacenada de forma codificada en el registro de configuraciones de Windows, de manera, que en el futuro, cada vez que se acceda a la misma página, se rellenerá la contraseña automáticamente. Para usuarios que se conectan a multitud de servicios de Internet, esta funcionalidad adicional puede simplificarles terriblemente la vida, en la medida en que no necesitan recordar docenas de contraseñas distintas. Sin embargo, si otro usuario navegando desde su misma cuenta accediera a esa página, automáticamente recibiría permiso para acceder a ella.

Solución

Qué puede hacer el usuario

En primer lugar, en la ventana que se le presenta debe contestar que no lo desea y activar la casilla "No volver a ofrecer recordar contraseñas".

Si esta funcionalidad ya está activada, puede borrar todas las contraseñas y desactivar la característica en Herramientas --> Opciones de Internet... --> Contenido --> Autocompletar... .

Qué puede hacer el administrador

Como un creador de páginas web no puede prever lo que harán los potenciales visitantes, más vale asegurarse de que no ocurrirán sorpresas. Puede desactivar la posibilidad de Autocompletar añadiendo el atributo AUTOCOMPLETE="OFF" a la etiqueta <FORM>:

<FORM METHOD="POST" ACTION="ENVIAR.ASP" AUTOCOMPLETE="OFF">

En el caso de que sólo se quiera desactivar el autocompletado en algunos campos más comprometidos del formulario y no en todos, puede utilizarse ese mismo atributo en las etiquetas de los campos, por ejemplo:

<INPUT TYPE="PASSWORD" NAME="CLAVE" SIZE="15" MAXLENGTH="15" AUTOCOMPLETE="OFF">

que desactivará autocompletar solamente en ese campo en concreto.

¡Advertencia final!

Ninguno de estos métodos debe ser considerado como una solución a prueba de intrusos. En ningún caso es posible aproximarse a los niveles de seguridad proporcionados por el servidor, usando autenticación básica, desafío y respuesta, certificados, u otras técnicas. Estos métodos están diseñados para proteger recursos que no requieran alta seguridad. No se recomienda su uso para la protección de información altamente secreta.

 

Copyright © 1997-2000 Gonzalo Álvarez Marañón, CSIC. Todos los derechos reservados.

Criptonomicón es un servicio ofrecido libremente desde el Instituto de Física Aplicada del CSIC. Para información sobre privacidad, por favor consulte la declaración de política sobre privacidad. Para sugerencias, comentarios o quejas, acuda al libro de visitas. Para contribuir al Criptonomicón, lea la página de contribuciones.