Cómo restringir el acceso a páginas web

Cómo restringir el acceso a páginas web

Algunos usuarios, después de crear sus páginas web, no saben cómo hacer para restringir el acceso a alguna de ellas. A menudo desearían proteger documentos de su web, de manera que sólo sean accesibles para personas autorizadas, bien porque hayan pagado para ello o bien porque hayan seguido un proceso de registro, pero carecen de permisos en el servidor o conocimientos para hacerlo. En este artículo se da respuesta a esta necesidad, presentándose diversas tecnologías Web para proteger páginas de forma sencilla.

1. Introducción
Por medio del control de acceso se limita quién puede acceder a qué datos dentro de un servidor. La primera etapa de un control de acceso correcto consiste en identificar a la persona que desea acceder a un recurso determinado. Esta identificación se conoce como autenticación. Existen muchas técnicas para asegurarse de la identidad de un usuario: su dirección IP o nombre de máquina desde la que se conecta, un nombre y contraseña, un certificado digital personal, una llave hardware, etc. Por desgracia, son muchos los creadores de páginas web que no disponen de privilegios en el servidor para utilizar estas técnicas sofisticadas de autenticación, por lo que deben buscar caminos alternativos que, sin ser tan seguros, les permitan al menos proteger mínimamente su trabajo. En este artículo se explican desde un punto de vista práctico varias formas de restringir el acceso a ciertas páginas por medio de Java, CGI, ASP y JavaScript, todas ellas al alcance de cualquier creador de páginas web, útiles en diversas plataformas, Unix o NT, utilizando en todos los casos herramientas gratuitas y de fácil obtención.

2. La clave está en el nombre
Cuando no se puede acceder a la configuración del servidor para implantar técnicas de control de acceso robusto, no queda más remedio que basarse en el secreto del nombre del fichero o ficheros que se desea proteger. Por nombre se entiende el camino o URL completo que localiza al fichero en el servidor Web: máquina, directorio y nombre del documento. Por lo tanto, bastará con mantener en secreto cualquier elemento de ese camino completo para asegurar una protección relativa del fichero. Así pues, la parte del nombre que permanezca secreta constituirá la clave de acceso.

La parte del nombre que permanezca secreta constituirá la clave de acceso
Por supuesto, este tipo de protección basada en el cliente, no en el servidor, no puede considerarse como un método verdaderamente seguro y nunca se deberá utilizar para proteger documentos críticos de una organización o compañía. No obstante, para proteger de la mirada de fisgones casuales ciertas áreas o ficheros en páginas personales o en un pequeño sitio web, estos métodos ofrecen unos resultados excelentes.
La forma más inmediata de restringir el acceso a un fichero de un web consiste en dejarlo en algún directorio, sin enlazarlo desde ninguna otra página de ese web ni de ningún otro.
Supóngase que el documento cuyo acceso se desea restringir se llama secretitos.doc y se encuentra albergado en la máquina www.confidencial.es. Si no se dispone de ningún enlace al mismo desde ninguna otra página, basta con almacenarlo simplemente en el directorio raíz, de manera que su URL sea: www.confidencial.es/secretitos.doc. para que sólo la persona que conozca a priori su nombre y localización pueda recuperarlo. Para ello, claro está, es condición indispensable impedir el listado de directorios, como se describe en la sección 7.1. Por consiguiente, bastaría con proporcionar el nombre y camino del fichero a los usuarios a los que se quiere garantizar el acceso para que sólo ellos fueran capaces de recuperarlo. Obviamente, el fichero protegido se puede depositar en cualquier otro subdirectorio.
Con el fin de proporcionar una interfaz más profesional y flexible, será necesario escribir una pequeña aplicación en algún lenguaje como Java o JavaScript o bien en CGI o ASP, por citar algunas posibles tecnologías. Los requisitos que se impondrán a esta aplicación son que presente una ventana en la que se solicite un nombre de usuario y una contraseña, o por lo menos una contraseña, para acceder a los contenidos restringidos. También se le puede exigir opcionalmente que se almacenen esos datos, de manera que el usuario no tenga que introducirlos cada vez que consulta el documento protegido.
En las secciones siguientes, se verá cómo estos requisitos toman cuerpo, utilizando para ello diversas tecnologías Web actuales.

