Seguridad en el Web

Hasta el momento, se ha presentado un Web que ofrece un acceso abierto a un conjunto de información que explícitamente se hace pública. Sin embargo, en determinadas circunstancias, es interesante poder limitar el acceso a documentos reservados o útiles para un conjunto restringido de personas. Se pueden establecer dos tipos de restricciones:

Limitación de acceso en función de direcciones IP o dominio. Sólo los usuarios de un dominio u organización tendrán acceso a la información. Limitación de acceso por nombres de usuario y claves de acceso.
Sólo los usuarios que conozcan una clave de acceso válida pueden acceder a la información.
Otro aspecto que está cobrando especial importancia es la seguridad de la información que se intercambia en el Web. La explotación comercial de Internet exige disponer de sistemas de comunicación seguros, capaces de adaptarse a las necesidades de los nuevos servicios, como la compra electrónica o la banca a distancia. En estos servicios, se manejan dos conceptos fundamentales, la autentificación (garantizar que tanto el usuario de un cliente Web como un determinado servidor de información son quienes dicen ser) y la confidencialidad (hacer que la información intercambiada no pueda ser interceptada por terceros).
Con los sistemas de comunicación actualmente en uso, es técnicamente posible ‘pinchar’ un enlace de comunicaciones e interceptar el contenido de las comunicaciones TCP/IP que por él se transmiten. Cuando se envía información privada, por ejemplo un número de tarjeta de crédito en un formulario de compra, es vital garantizar que la información sea recibida exclusivamente por su destinatario, y que la identidad es la esperada.

Control de acceso a la información

Se utiliza para limitar el acceso a determinados documentos de un servidor Web, en función del origen y tipo de petición.

La forma de hacerlo varía con el entorno en el que se publican las páginas (sistema operativo y servidor HTTP, principalmente) general, todas las soluciones pasan por definir un fichero que contiene las diferentes limitaciones de acceso, en un formato característico del servidor HTTP. En algunos casos se utiliza un fichero global con las restricciones de acceso o bien un fichero por cada directorio al que se quiere limitar el acceso.

Cuando un cliente Web accede a un fichero protegido, el servidor devuelve un código de error asociado a la falta de permisos para realizar la operación (código 401). Si el acceso se realiza desde un dominio o dirección IP prohibida, no será posible acceder a la información desde ese sistema. Cuando la protección se basa en nombres y claves de acceso, el browser solicitará estos datos y los enviará al servidor para que sean verificados. Las claves de acceso se envían al servidor por diferentes sistemas, sin codificar (sencillo pero inseguro) o codificadas (DES o Kerberos, por ejemplo). Será el propio servidor HTTP el que informe sobre la manera en que se deben enviar estas claves de acceso.Para conocer cómo se especifican estas listas de control de acceso, se puede emplear la documentación de los respectivos servidores HTTP.

En la bibliografía se incluyen enlaces a estas páginas. En los siguientes apartados, se hace un breve repaso de las posibilidades de tres servidores muy utilizados.

Control de acceso en un servidor CERN

La versión 3.0 del servidor desarrollado por el CERN permite limitar el acceso a documentos o grupos de documentos, en función de nombres de usuario o direcciones de origen. El control de acceso se puede realizar para todo el servidor, modificando los ficheros globales de configuración o para un directorio concreto. Como este método está disponible para cualquier usuario, sin necesidad de tener privilegios de administración, será el comentado aquí.El control de acceso al contenido de un directorio se realiza creando un fichero de nombre .www_acl , en el mismo directorio que los ficheros cuyo acceso se quiere controlar. Un ejemplo aclarará más el formato de este fichero:

secret*.html : GET,POST : trusted_people
minutes*.html : GET,POST : secretaries
*.html : GET : willy,kenny

Está formado por líneas, cada una de ellas fijando una limitación de acceso diferente. Para cada especificación de ficheros, se indica los comandos HTTP permitidos y los usuarios o grupos de usuarios que pueden acceder. Cuando se añade un control de acceso, automáticamente se deshabilita el acceso para los usuarios o grupos no incluidos. Se utiliza el mecanismo de autentificación básica, en la cual las claves de acceso son transferidas por la red sin codificar.
Se pueden crear usuarios o grupos de usuarios con la aplicación htadm, a través de la cual se generan nuevos usuarios y se les asigna claves de acceso. Además, a través de la configuración global del servidor, es posible fijar permisos de acceso por defecto, o restringir el uso del servidor a determinadas direcciones (o rangos de direcciones) IP.

NOTA

Se puede encontrar más información sobre el uso de los controles de acceso en http://www.w3.org/pub/WWW/Daemon/User/Config/AccessAuth.html.

Control de acceso en un servidor NCSA