3. Control de acceso en JavaScript
JavaScript es un lenguaje de programación desarrollado por Netscape Corporation para permitir la ejecución de código dentro de las páginas en HTML. Microsoft posee su propia versión, llamada Jscript. Gracias a los programas (llamados guiones) escritos en este lenguaje, se pueden conseguir interesantes efectos en las páginas web, comprobar la entrada de formularios, abrir y cerrar ventanas, cambiar dinámicamente el aspecto y los contenidos de una página, y mucho más.
Basándose en la técnica de utilizar como clave de acceso el propio nombre del fichero (o parte del mismo), existen muchas formas de proteger el acceso a las páginas, que se traducirán en diferentes formas de esconder la clave dentro del código en JavaScript. Aquí aparece la primera limitación inherente a los métodos que utilizan este lenguaje, y es que el código original en JavaScript se puede examinar sin más que editar el código fuente de la página web en la cual está embebido. Por este motivo, no puede declararse la palabra clave dentro del propio código, ya que quedaría visible para todo aquel que se molestase en examinar el código fuente.
El método más sofisticado y seguro en JavaScript consiste en presentar una ventana de petición de clave, clave que se corresponderá con el nombre del fichero. En general, existirán por lo menos dos documentos:

• La página de entrada, en la que aparece el enlace a la página protegida.
• La página destino que se quiere proteger y cuyo nombre constituye la clave.

El código fuente en HTML de la página de entrada será algo como:

<SCRIPT language=“JavaScript”>

</SCRIPT>

Por su parte, el enlace a la página pro- tegida pasará a tener el siguiente aspecto:

Aquí encontrarás los <A HREF=“java-script: protector()”>documentos secretos</A>.

Ahora bien, si se desea proteger muchas páginas, este esquema resulta inadecuado, ya que el usuario se sentiría agobiado por la gran cantidad de contraseñas que debería recordar (tantas como páginas protegidas). Para muchas páginas protegidas, se vuelve más cómodo y eficiente proteger todos los archivos de un directorio con una única clave, que consistirá en el nombre del directorio donde se alojan. Ahora, el nombre del fichero es conocido, pero no su localización. Así, el nuevo código en JavaScript quedaría como:

var url = clave + “/nombrefichero.html”;

De esta forma, para cambiar la clave de acceso a varios ficheros simultáneamente no será necesario cambiarles el nombre a todos (no hay que olvidar que la clave de acceso es el propio nombre del fichero), sino que bastará con moverlos a todos a otro directorio distinto, cuyo nombre pasará a ser la nueva clave. Es fácil observar que este esquema gana en eficacia si la clave se ve comprometida, por ejemplo, porque alguien haya enlazado directamente alguna de las páginas protegidas (v. sección 7.2).
La ventaja de este método reside en que se puede utilizar en cualquier tipo de plataforma, Unix o NT, sin necesidad de poseer privilegios especiales en el servidor. Por supuesto, funcionará correctamente en cualquier navegador que soporte JavaScript y que no haya deshabi- litado su ejecución. No es necesario ningún fichero adicional a la página HTML, ya que el código va embebido en la propia página, por lo que su simplicidad es máxima. Además, cualquier editor de texto sirve para escribir el programa y se visualiza en el propio navegador, por lo que no se requiere software de desarrollo adicional. Se pueden encontrar el código completo y páginas de demostración de los ejemplos de control de acceso en JavaScript en www.iec.csic.es/criptonomicon/acceso/javascript.html.

4. Control de acceso en Java
Java es otro lenguaje completo de programación, desarrollado por Sun Mi-crosystems. Lo que hace tan popular a Java es su capacidad de ejecutarse en cualquier tipo de plataforma una vez compilado en bytecodes, lo que lo hace especialmente indicado para su despliegue en Internet, donde coexisten todo tipo de sistemas operativos y máquinas. Las applets son pequeños programas escritos en Java que aparecen embebidos en las páginas web, como aparecen los gráficos o el texto, pero con la capacidad de ejecutar acciones muy complejas, como animar imágenes, establecer conexiones de red, presentar menús y cuadros de diálogo para luego emprender acciones, etc.
En Java se puede elaborar un método de protección similar a lo explicado para JavaScript, aunque mucho más sofisticado. Igualmente, se solicita la palabra clave, que se corresponderá con el nombre del fichero que se desea proteger, pero en esta ocasión a través de una applet de Ja- va actuando como filtro. El código de la applet comprobará en primer lugar si existe esa página web (correspondiente a la clave introducida por el usuario), para pasar después, en caso afirmativo, a abrirla en la misma ventana desde la que se lanzó la applet, en una nueva ventana o en un marco o frame.
En el siguiente cuadro se muestra un fragmento de código en Java que permite controlar el acceso a una página. Básicamente, se repiten los pasos descritos para JavaScript:

1. Leer la palabra clave introducida por el usuario.
2. Intentar abrir la página correspondiente al URL construido a partir de la clave.
3. Si el URL no se corresponde con una página existente, se devolverá un mensaje de error; en caso contrario, se transportará al usuario a la página protegida.

void surfto()
{
if (t_password.getText().length()>0) {
try {
URL surftoURL = new URL ( root + t_password.getText( ) + ".html" );
t_password.setText("");
if ( !check_if_URL(surftoURL.toString())) {
surfto_error();
}
else {
getAppletContext().showDocument( surftoURL, "_self" );
}
}
catch (MalformedURLException e) { surfto_error();
}
catch (SecurityException e)

surfto_error();
}
catch (IOException e)

surfto_error();
}
}
}

El código completo con las funciones empleadas y la página de demostración se pueden obtener en www.iec.csic.es/criptonomicon/acceso/java.html.
No hay que olvidar, como se discute en la sección 7.3, que no conviene incluir la clave dentro del código, ya que es muy fácil obtenerlo a partir de los ficheros compilados de clase, aunque a simple vista no lo parezca.
La riqueza del lenguaje Java permite crear interfaces de usuario muy sofisticados.
Además, mediante una applet de Java se pueden gestionar otras características del control de acceso, como registro de intentos de acceso fallidos, bases de datos con nombres y claves de acceso para proteger distintas páginas de forma flexible, etc.
Este tipo de protección resulta adecuado para aquellos que no dispongan más que de la posibilidad de incluir páginas en HTML y ficheros del tipo .class (utilizados para almacenar el código objeto de applets de Java), algo generalmente consentido por todos los administradores Web.
La ventaja de este método es que se puede utilizar en cualquier tipo de plataforma, Unix o NT, sin necesidad de poseer privilegios especiales en el servidor. Por supuesto, funcionarán correctamente en cualquier navegador que soporte Java y que no haya deshabilitado su ejecución.
Las herramientas para programar en Java, depurar código y visualizarlo se pueden obtener gratuitamente del sitio Web de sus creadores en java.sun.com.

5. Control de acceso en ASP
Las Páginas Activas de Servidor (Active Server Pages) o ASP para abreviar, representan el paradigma de la filosofía de Microsoft en su estrategia para Internet. A diferencia de otros productos de Microsoft, como los controles ActiveX o los guiones en VisualBasic (VBScript), las aplicaciones ASP se procesan y ejecutan en el servidor y no en el cliente, siendo en este sentido parecidas a las aplicaciones CGI, pero integrando otros servicios y aplicaciones Microsoft, todo ello utilizando el lenguaje Visual Basic como aglutinante.
El control de acceso mediante ASP (Active Server Pages) resulta especialmente útil cuando se desea acceder a servicios como consultas a bases de datos, búsquedas en catálogos o directorios de empresas u otro tipo de páginas generadas al vuelo, es decir, páginas para las que no existe a priori un URL asignado, ya que su contenido dependerá de la solicitud del usuario.
En el siguiente listado se muestra un ejemplo escrito en VBScript (dialecto de Visual Basic, conceptualmente similar a JavaScript):