El servidor HTTP de la NCSA (esto se aplica también a Apache, desarrollado a partir de él) permite limitar el acceso en función de direcciones de origen o nombres de usuario. El procedimiento es similar al del servidor del CERN. Se debe crear un fichero de nombre .htaccess en cada directorio cuyos ficheros requieran protección. Por ejemplo:

AuthUserFile /users/luis/usuarios
AuthGroupFile /users/luis/grupos
AuthName ByPassword
AuthType Basic
<LIMIT GET POST>
requiere user luis
allow from .cdec.unican.es
deny from .hackers.unican.es
</LIMIT>

Como se puede ver, el control de acceso afecta a todos los ficheros del directorio protegido. Se puede conceder o denegar el acceso en función de direcciones IP, en cuyo caso se utilizaría un fichero de control de acceso de la forma (all equivale a cualquier petición):

<Limit GET POST>
deny from all
allow from pc1.usuarios.unican.es
</Limit>

Además, NCSA soporta los sistemas de autentificación básico (en el que las claves circulan de forma visible por la red) o MD5 (que añade una codificación a estas claves). Los ficheros de usuarios y claves se crean con la aplicación htpasswd, que permite editar un fichero de claves (similar al passwd de UNIX):

htpasswd –c /users/luis/usuarios luis
à Ahora se teclearía la clave de acceso para luis

NOTA

Se puede encontrar más información sobre el uso de los controles de acceso en http://hoohoo.ncsa.uiuc.edu/docs/tutorials/user.html.

Control de acceso en un servidor Microsoft

El servidor HTTP de Microsoft puede limitar el acceso a máquinas o grupos de máquinas, a través de la utilidad de configuración del servidor (el Administrador de Servicios Internet). Para ello, se agrega la máscara de red de aquellos sistemas a los que se concede (o niega) el acceso al servidor.Además, es posible controlar de forma individual el acceso a
cualquier documento o directorio del servidor, sirviéndose de los permisos de acceso a ficheros y la base de usuarios del servidor NT.

Para poder utilizar este tipo de control de acceso, es necesario que el sistema de ficheros en que residen los documentos Web tenga formato NTFS, el único que permite asignar permisos de acceso a ficheros.

Seguridad y privacidad

El intercambio seguro de información a través de una red abierta e insegura como Internet ha obligado a desarrollar numerosos sistemas de encriptación y autentificación de las transacciones, destinados a cubrir tres problemas fundamentales:
Conocer la identidad real de los clientes y servidores que se comunican, de forma que ambos dispongan de algún sistema para verificar la identidad del otro. Este tipo de identificación tiene particular importancia en las cibertiendas, ya que al
enviar un número de VISA para realizar un pago se tiene que estar seguro de que el destinatario es quien dice ser.
Garantizar que la transferencia de datos sólo pueda ser entendida por las aplicaciones que se comunican, utilizando
métodos criptográficos para codificar todos los datos intercambiados, y evitar las ‘escuchas’ en la red.
Garantizar la integridad de los datos enviados, teniendo capacidad de detectar cualquier cambio, intencionado o no, en
los mismos. Los métodos criptográficos tradicionales operan a partir de una palabra o frase llave, que sirve para codificar y descodificar los datos intercambiados. Está llave debe ser conocida por los dos extremos de la comunicación, por lo que el punto débil de este método es justamente el proceso de difusión de la llave. Se han ideado diversos sistemas para realizar un intercambio seguro de las llaves, por lo general haciendo que cambien con el tiempo, pero casi todos tienen algún punto débil.
La mayoría de los intercambios seguros de información se realizan según un sistema denominado Criptografía de Clave Pública; cada extremo de la comunicación dispone de dos claves, una pública que cualquiera puede solicitar y conocer, y otra privada, cuya seguridad es fundamental para el éxito de la codificación. Para enviar un mensaje seguro a una persona, se solicita su clave pública, con la que se codifica el mensaje. El sistema garantiza que el mensaje resultante sólo puede ser descodificado con la clave privada del destinatario.
El siguiente paso es asegurar la correcta identidad del destinatario. Para ello, se han creado las autoridades de certificación, organizaciones o empresas que distribuyen certificados, unos documentos digitales que contienen la identidad y clave pública de una determinada organización. Cuando se establece una conexión segura con un servidor HTTP, es posible acudir a una de estas autoridades de certificación para verificar su identidad. Una de las autoridades de certificación más conocidas es Verisign www.verisign.com, una empresa que proporciona diversos tipos de certificados, personales o para empresas, tras un proceso de verificación de la identidad del solicitante (previo pago de una tasa).
Los clientes Web tienen una pequeña base de datos con las claves públicas de diversas autoridades de certificación, a partir de las cuales se pueden verificar las claves públicas de otros servidores. De esta forma, si se codifica un mensaje con la clave pública de un determinado servicio Web, la información enviada sólo podrá ser interpretada por el destinatario del mensaje.