'Comprobar si el usuario es válido
usuario=Session(“usuario”)
Rechazado=False
'Si usuario está vacío es que todavía el usuario no ha intentado acceder (o lo intentó sin éxito)
If IsEmpty(usuario) Or IsNull(usuario) Or usuario=”” Then
Intentado=False
'En ese caso, se le presenta la pantalla de autenticación
URL=Request.ServerVariables(“QUERY_STRING”)
If IsEmpty(URL) Or URL=”” Then
URL=”” ’por si acaso
Else
URL=”?” & URL
End If
URL=Request.ServerVariables(“SCRIPT_NAME”) & URL
’buscar la información de autenticación enviada a través del formulario
’se usa el método POST para no dejar rastro en el cache ni en los proxies
nombre=Request.Form(“nombre”)
clave=Request.Form(“clave”)
usuario=nombre&clave
If IsEmpty(usuario) Or IsNull(usuario) Or usuario=”” Then
Rechazado=True
Else
’Comprueba los datos del usuario
If nombre = “gon” And clave = “alv” Then
’Almacena la combinación usuario en una variable de Session
’Esto permite que en el futuro no necesite autenticarse de nuevo
Session(“usuario”)=usuario
Rechazado=False
Else
Intentado=True
Rechazado=True
End If
End If
End If

If Rechazado Then
If Intentado Then
Titulo=“La identificación ha fallado”
Else
Titulo=“Identifíquese, por favor”
End If

%>

</font><%
Response.End 'Terminar el procesamiento antes de pasar a la página protegida
End If

'...si no ha fallado la autenticación, aquí viene la página protegida
%>

Este texto (o acceso a base de datos o lo que sea) sólo se verá si el usuario se ha autenticado con éxito.
Como se deduce del examen del código, la página anterior se genera al vuelo. Primero se comprueba si el usuario ya se ha autenticado (información del objeto Session). En caso afirmativo, se pasa directamente a presentar el contenido a proteger: desde una página web convencional, con texto, gráficos, etc., o mejor aún, algún tipo de servicio, como consulta a base de datos. En caso negativo, se le presenta un página para que se autentique, a la que se le pasa información dinámicamente. Cuando el usuario rellene el formulario con sus datos y pulse el botón de enviar, se repetirá este proceso. A continuación se muestra el fichero en HTML que debe incluirse en el código anterior, con el fin de presentar la página de autenticación, en la que se solicita el nombre de usuario y la clave de acceso:

<h1><%=Titulo%></h1>
<p>Va a acceder a un servicio restringido para el que es necesario que se identifique</p>
<form action=“<%=URL%>” method=“POST”>
<table border=“0” width=“100%”>
<tr>
<td width=“15%”>Nombre de
usuario:</td>
<td width=“50%”><input type=“text” name = “nombre” size=“12”></td>
</tr>
<tr>
<td width=“15%”>Clave de acceso:</td>
<td width=“50%”><input type=“password” name=“clave” size=“12”></td>
</tr>
</table>
<p><input type=“submit” value=

“Entrar”> </p>
</form>
Listado 4. Página de autenticación en HTML (login.htm).

El código VBScript (lo que se encuentra entre los signos <% y %>) no quedará al descubierto si se intenta ver el código fuente de la página, ya que a diferencia de lo que ocurre con Java o JavaScript, en ASP el código se ejecuta en el propio servidor y no en el cliente (ver sección 7.3). En cualquier caso, incluso acceder directamente a la página login.htm resulta inútil, ya que no ofrece ninguna pista acerca de qué hay dentro de la página ASP a la que da acceso.
Para mayor comodidad, en vez de almacenar la información del usuario en una variable de sesión, que desapare- ce entre sesiones consecutivas al cerrar el navegador, se podría guardar en una cookie, de manera que estuviera accesible la próxima vez que se visitase esa página, sin necesidad de pasar de nuevo por todo el proceso de autenticación. No obstante, este enfoque presenta algunos inconvenientes, como se describe en la sec. 7.4.
Este esquema presenta importantes ventajas frente a los dos métodos anteriores. En primer lugar, la página protegi- da no puede enlazarse desde otras páginas ni accederse directamente soslayando el proceso de autenticación (v. sec. 7.2). Por otra parte, permite proteger no ya páginas, sino servicios, como una consulta a una base de datos o búsquedas en un sitio Web.
Las páginas ASP se pueden escribir con cualquier editor de texto convencional, aunque como contrapartida, es necesario que el administrador permita alojar en el servidor páginas ASP, a lo cual muchos administradores pondrán pegas. Por otro lado, esta tecnología sólo funciona en servidores Internet Information Server de Microsoft y normalmente requerirá la instalación de las extensiones de FrontPage.
Se pueden ver ejemplos completos de aplicaciones en ASP, con y sin cookies, en www.iec.csic.es/criptonomicon/acceso/asp.html.

6. Control de acceso en CGI
La interfaz de pasarela común (Common Gateway Interface, CGI) es un protocolo genérico que permite extender drásticamente las capacidades de HTTP.
Los programas en CGI añaden funcionalidad al servidor Web, ya que le permiten ejecutar cualquier programa, desde consultas a bases de datos, hasta envío de correo y generación automática de páginas web.
En este caso, la técnica utilizada en su forma más simple consiste en servirse de un guión o programa en CGI como filtro entre el usuario y la página que se desea proteger, con el fin de evitar accesos no deseados. Esta aplicación CGI debe alojarse en el directorio cgi-bin del servidor u otro directorio que el administrador proporcione a tal efecto.
Como en los casos previamente analizados, se trata de leer una clave introducida por el usuario y garantizar el acceso sólo si la clave es correcta. En este caso, dado que el código fuente no se encuentra disponible para los usuarios, bien porque el programa se compila, o bien porque, aunque siendo interpretado, el servidor no permite su listado, resulta posible embeber la clave dentro del código fuente, como se hace en el ejemplo. No obstante, en un caso real, conviene hacerlo de forma cifrada. Una vez verificada la clave, simplemente se transporta al usuario a la página de error si aquélla es incorrecta, o a la página protegida, si fuera correcta. A continuación se muestra un sencillo programa en C que serviría para restringir el acceso a una página.

#define CLAVE “reservado”
#define URL_CORRECTO “http://www.iec.csic.es/criptonomicon”
#define URL_INCORRECTO “http://www.iec.csic.es/criptonomicon/ac-
ceso/error.html”
int main()
{
llist entries;
node * item;
read_cgi_input(&entries);
item = entries.head;
if ( strstr( item->entry.value, CLAVE ) != NULL )
printf( “Location: %s\n\n”, URL_CO- RRECTO );
else
printf( “Location: %s\n\n”, URL_IN- CORRECTO );
}

Ahora bien, puede resultar tedioso tener que introducir el nombre y la clave cada vez que se quiere acceder a páginas protegidas en el sitio web. Para evitar esta repetición, una posible solución consiste en pedir el nombre y la clave una sola vez y almacenarlos en una cookie, de manera que a partir de ese momento cada vez que se acceda a un servicio protegido, se compruebe la información de autenticación leyendo la cookie. En la sección 7.4 se describen los problemas que plantea este enfoque.
Por otro lado, dado que con CGI se pueden generar páginas al vuelo, al igual que se hacía en ASP, se presentan interesantes posibilidades para soslayar el problema del bookmarking (v. sección 7.2). Por ejemplo, supóngase que se desea ofrecer una colección de fotos a aquellos que hayan pagado por verlas. Si las fotos no se acceden directamente a través de un URL, sino por medio de un CGI, se evita así que nadie pueda enlazarlas directamente. Si se combina esta capacidad con el almacenamiento de la información de autenticación en una cookie, se consigue que no sea necesario autenticarse para cada imagen descargada.
En el siguiente fragmento de código se muestra cómo se puede llevar a la práctica esta forma de servir imágenes.