A partir de la criptografía de clave pública se ha desarrollado SSL (Secure Sockets Layer), un sistema de codificación de información propuesto por Netscape que codifica toda la información transferida al nivel de conexiones TCP, por lo que es compatible con todos los protocolos y servicios de Internet. SSL está incluido en los clientes Web de Netscape, Microsoft, IBM... El establecimiento de una conexión SSL consta de las siguientes fases:
El cliente y el servidor intercambian sus certificados de autenticidad (el cliente no tiene necesariamente uno). Estos certificados se validan con una autoridad de certificación. Este procedimiento es el llamado ‘sistema de autentificación de RSA’ www.rsa.com .El cliente genera una clave aleatoria, que envía al servidor tras codificarla con la clave pública de este; el servidor hace un proceso similar. De esta forma, las claves de encriptación sólo pueden ser conocidas por el cliente y el servidor. Esas llaves se utilizan para encriptar todos los datos intercambiados. El sistema criptográfico empleado en este punto es elegido como el más seguro entre todos los conocidos por el cliente y el servidor (por ejemplo, RC2, RC5, DES o IDEA). Adicionalmente, se puede utilizar un sistema de firma digital de los contenidos, como MD5. Como puede verse, SSL combina criptografía de clave pública, para el intercambio de las claves de cifrado, y criptografía de clave privada, para el intercambio de información. Esto es necesario porque la criptografía de clave pública implica muchos más cálculos
que la otra, por lo que no es factible para mantener una conexión cifrada.
La base de cualquier sistema de codificación es el tamaño de la llave empleada para encriptar el contendido de los mensajes. Con SSL, se pueden utilizar varios tamaños de llave desde 40 bits. En la actualidad, las llaves de 40 bits pueden ser desencriptadas en un tiempo razonablemente corto empleando sistemas informáticos de alto rendimiento, cosa mucho más complicada con las llaves de 128 bits o más. Sin embargo, Estados Unidos impone restricciones para exportar
fuera de su país aplicaciones que utilicen codificación de más de 40 bits. Estas restricciones no se aplican a los sistemas de
autentificación de identidad, que pueden utilizar llaves de cualquier longitud.
Otro sistema bastante utilizado es S-HTTP, una versión de HTTP que incorpora criptografía de clave pública para la autentificación y el intercambio seguro de datos. Sin embargo, S-HTTP sólo puede utilizarse para intercambiar datos entre clientes y servidores Web, mientras que SSL actúa de forma transparente para cualquier aplicación de comunicaciones TCP/IP.
Los siguientes enlaces proporcionan más información sobre temas relacionados con la seguridad y la criptografía en Internet:
El RSA FAQ about cryptography, un extenso manual de referencia, muy actualizado, que describe el funcionamiento de la mayoría de los sistemas de cifrado y autentificación que se utilizan en la actualidad. Se puede encontrar en: http://www.rsa.com/rsalabs/newfaq/.

Netscape dispone de información detallada sobre el funcionamiento de SSL, y la forma de integrar este sistema en nuestros propios desarrollos. Se puede consultar una introducción general a SSL, los certificados de servidores y otros temas relacionados en: http://search.netscape.com/newsref/ref/128bit.html.El W3 Consortium dispone de material de referencia sobre seguridad, en http://www.w3.org/Security/.

Los clientes Web muestran avisos de advertencia cuando la conexión pasa de modo normal a modo seguro y viceversa (el candado o llave abiertos de la esquina inferior izquierda de Netscape Navigator o Internet Explorer). A partir de este momento se puede asegurar la identidad del servidor remoto, y la total privacidad de los datos intercambiados. La siguiente pantalla muestra los detalles de una conexión segura establecida con una tienda electrónica.Location: https://www.aberdeeninc.com/abcatg/sidecheck.htm

File MIME Type: text/html
Source: Currently in memory cache
Local cache file: none
Last Modified: 7 de noviembre de 1997 23:15:04 Local time
Last Modified: 7 de noviembre de 1997 22:15:04 GMT
Content Length: 27076
Expires: No date given
Charset: iso-8859-1
Security: This is a secure document that uses a medium-grade
encryption key suited for U.S. export (RC4-Export, 128 bit with
40 secret).
Certificate: This Certificate belongs to:
www.aberdeeninc.com
Aberdeen LLC
Santa Fe Springs, California, US
This Certificate was issued by:
Secure Server Certification Authority
RSA Data Security, Inc.
US
Serial Number: 02:F3:00:1C:48
This Certificate is valid from Tue Aug 12, 1997 to Sat Aug 15,
1998
Certificate Fingerprint:
D6:26:95:63:07:90:F2:E2:21:50:AA:EE:4C:45:43:AF

Los clientes Web modernos disponen de una base de datos con los datos de varias autoridades de certificación, que se utilizarán para verificar las ‘identidades digitales’ de los servidores HTTP con los que se trate de establecer una conexión segura.( El siguiente ejemplo muestra las características de la autoridad de certificación de Verisign.)