#define IMAGES /home/users/gonzalo/images/
// Se leen las cookies para ver si se le permite al usuario ver la imagen
num_cookies = parse_cookies( &cookies );
if ( num_cookies > 0 ) {
item = cookies.head;
while ( item != NULL ) {
if ( strstr( item->entry.name, “usuario” ) != NULL ) {
if ( strstr( item->entry.value, CLAVE ) )
autenticado = 1;
break;
}
item = item->next;
}
}
// Si la cookie contenía el nombre y clave correctos, se le deja acceder a la foto
if ( autenticado ) {
// Se crea el URL completo del fichero que se quiere leer
strcpy( fichero, IMAGES );
strncat( fichero, sURL, 100 );
// Se intenta abrir el fichero
if ( ( f = fopen( fichero, “rb” ) ) == NULL ) {
printf ("Content-type: text/html\n\n");
printf( “Error, no se encontró el fichero <b>%s</b>", sURL );
return 1;
}
// Finalmente lo enviamos al cliente
envia_foto( f );

}
else
printf( “Location: %s\n\n”, URL_IN-CORRECTO );

En esta ocasión, los enlaces para saltar a una imagen pasarán a tener la siguiente forma:

/cgi-bin/filtro.exe?nombredeimagen

Donde filtro.exe es el nombre del programa en CGI y nombredeimagen es el nombre del fichero de la imagen que se desea ver. Obsérvese que no se incluye el camino completo de la imagen, sino sólo el nombre de fichero. Es importante notar que los ficheros con las imágenes pueden encontrarse en cualquier posición del árbol de directorios del servidor, no necesariamente en el área de documentos del servidor Web. En el código de ejemplo, la constante IMAGES define la posición dentro de la estructura de directorios donde se encuentran almacenadas las imágenes, no siendo accesible a través de la Web. De esta forma, se consigue aislar completamente el lugar físico donde se guardan las imágenes del área del servidor Web. En estas circunstancias, resulta completamente imposible enlazar directamente a las imágenes, sin pasar antes por el proceso de autenticación. Por supuesto, este método de servir ficheros puede aplicarse no sólo a imágenes, sino también a otros documentos en formato digital, resultando especialmente indicado para aquellos que deseen proteger imágenes (jpg, gif, bmp, tiff), textos (html, txt), otros documentos (word, pdf, ghostscript), sonido (wav, au, aiff, realaudio), animaciones (mpeg, avi, quicktime), con la ventaja de que resultan imposible de enlazar directamente desde otras páginas web (problema de los tres métodos anteriores), ya que el objeto a proteger no se encuentra físicamente en el área de documentos del sitio web.
Si se aprovechan completamente las posibilidades que ofrece la programación en CGI, se pueden desarrollar esquemas de protección muy complejos, con ficheros de control de acceso (ACF) que sirvan para especificar tanto autenticación de usuario como control de acceso por dominios. Sin embargo, su complejidad los sitúa fuera del alcance de este artículo. Los lenguajes más frecuentemente utilizados para escribir aplicaciones en CGI son Perl y C/C++, que pueden encontrarse gratuitamente en una gran variedad de plataformas.
El inconveniente que presentan es que, dado que una aplicación en CGI mal diseñada podría permitir acceso total o parcial al servidor, muchos administradores se muestran reacios a permitir a los usuarios que escriban sus propios CGI para su inclusión en el sitio web. De hecho, muchos se negarán o no ofrecerán esta posibilidad, por lo que se deberá recurrir en ese caso a alguno de los métodos anteriormente descritos (v. secs. 3 y 4), que no dependen del servidor.
Se pueden ver ejemplos completos de aplicaciones en CGI, con y sin cookies, así como de protección de documentos, en www.iec.csic.es/criptonomicon/acceso/cgi.html.

7. Limitaciones
A continuación se discuten las limitaciones presentadas por estos métodos, apuntando asimismo posibles soluciones para superarlas.

7.1 Listado de directorios
Aunque el listado de directorios puede ser conveniente, representa una amenaza para la seguridad. Si en la ventana de URL se introduce el nombre de un directorio y está habilitado el listado (browsing), aparecerán listados los contenidos de ese directorio, con sus carpetas y ficheros. En estas circunstancias, algunos de 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 in- dex.html o default.htm y si no está presente, aparecerá una página de error en vez de listarse el contenido del fichero.

7.2 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 propia 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.

7.3 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 alguna de las muchas herramientas que existen a tal fin. Por consiguiente, no hay que olvidar que el usuario firmemente determinado será capaz de obtener el código fuente, por lo que no conviene dejar en él material sensible ni claves en claro.
En el caso de C/C++, aunque el programa está compilado y enlazado, si se examina el ejecutable con un editor hexadecimal, se podrán leer las cadenas de texto, por lo que no conviene dejar las claves en claro. Ahora bien, salvo que el servidor esté deficientemente configurado, nadie podrá hacerse con los ejecutables.
Solución: se pueden utilizar ofuscadores de código, que dificultan la labor de decompilación, en el caso de Java. En el caso de C/C++, se puede cifrar la clave dentro del programa ejecutable.

7.4 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, en consecuencia, entrar a ese servicio.
Por otro lado, no todos los navegadores soportan cookies, o bien su aceptación está desactivada en muchos de ellos debido al halo de misterio y riesgo que las rodea (puede verse www.iec.csic.es/criptonomicon/cookies para una completa discusión sobre las cookies).
Solución: respecto al acceso físico a la cookie, lo más conveniente es que el usuario proteja celosamente sus archivos sensibles cuando no los esté utilizando, incluyendo el archivo de cookies. En el caso de la autenticación, la información guardada en la cookie de nombre y contraseña puede ser interceptada en tránsito, por lo que otra solución consistirá en utilizar un canal seguro mediante SSL.
Un camino alternativo de protección de la información de autenticación contenida en la cookie consiste en incorporar en la cookie la dirección IP del host del usuario y una sello de tiempo que especifique el período durante el cual la información de autenticación es válida. De esta forma, dicha cookie sólo sería válida para el usuario trabajando desde ese host. Con el fin de evitar la falsificación de estos datos, se puede incorporar en la cookie una información sólo conocida por el servidor y se calcula el hash de todo el conjunto. Este hash se concatena con los contenidos
anteriores antes de enviarla al navegador. Ahora, cuando el servidor reciba esta cookie, puede comprobar su autenticidad calculando el hash de la información de la cookie más ese secreto que sólo él conoce.
Autenticacion = dirección IP + fecha de caducidad + nombre de usuario + clave de acceso valor de la cookie = autenticación + hash (secreto + autenticación) 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 na-vegan por las páginas protegidas. Los pro- gramas de filtrado de cookies son otra solución aceptable, ya que permiten la aceptación selectiva de cookies, a diferencia de las opciones presentadas por los navega- dores, que se reducen a todo o nada. 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. Simplemente se verían obligados a autenticarse para cada documento protegido que quisieran visualizar.

7.5 Referer logs
Otro problema asociado es la aparición de la página secreta en el registro de referencias de algún servidor remoto. Si desde la página secreta se enlaza a alguna otra página fuera del propio sitio web, en los log del servidor de la máquina a la que se referencia aparecerá registrada rutinariamente la página de la que se provino. En el caso peor, el creador de la página enlazada ha podido incluir una página de estadísticas de acceso que resulte accesible por cualquier visitante a su web, de manera que el URL de la página expuesta quedaría a la vista de todos aquellos que se pasasen por la página de estadísticas del sitio referenciado.
Solución: nunca se debe enlazar páginas externas desde una página protegida por estos métodos. Se puede crear una página de enlaces desde la cual ya sí que se puede referenciar otras páginas sin correr este riesgo. La página protegida nunca enlazará al exterior, sino a esa página de enlaces.

Gonzalo Alvarez. [01/01/2000 ]