SEGURIDAD EN EL SERVICIO WORLD WIDE WEB Y VERIFICADOR DE FALLOS DE SEGURIDAD EN CLIENTES DE WEB

PABLO JESS MOGOLLN SOMAVILLA

FACULTAD DE INGENIERIA DEPARTAMENTO DE INGENIERA DE SISTEMAS Y COMPUTACIN UNIVERSIDAD DE LOS ANDES SANTAF DE BOGOT, 1998

SEGURIDAD EN EL SERVICIO WORLD WIDE WEB Y VERIFICADOR DE FALLOS DE SEGURIDAD EN CLIENTES DE WEB

PABLO JESS MOGOLLN SOMAVILLA

Trabajo de grado presentado como requisito parcial para optar al ttulo de Magister en Ingeniera de Sistemas y Computacin Director: Alejandro Quintero I.S., Ph.D. Jurados: Harold Castro I.S., Ph.D. Daro Correal I.S., M.I.S.

FACULTAD DE INGENIERIA DEPARTAMENTO DE INGENIERA DE SISTEMAS Y COMPUTACIN UNIVERSIDAD DE LOS ANDES SANTAF DE BOGOT, 1998

TABLA DE CONTENIDO Y...................................................................................................................................................1 VERIFICADOR DE FALLOS DE SEGURIDAD EN CLIENTES DE WEB.......................1 PABLO JESS MOGOLLN SOMAVILLA..........................................................................1 PABLO JESS MOGOLLN SOMAVILLA..........................................................................2 INTRODUCCIN......................................................................................................................1 1. INTERNET Y EL SERVICIO WWW...................................................................................3 1.1 CONJUNTO DE PROTOCOLOS TCP/IP........................................................................3 1.2 HYPERTEX TRANSFER TRANSMISION PROTOCOL...............................................4 1.3 LENGUAJE DE MARCAS DE HIPERTEXTO................................................................5 1.4 LENGUAJES PARA GUIONES DE COMANDOS EN EL CLIENTE...........................6 1.5 COOKIES.............................................................................................................................7 1.6 PLUG-IN...............................................................................................................................8 1.7 JAVA.....................................................................................................................................8 1.8 ACTIVEX...........................................................................................................................10 2 RIESGOS DE SEGURIDAD EN EL SERVICIO WWW...................................................12 2.1 EL SERVICIO WWW CADA VEZ ES MS SENSIBLE A LA SEGURIDAD...........12 2.2. QU ES SEGURIDAD EN EL SERVICIO WWW?....................................................12 2.3 SEGURIDAD EN EL SERVIDOR WWW.......................................................................14 2.4 SEGURIDAD EN LA CONEXIN...................................................................................19 3 SEGURIDAD EN EL VISOR...............................................................................................23 3.1 Tipos de fallas de seguridad en el visor.............................................................................23 3.1.1 Informacin del sistema no sensible expuesta ..............................................................23 OJO qu significa????........................................................................................................23 3.1.2 Revelar informacin sensible ........................................................................................23 3.2 CAUSAS PRINCIPALES DE LAS FALLAS DE SEGURIDAD....................................24 4 SEGURIDAD EN EL CLIENTE DE WEB.........................................................................29 4.1 ANLISIS DE NECESIDADES DE SEGURIDAD.........................................................29 4.1.1 Navegacin personal........................................................................................................29 4.1.2 Navegacin desde una red corporativa..........................................................................30 4.2 NETSCAPE NAVIGATOR...............................................................................................35 4.3 MICROSOFT INTERNET EXPLORER.........................................................................37 4.4 PROPUESTAS PARA LA INTERFAZ DE CONFIGURACIN..................................38 4.5 MECANISMOS DE SEGURIDAD PROPUESTOS........................................................40 5. ALGUNAS PROPUESTAS EXPERIMENTALES PARA MEJORAR LA SEGURIDAD ...................................................................................................................................................45 5.1 FILTRO PARA JAVA.......................................................................................................45 5.2 AMBIENTE SEGURO PARA VISORES DE DOCUMENTOS....................................46 5.3 ESPACIOS DE OBJETOS SEGUROS.............................................................................48 5.4 PRUEBA CONTENIDA EN CDIGO.............................................................................49 6 VERIFICADOR DE SEGURIDAD.....................................................................................51 6.1 JUSTIFICACION...............................................................................................................51 6.2 DEFINICION......................................................................................................................52 6.4 DISEO..............................................................................................................................53 6.5 ANLISIS DE ATAQUES.................................................................................................55 7 Control de recursos en Java..................................................................................................62 7.1 RECURSOS QUE SE VAN A PROTEGER.....................................................................62 7.2 NIVELES DE PROTECCION..........................................................................................63 7.4 DISEO..............................................................................................................................64 7.4.6 Interfaz del usuario.........................................................................................................65 7.4.7 Interfaz de la clase...........................................................................................................65 8 CONCLUSIONES.................................................................................................................67 REFERENCIAS BIBLIOGRAFICAS....................................................................................69 DIRECCIONES URL..............................................................................................................72

INTRODUCCIN
Internet ya no es una novedad. En los pocos aos que la red de redes ha estado disponible para el pblico colombiano se ha convertido en un medio comn para trabajar, divertirse, comunicarse, conocer personas, comprar, jugar y un largo etctera. Internet puede afectar todos los aspectos de la vida de una persona. En la red se puede encontrar informacin sobre cualquier tema y se puede contactar personas sin limites de distancias o fronteras. Si este influjo es positivo o negativo es un tema que lleva a largos y ridos debates similares a los que ha originado la televisin; el hecho es que Internet est aqu y se populariza rpidamente. Por otro lado existe una tendencia hacia el mejoramiento de los programas que se utilizan en Internet. Este mejoramiento tiene que ver principalmente con nuevos tipos de documentos que se pueden presentar automticamente y con nuevos mecanismos para proporcionar mayor interactividad. Es decir, que la comunicacin entre el cliente y el servidor sea de dos vas (tradicionalmente la Web se limitaba a presentar en el programa cliente informacin almacenada en el servidor) y que se pueden ejecutar programas automticamente en ambos extremos de la comunicacin. Es notorio como un usuario de Internet colombiano en 1993 estaba satisfecho con el uso de programas cliente de E-mail, FTP, WAIS y gopher a travs de una interfaz de texto. En estos momentos este ambiente se considera primitivo como si de la prehistoria se tratar. Actualmente, a travs de una interfaz grfica con un solo programa se puede tener acceso a todos los servicios anteriores, al World Wide Web, a ambientes multimedia y mundos virtuales. Los protocolos y tecnologas que se utilizan sobre la red de redes han sido mejorados, se desarrollan nuevos mecanismos continuamente y la industria est orientada claramente hacia una integracin entre el ordenador y la red que difumina donde termina uno y empieza la otra. Dada la gran popularidad de Internet y el impulso tecnolgico que presenta, son notorias la carencia de medidas apropiadas de seguridad en los programas cliente y, sobre todo, la poca o casi nula conciencia entre la mayora de los usuarios sobre las implicaciones que tiene el conectar una computadora a la red. Por un lado, existe una guerra comercial entre las dos empresas principales que desarrollan programas para Web. Ambas empresas buscan tener el mejor programa cliente de Web; por lo tanto se desarrollan nuevos mecanismos y los entregan al pblico sin un periodo de prueba apropiado. Los programas son cada vez ms complejos y aparecen multitud de problemas por defectos en el diseo de los nuevos mecanismos, fallas en la implementacin o por interacciones inesperadas entre diferentes tecnologas. Por otro lado, el usuario comn no-tcnico que utiliza la web como otro medio de comunicacin no suele estar consciente de las implicaciones de conectar su computador a la red y de cmo proteger su informacin y su privacidad de intromisiones del exterior. Por todo lo anterior esta tesis quiere hacer un anlisis de los riesgos a los que se enfrenta un usuario comn al utilizar Internet, del estado actual de los mecanismos de seguridad, y proponer una serie de polticas y herramientas que permitan hacer ms seguro el ambiente de trabajo sobre el World Wide Web1. El trabajo est estructurado de la siguiente manera: Captulo 1. Internet y WWW: El captulo permite establecer las bases de Internet y del servicio WWW. Difcilmente se puede estudiar o entender la seguridad de algo que no se conoce con cierta profundidad. Captulo 2. Seguridad en WWW: Se hace un recuento de los problemas de seguridad que aquejan al servicio WWW en general para terminar haciendo nfasis en los aspectos que conciernen al usuario. Captulo 3. Anlisis de las causas de inseguridad en la Web. Antes de intentar encontrar soluciones se debe tener claro cuales son las bases de la situacin actual en el servicio WWW.

Se puede traducir como Telaraa de Alcance Mundial pero, dado que se ha convertido en un vocablo comn, se utilizar World Wide Web o, en forma abreviada, WWW y Web.

Captulo 4. Seguridad en el visor. Se comenta el estado actual de la tecnologa de seguridad en las implementaciones ms populares y se proporcionan algunos lineamientos que se deberan tener en cuenta para desarrollar la seguridad en la Web. Captulo 5. Discusin acerca de las polticas de seguridad en el visor. Captulo 6. Se presentan algunos esfuerzos experimentales para aumentar la seguridad en la Web y se discuten sus beneficios y defectos. Captulo 7. Verificador de seguridad para visores (SATANWEB): Se disea e implementa una herramienta que permite a un usuario comn conocer el estado de seguridad de su ambiente de trabajo sobre Internet.

1. INTERNET Y EL SERVICIO WWW

Internet es un conjunto de redes interconectadas que conforman un sistema de mbito mundial para intercambio de informacin y mejor aprovechamiento de recursos de computo. Est definicin proporciona algunas de las caractersticas bsicas de Internet. Es una red heterognea; es decir, no se encuentra limitada a un conjunto de arquitecturas, procesadores o sistemas operativos. Internet no tiene propietario: es una gran asociacin mundial de redes de diversa naturaleza (corporativas, educativas, comerciales, etc.). Los orgenes de la red de redes se pueden encontrar en ARPANET, la red de la Agencia de Proyectos de Investigacin Avanzados (ARPA por sus siglas en Ingls) de Estados Unidos. El proyecto ARPANET iniciado en 1969 buscaba crear una red que ofreciera conexiones slidas entre computadoras de diferentes fabricantes y arquitecturas. Para 1975 la tecnologa que soportaba ARPANET estaba suficientemente madura como para dejar de considerarla un proyecto experimental y tratarla como una red completamente operacional. El siguiente paso consisti en interconectar redes completas, no slo computadoras de manera que se creo el Internet Protocol Suite o TCP/IP que se normaliz en 1983. Inicialmente slo tuvieron acceso a la red centros militares, centros de investigacin y universidades, pero poco a poco se fue expandiendo para usos comerciales y personales de manera que por razones de seguridad se dividi la red original en dos, una para uso militar llamada MILNET y otra que continu llamndose ARPANET y despus Internet. Aunque Internet puede ser utilizado para todo tipo de aplicaciones, existen un conjunto de servicios comunes para los usuarios; Telnet, FTP, WAIS, FINGER, GOPHER y World Wide Web son los ms conocidos. WWW junto con el correo electrnico ha contribuido enormemente a la popularizacin de Internet. El servicio World Wide Web es un sistema de presentacin de informacin hipertexto con interfaz grfica, independiente de plataformas y arquitecturas de mbito mundial (hasta donde llegue Internet). El World Wide Web se origin como un proyecto de distribucin de documentos en red del Laboratorio Europeo para Fsica de Partculas (CERN). Este servicio se basa en la relacin entre servidores que contienen los documentos y clientes que pueden acceder a esta informacin. El cliente del servicio proporciona una interfaz para desplazarse entre piezas de informacin mediante mecanismos de apuntar y pulsar (clicking), el servidor WWW reacciona enviando un nuevo documento hipertexto HTML y archivos de diferente naturaleza como grficos o sonidos que estn incrustados en el documento HTML, el programa cliente los recibe, da formato al contenido y lo presenta. De esta manera se puede alcanzar una visin multimedia de Internet. El cliente de Web se suele llamar agente de usuario o, ms comnmente, visor (browser) o navegador. El visor se usa para presentar documentos HTML y documentos definidos por la norma MIME. El visor tambin puede ser usado para acceder a servicios diferentes al WWW como FTP, GOPHER y otros. La fuerte competencia entre las compaas que desarrollan estos programas ha impulsado la creacin de nuevas tecnologas que permiten aumentar la flexibilidad de este servicio como Java, ActiveX, Plug-in, Server Side Includes, etc. Las nuevas capacidades de los visores y de los servidores WWW han ampliado el abanico de aplicaciones basadas en este servicio. Ya no se trata de un eficiente mecanismo de presentacin de informacin hipertexto sino que es utilizado para comercio electrnico, interfaz para bases de datos, sistemas de trabajo colaborativo, ambientes de realidad virtual y un siempre creciente nmero de nuevas aplicaciones. Este trabajo tiene que ver con el World Wide Web principalmente y con el visor utilizado para hacer uso de este servicio de manera que se van a presentar los mecanismos bsicos utilizados por este servicio para poder sentar las bases sobre las cuales se discutirn posteriormente los riesgos de seguridad existentes en el ambiente de Web. 1.1 CONJUNTO DE PROTOCOLOS TCP/IP TCP/IP es el conjunto de protocolos para comunicacin entre computadoras ms usado en el mundo y base para la red de redes Internet. Su nombre se debe a los dos protocolos ms

importantes, Transport Control Protocol (Protocolo de Control de Transporte) e Internet Protocol (Protocolo entre redes). Fue creado por el DoD (Department of Defense) de E.E.U.U. para conectar redes de diferentes fabricantes. Por ser una red que deba poder enfrentar los rigores de un conflicto blico se diseo para ser una red robusta con capacidad para recuperarse de la cada de un nodo o de una lnea de comunicaciones. De esta manera se pueden crear grandes redes que no requieren de administracin intensiva. Por la misma razn algunos problemas pueden permanecer sin detectarse ni corregirse. A pesar de considerar seriamente la seguridad de las conexiones en el diseo de los diferentes niveles de Internet, no se pens en mecanismos para proteger la informacin que viaja a travs de Internet, crear servicios de usuario seguros o proteger los mecanismos de enrutamiento, servicio de nombres y otros contra datos de control falsos (direccin de origen, nmero de secuencia TCP, informacin de fragmentacin). 1.2 HYPERTEX TRANSFER TRANSMISION PROTOCOL Hyper Text Transmision Protocol o HTTP es el protocolo bsico utilizado para intercambiar informacin entre clientes y servidores de World Wide Web. Se basa en conexiones TCP y el puerto por defecto (well known port) es el 80. Este protocolo crea un mecanismo solicitud/respuesta clsico de la arquitectura cliente/servidor. Las peticiones del cliente y las respuestas del servidor tienen el mismo formato: lnea de peticin o respuesta, encabezado y cuerpo del mensaje. Una solicitud del cliente tiene la siguiente forma: Lnea de peticin. Se compone de un comando o mtodo HTTP, una direccin de documento y la versin de HTTP que est usando. Por ejemplo GET /index.html HTTP/1.0. Encabezado, son varias lneas cada una compuesta de un nombre de atributo y uno o varios valores que permiten identificar al programa cliente, que tipo de informacin puede manejar (formatos de grficos, cdigo Java, etc.) y que versin de HTTP usa. Termina con una lnea en blanco. Las lneas son similares a: User-Agent: Mozilla/2.02Gold (WinNT; I) o Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, /. Informacin adicional que puede ser los valores de una forma HTML que utiliza la accin POST, destinados a un CGI. El servidor responde as: Lnea de respuesta que indica la versin de HTTP y un cdigo de estado de la siguiente manera HTTP/1.0 200 OK Un encabezado con informacin acerca del servidor y del documento con un formato anlogo al encabezado del cliente. Varias lneas de informacin con pares atributo/valor(es) y finaliza con una lnea en blanco. Algunos ejemplos del contenido del encabezado son Date: Fri, 20 Sep 1996 08:17:58 GMT, Server: NCSA/1.5.2, Last-modified: Mon, 17 Jun 1996 21:53:08 GMT, Content-type: text/html, Content-length: 2482. Contenido del documento: Si el servidor pudo responder satisfactoriamente la solicitud en esta zona va el documento solicitado; si ocurri una falla se incluye una explicacin de la falla. Al enviar los mensajes de error en texto llano el cliente no tiene que lidiar con cdigos que pueden variar (a medida que aumentan las capacidades del cliente existen nuevas razones para que una solicitud de documento no sea exitosa), muestra la informacin que llega del servidor sin importar que sea el documento solicitado o un documento de mensaje de error. Un documento HTML contiene otros documentos incrustados en l, que corresponden a grficos, sonidos, cdigo ejecutable y otros. En la versin 1.0 de HTTP una vez se enva un documento se cierra la conexin (a menos que se enve una indicacin keep alive) y se debe volver a establecer para cada uno de los objetos incrustados, debido al tiempo requerido para establecer cada nueva conexin se crea una sobrecarga innecesaria. En la versin 1.1 la misma

conexin es utilizada para enviar todos los archivos y el cliente o el servidor deben cerrar explcitamente la conexin. En el protocolo HTTP no existe el concepto de sesin; esto quiere decir que el servidor no guarda estado de la conexin y cada vez que el cliente desea solicitar una pgina Web debe establecer de nuevo la conexin y proporcionar todos los parmetros necesarios para que el servidor sepa como responderle. Los mtodos ms utilizados en las solicitudes del cliente al servidor son: GET: Se utiliza para solicitar un documento al servidor y para enviar datos a un programa o guin de comandos (script) CGI. Cuando se usa GET con un programa CGI los parmetros se colocan inmediatamente despus de la URL que identifica al documento separndolos con un signo de interrogacin (?) y cada par valor/atributo se separa con un signo ampersand (&). Por ejemplo GET /cgi-bin/pedido.pl?item=203486&cantidad=2 HTTP/1.0 enva los datos de referencia de artculo y cantidad a un CGI que los procesar. Como este mecanismo tiene limitaciones de espacio se suele usar POST para programas que requieren gran cantidad de parmetros o parmetros muy extensos. HEAD: Permite obtener la informacin de encabezado de un archivo o recurso. El cliente puede desear obtener la fecha de modificacin de un archivo para poder decidir si presenta el que tiene en cache o lo solicita efectivamente al servidor o para obtener el tamao del documento y calcular el tiempo que va a tardar en recibirlo. POST: El mtodo POST sirve para enviar datos del cliente al servidor en la parte correspondiente a los datos adicionales de la peticin. Una vez recibida la peticin, el servidor ejecuta el programa o guin de comandos indicada y le pasa los parmetros que se encuentran en esta zona. LINK: Solicita que la informacin que va en la zona de encabezado sea asociada al documento indicado en la solicitud UNLINK: Lo contrario de la anterior, solicita que la informacin que va en el encabezado se desasocie del documento. PUT: Solicita que el contenido de la zona de informacin sea almacenado en el archivo indicado. DELETE: Solicita la eliminacin del archivo. OPTIONS: Solicita informacin acerca de las opciones de comunicaciones disponibles. TRACE: Solicita que el contenido de informacin de la peticin sea devuelto al cliente intacto. Se usa para depuracin de programas. 1.3 LENGUAJE DE MARCAS DE HIPERTEXTO El Lenguaje de Marcas de HiperTexto (HTML por sus siglas en ingls) define el conjunto de marcas utilizado para crear los documentos de hipertexto que son la base de la navegacin en WWW. Las marcas sirven para definir la estructura interna y la presentacin del contenido del documento hipertexto. Un documento HTML esta elaborado en texto llano ASCII y contiene una serie de marcas que definen el formato del texto, las referencias a otros objetos o secciones del mismo documento. Existe una gran cantidad de investigacin para desarrollar la norma base de HTML. Se debe tener en cuenta que la implementacin de HTML entre los diferentes agentes de usuario suele diferir pues cada compaa intenta extenderla ms y tambin convertir su propio conjunto de marcas en una norma de facto. Dentro del documento, las marcas HTML se reconocen pues van encerradas entre los signos menor que (<) y mayor que (>). Las marcas definen el formato o las propiedades de una zona determinada del documento, por lo tanto suele existir una marca inicial y una marca final que delimitan el campo de influencia del par de marcas, la marca de inicio consta del nombre y puede contener algunos parmetros, la marca del final consta slo del nombre precedido por una lnea inclinada / (slash). Por ejemplo <A HREF= java.sun.com/index.html> Java</A> indica que el texto Java aparecer destacado y que al pulsar sobre l, el visor solicitar el documento index.html al servidor java.sun.com.

El primer elemento es el documento HTML el cual se compone de un elemento encabezado (HEAD) y otro cuerpo (BODY). La estructura general del documento es la siguiente: <HTML> <HEAD> Datos del encabezado... </HEAD> <BODY> Texto, hipervnculos y objetos... </BODY> </HTML> En el encabezado pueden presentarse datos acerca del documento, informacin del autor, del programa editor de HTML y palabras claves del contenido para facilitar el trabajo de los robots que recogen informacin para los motores de bsqueda. En el cuerpo va la informacin que se presentar. Existen marcas para designar prrafos, listas, tablas, lneas horizontales, separacin de lneas, imgenes, sonidos, cdigo de guiones de JavaScript o VBScript y otros. Hasta aqu HTML es una gran herramienta para presentar informacin esttica, sin embargo si se desea cambiar el formato de la informacin de acuerdo a las acciones del usuario (eventos de ratn o teclado) se debe enviar el requerimiento al servidor y esperar que llegue un nuevo documento probablemente generado por un guin de comandos o programa CGI lo cual requiere largos tiempos de espera de transmisin y presentacin. Para solventar este problema se desarroll una extensin para HTML conocida como HTML Dinmico (DHTML) en la cual cada marca es un objeto con identificacin nica y propiedades. Las propiedades permiten determinar como reaccionar una marca a situaciones especficas. De esta manera se pueden modificar (cambiar el valor de las propiedades) marcas especficas identificndolas por su nombre modificando la apariencia de partes especficas del documento HTML. Gracias a este mecanismo cada vez que se desea ver un documento con un formato diferente (cambiar el orden de una lista, ver ciertos elementos resaltados, etc.) este es generado en el visor y no se debe desarrollar el lento proceso de solicitarlo al servidor, transmitirlo y dar formato a toda la pgina HTML. 1.4 LENGUAJES PARA GUIONES DE COMANDOS EN EL CLIENTE Un lenguaje de guin de script o lenguaje de script para Web permite crear programas sencillos para proporcionar nuevas capacidades a los documentos HTML. En principio parecen ser similares al HTML dinmico y en efecto pueden tener aplicaciones similares en algunos casos y se pueden combinar. Por ejemplo se puede cambiar el color de fondo de un documento HTML con HTML Dinmico o con un lenguaje de guiones de script. Sin embargo la filosofa es diferente, una marca DHTML tiene una serie de propiedades que permiten que el documento reaccione a diferentes eventos y est ntimamente ligada a la estructura y presentacin del documento, el lenguaje de script es ms general, permite manejar variables a lo largo del documento y tiene la capacidad mnima esperada en un lenguaje como ciclos, condicionales, etc. Por lo tanto son diferentes y complementarios, resultan una buena combinacin para dar funcionalidad a una pgina WWW. Mientras DHTML puede animar un formato para modificar las entradas de datos de acuerdo a las respuestas y selecciones del usuario, un lenguaje de script puede realizar labores relativamente ms complejas como validacin de coherencia de datos. El primer lenguaje de script que se us ampliamente fue JavaScript desarrollado por Netscape en 1995 con el nombre de LiveScript. En ese mismo ao Sun sac a la luz el lenguaje Java. Netscape desarroll LiveScript con una sintaxis basada en la de Java y con acceso a un conjunto de objetos que componen la interfaz para ejercer influencia sobre el visor, el documento o los diferentes objetos que lo componen. A finales de 1995 se lleg a un acuerdo entre Sun y Netscape de manera que Sun respald la idea de un lenguaje de script y se cambi el nombre del producto a JavaScript. Actualmente el Explorador de Internet de Microsoft tambin soporta JavaScript con algunas variaciones. A esta implementacin del lenguaje se le conoce como Jscript. JavaScript tiene algunas medidas de seguridad implementadas para proteger el sistema y separar documentos de fuentes confiables de documentos de fuentes no confiables: Poltica de mismo origen: Al presentar en marcos varios documentos simultneamente, el cdigo obtenido en un documento HTML no puede obtener o modificar la informacin de

objetos obtenidos de otro servidor o del mismo servidor pero diferente puerto. Los objetos sujetos a comprobacin de origen son imgenes, capas, ventanas y documentos. En el Navegador 3.0 exista la posibilidad de exponer algunos elementos para ser vistos desde cdigo de diferente origen (mecanismos data tainting) pero a partir del Navegador 4.0 se retiro este mecanismo. Guiones de comandos firmados: A partir de la versin 4.0 del Navegador se implement un modelo para firma de guiones JavaScript basado en el modelo Java de Sun para firma de objetos. Por lo tanto un guin que desea obtener privilegios debe utilizar LiveConnect para acceder al API de Capabilities de Java. Para firmar un guin o un objeto se utiliza la herramienta de firma de pginas (Page Signer tool) de Netscape que asocia una firma digital con los guiones de un documento HTML y la guarda en un archivo JAR (Java Archive). Los privilegios asociados al propietario de la firma (principal) representan la autorizacin o negacin para acceder a un objeto (target). Principales de origen: JavaScript permite que se asocie el script a un principal derivado del origen del documento. Es decir los permisos asociados al guin de comandos se basan en la confiabilidad del servidor o del dominio de origen. Este mecanismo resulta mucho ms dbil que el uso de firmas digitales y por lo tanto est desactivado por defecto aunque el Navegador lo utiliza para reforzar la poltica de mismo origen explicada anteriormente.

Otro lenguaje que es importante por el respaldo que le da la compaa que lo creo es VBScript. Basado en la sintaxis de VisualBasic, tiene propiedades similares a las de JavaScript y es soportado por el Explorador de Internet de Microsoft. Las caractersticas bsicas de un lenguaje de script son: Es interpretado. El visor debe tener integrado el interpretador para poder procesar el guin de comandos. Puede ser combinado con HTML. Existen marcas que permiten identificar donde empieza y termina un guin de comandos o para sealar que porcin de cdigo debe ser invocada como respuesta a un evento. El lenguaje no puede extender su influencia ms all del ambiente del navegador. El lenguaje est diseado para ejercer influencia sobre el visor, los documentos que contiene y los objetos incrustados en cada documento, no debe tener acceso libre y directo sobre recursos como los medios magnticos de almacenamiento, interfaz de red, perifricos, etc. En general no se requiere un compilador o alguna herramienta de desarrollo para crear guiones de comandos. Los lenguajes modernos de script estn basados en objetos. Aunque presentan limitaciones (generalmente no hay herencia) se puede utilizar un conjunto de objetos que el interpretador ofrece. Su trabajo se basa en eventos definidos dentro de las marcas HTML, de esta manera los diferentes guiones pueden responder a acciones del usuario. 1.5 COOKIES Como se dijo en el apartado sobre HTTP, el ambiente de Web no ofrece soporte para el concepto de sesin. Sin embargo para muchas aplicaciones se necesita mantener una sesin entre diferentes pginas Web, por ejemplo si se presenta una forma de identificacin de un usuario para poder determinar sus derechos dentro del sistema, no existe un mecanismo preestablecido que permita guardar la informacin del usuario en el servidor para que este pueda tomar decisiones sobre qu documentos le puede enviar o no. Netscape ide un mecanismo para guardar la informacin de estado en el cliente de manera que el servidor pueda recuperarla cuando la necesite, esta informacin y el archivo que la contiene suelen llamarse cookie. Posteriormente si el cliente enva una solicitud a un servidor para el cual tiene una cookie (est especificado en la misma cookie) sta ser enviada junto con la peticin. El servidor recibe la consulta y coloca la informacin en una variable de ambiente

(generalmente HTTP_COOKIE) de manera que cualquier programa CGI que sea invocado pueda hacer uso de dicha informacin. Si existe ms de una cookie en la peticin, toda la informacin es convertida en una cadena de pares nombre de atributo y valor que se almacenan en dicha variable de ambiente. El cliente enva la informacin contenida en la cookie a un servidor slo cuando la direccin del servidor encaja con la direccin o dominio especificados dentro de la misma cookie. La coincidencia no necesita ser completa; es decir, si la cookie especifica que est destinada al dominio uniandes.edu.co los servidores isis.uniandes.edu.co y odin.uniandes.edu.co recibirn la cookie si se les hace un requerimiento. La direccin de servidor o de dominio especificada en la cookie y la direccin del servidor con el que est conectado el agente de usuario deben contener dos elementos en comn (de derecha a izquierda) como mnimo y tres si est incluida la indicacin del pas. Si se definiese una cookie destinada al dominio com la recibiran muchos servidores cuyos programas CGI no la esperan y puede ocasionar ruido o incluso presentar problemas con cookies legtimas que tienen el mismo nombre para alguno de sus atributos. Est definidos los siguientes lmites para este mecanismo: 4Kb para el tamao del archivo que contiene una cookie. Mximo 300 cookies por visor 20 cookies por dominio. Los archivos de cookies son almacenados en un directorio especfico que no debe poder ser modificado mediante programacin Las cookies tienen un tiempo lmite de vigencia. Si no se especifica, se consideran desactualizadas en el momento en que se descarga de memoria el programa visor. Una vez desactualizadas pueden ser borradas. Los programas visor conocidos no permiten desactivar la recepcin de cookies desde el servidor, se puede configurar el programa para que presente una ventana de decisin por cada cookie que llega. Dado que hay sitios que presentan varias cookies, si se configura el visor para que avise que cookies llegan de cada servidor se corre el peligro de dedicar ms tiempo a administrar cookies que a navegar por Internet. En cambio no existe ninguna configuracin que permita a un usuario impedir que se enve la informacin contenida en las cookies hacia un servidor, es decir, no se puede vetar un servidor o un dominio en especial para que no reciba informacin sobre mi sistema o mis hbitos de navegacin. Para mantener una sesin a lo largo de varias pginas se puede guardar la informacin del usuario en un archivo o base de datos con un programa CGI y mantener en el cliente la llave de acceso. De este modo cuando llega un requerimiento al servidor de un documento, este recibe la informacin de la llave del cliente y puede localizar la informacin pertinente del usuario. 1.6 PLUG-IN En enero de 1996 Netscape present con la versin de pruebas Beta del programa Navegador 2.0 una interfaz de programacin para el desarrollo de programas de presentacin de documentos que pudiesen ser invocados automticamente por el navegador, el API Plug-in. Esta interfaz de programacin permite extender las capacidades de presentacin de documentos para cobijar tipos de documento no contemplados directamente en el navegador o mejorar el soporte a los actuales por medio de mdulos que se integran con el programa visor. Este API fue ampliamente aceptado y muchas compaas crearon Plug-ins para que el navegador de Netscape soportara los tipos de documentos propietarios. Actualmente el explorador de Internet de Microsoft tambin soporta el API Plug-in. 1.7 JAVA Java es un lenguaje de programacin y ambiente de ejecucin desarrollado por Sun. Actualmente es uno de los mecanismos ms importantes para el desarrollo de aplicaciones complejas sobre Internet y existe un desarrollo continuo para mejorar el lenguaje y su implementacin y aadirle nuevas capacidades que faciliten su aplicacin en multitud de campos.

Para utilizar cdigo Java se coloca una referencia al archivo que lo contiene por medio de marcas <APPLET> </APPLET> de manera que es un objeto ms que es transportado a la computadora cliente con los dems objetos incrustados en el documento HTML. Una vez en el cliente pueden ser ejecutados inmediatamente o ser invocados en respuesta a eventos. El visor debe tener una implementacin de la JVM (Java Virtual Machine) para que el cdigo sea ejecutado. Java tiene una serie de propiedades que lo hacen ideal para el desarrollo de aplicaciones en los clientes de Web: Es un lenguaje de programacin completo. A diferencia de los lenguajes de script, Java tiene funcionalidad completa. Est orientado a objetos. No slo usa objetos existentes sino que puede crear nuevos desde cero o a partir de otros objetos por medio del mecanismo de herencia. La sintaxis es similar a la de C++. Al tener sintaxis similar a la de una herramienta ya conocida por muchos programadores es ms sencilla la aceptacin de la herramienta. Es independiente de la plataforma. El sistema est pensado para que los programas y applets se ejecuten sobre una mquina ideal llamada Java Virtual Machine (JVM), por lo tanto el dispositivo que desea ejecutar cdigo debe tener un interpretador que emule a la JVM. El cdigo ejecutable no es cdigo nativo sino un cdigo intermedio llamado bytecode. Por lo tanto este lenguaje se considera pseudocompilado, pues para generar el bytecode se debe compilar lo cual permite realizar diferentes optimizaciones y para ejecutarlo se debe tener un interpretador. El bytecode no est destinado a ser ejecutado nicamente en computadoras, tambin puede ser ejecutado en dispositivos de diferente naturaleza que contengan la JVM implementada en su circuitera. El lenguaje incluye caractersticas de seguridad dentro de su diseo. Elimina problemas de versiones, se pueden desarrollar aplicaciones Java y todos los usuarios tendrn siempre en su visor la ltima versin o la versin ms adecuada para ellos sin problemas de distribucin o instalacin. Como se dice arriba, Java es un lenguaje completo y es usado para ejecutar sobre el cliente cdigo residente en el servidor. Esto representa un problema grave, en principio un programa ejecutable mal intencionado o con defectos de desarrollo puede causar estragos sobre el sistema local. Se debe tener en cuenta que la mayor parte de los usuarios de Internet utilizan sistemas operativos monousuario que no tienen en cuenta medidas de seguridad que permitan defender al sistema o minimizar el posible dao causado. En un sistema operativo multiusuario como Unix que debe hacer frente a la posibilidad de ser usado por diversos tipos de usuario se puede ejecutar el programa visor con permisos mnimos de manera que un programa mal intencionado no pueda realizar mucho dao. Dado que este no es el caso comn, el equipo de diseo de Java ha implantado mecanismos de seguridad tanto en el diseo del lenguaje como en la implementacin de la JVM y del compilador. Las principales medidas de seguridad implantadas en Java son: No se permiten apuntadores o asignacin de memoria en tiempo de ejecucin. Una de las grandes fuentes de errores en programas elaborados en C++ son los apuntadores a memoria mal utilizados que dejan al programa en un estado inconsistente con consecuencias imprevisibles. Por ello Java no permite el uso libre de apuntadores y la asignacin de memoria la realiza la JVM. Verificacin de lmites en los objetos de manera que no se pueda asignar valores equivocados en posiciones de memoria por fuera del rango especificado. Uno de los problemas comunes en programas en C++ son los arreglos de caracteres a los cuales se les asigna una cadena ms larga de lo especificado, por lo tanto se asignan caracteres a zonas de memoria reservada para otros valores cayendo en un estado inconsistente. Este error de programacin puede ser utilizado por un intruso para obtener acceso remoto al sistema y poder ejecutar comandos del sistema operativo sin control de seguridad.

La clusula Finally se puede utilizar para indicar que un mtodo de una clase es la versin final y que no se puede modificar su comportamiento por medio de herencia. De esta manera cuando un mtodo realiza una actividad que puede afectar la seguridad se le marca como Finally de manera que un programador malicioso no intente crear una nueva clase a partir de la clase que contiene el mtodo en cuestin y lo modifique para causar dao. La JVM tiene un verificador de cdigo que comprueba que el bytecode que va a ser interpretado sea cdigo Java apropiado. Para ello se usa un algoritmo basado en un solucionador automtico de ecuaciones. La JVM hace diferencia entre el conjunto de clases que se instalan con el programa visor (clases del sistema que se encuentran en el directorio especificado en CLASSPATH) y las clases que son obtenidas a travs de la red. Se supone que las clases que han sido adquiridas con el visor son desarrolladas o por lo menos avaladas por la firma que vende el visor, por lo tanto son confiables y se les permite un acceso mayor a los recursos del sistema. En cambio las clases que llegan por la red no tienen en principio ninguna confiabilidad y son manejadas en forma ms restringida. Adems de verificar el cdigo antes de su ejecucin, la JVM implementa una Sandbox en la cual se ejecutan los applets Java. Es decir un applet se ejecuta en un ambiente controlado y restringido de manera que no pueda influir negativamente sobre el sistema que lo contiene. Algunas de estas restricciones son no tener acceso a los medios de almacenamiento magntico, no poder hacer conexiones de red con un servidor diferente del que lo origin. Java ofrece APIs para diferentes reas como multimedia o reconocimiento de voz, Tambin ofrece un API de seguridad que permite el acceso a diferentes mtodos de cifrado, firma digital, etc. y un API para comercio electrnico que ofrece los mecanismos para desarrollar transacciones seguras.

En este punto se puede afirmar que la idea base de la seguridad en Java es, ejecutar aplicaciones no confiables en un ambiente confiable. No se puede asumir nada acerca de la confiabilidad de las aplicaciones que llegan a travs de la red, por lo tanto se desarrollan una serie de mecanismos tecnolgicos para proteger al sistema de programas mal intencionados o con errores. Sin embargo la Sandbox puede ser demasiado restrictiva para algunas aplicaciones, por lo tanto se ha buscado un mtodo para proporcionar mayor libertad a las aplicaciones Java. Por ello Sun ha desarrollado mecanismos que permiten al visor recibir clases Java firmadas digitalmente por la entidad que las creo o por entidades que la respaldan. Una entidad verificadora confirma o niega la autenticidad de esa firma y el usuario puede decidir si confa en las entidades firmantes y si permite que se ejecute la aplicacin. La confiabilidad de estas entidades se traslada a la aplicacin y por lo tanto se le proporciona mayor libertad para actuar sobre el sistema. 1.8 ACTIVEX ActiveX es un mecanismo desarrollado por Microsoft para ejecutar en el visor aplicaciones residentes en el cliente de Web. Actualmente slo el Explorador de Internet de Microsoft proporciona soporte para esta tecnologa. ActiveX est basado en un API que sirve para que una aplicacin que cumpla esta especificacin se pueda relacionar con el visor y un mecanismo para transmitir e instalar estos componentes. Aunque existe una visin comercial de AcitveX como una alternativa a Java, tecnolgicamente est mucho ms cerca de los Plug-In de Netscape. En este caso las aplicaciones se compilan a cdigo nativo para sistema operativo Windows 95 o superior, de manera que no tiene las propiedades multiplataforma de Java. Un aspecto a tener en cuenta es que existen versiones Windows NT para procesadores diferentes del Intel del PC comn y adems Microsoft est desarrollando una versin de su Explorador de Internet para Unix y es de esperarse que la plataforma NT y el Explorador de Internet soporte la tecnologa ActiveX, por lo tanto el mecanismo de obtencin de componentes ActiveX debe estar preparado para seleccionar la versin apropiada para la plataforma. Esta puede ser una desventaja pues si se desea crear una aplicacin multiplataforma se deben crear varias versiones del mismo componente complicando el proceso de desarrollo y mantenimiento de software (un campo en el

que Java es muy fuerte). Por otro lado no existe una herramienta determinada para crear aplicaciones ActiveX, diferentes lenguajes se utilizan para crear componentes Activex, por ejemplo C, C++, Visual Basic, Pascal, Delphi e incluso el mismo Java. Por lo tanto no hay que aprender un nuevo lenguaje para crear componentes ActiveX facilitando la adopcin de esta norma por parte de la comunidad de programadores. Al igual que en Java la seguridad es un asunto importante dentro del diseo de la tecnologa. Dado que los programas se ejecutan en cdigo nativo no existe una Sandbox que proteja al sistema de los efectos de un programa mal intencionado, que contenga errores de programacin o que produzca conflictos con otras aplicaciones o con configuraciones especficas del sistema operativo. El concepto bsico de seguridad en ActiveX es ejecutar aplicaciones confiables en un medio no confiable, es decir, no existe un mecanismo que provea un ambiente de ejecucin seguro, a cambio se crea un mecanismo para asegurar razonablemente que las aplicaciones que se obtienen a travs de la red son seguras y confiables. La idea principal es que una aplicacin es tan confiable como la empresa que la crea y/o respalda, por lo tanto se crea un mecanismo para que las empresas puedan firmar digitalmente los componentes que ofrecen a travs de la red, cuando el visor recibe un componente puede verificar la autenticidad de la firma por medio de una entidad verificadora (Verisign, Twathe, etc.). Si la configuracin del visor indica que la compaa que respalda el software siempre es confiable el componente se instalar automticamente, en otro caso el sistema presenta una ventana con la informacin relevante del componente y de la entidad que lo respalda para que el usuario pueda decidir si permite instalar el componente o no.

2 RIESGOS DE SEGURIDAD EN EL SERVICIO WWW

2.1 EL SERVICIO WWW CADA VEZ ES MS SENSIBLE A LA SEGURIDAD El servicio WWW de Internet es cada vez ms popular. La sencillez de uso, su capacidad de presentacin multimedia de mltiples tipos de documentos, la posibilidad de comunicarse con cualquier lugar del mundo hace que la World Wide Web sea un mecanismo de comunicacin flexible, potente, econmico y atractivo. Las empresas encuentran en la WWW un nuevo mecanismo para llegar a sus clientes. Estn surgiendo nuevas formas de mercadeo y prestacin de servicios para aprovechar al mximo toda la capacidad de la Web. Conceptos como Virtual Mall o Home Banking comienzan a hacerse comunes. El pie de pgina de las propagandas suele incluir la direccin URL para llegar a la pgina Web de la empresa. Los noticieros de televisin, los peridicos, las universidades, los partidos polticos y muchas otras organizaciones permiten acceso a su informacin a travs de pginas Web. Sin embargo, este boom de Internet en general y del servicio WWW en particular presenta problemas. Cada vez se maneja ms informacin sensible sobre el servicio de Web como nmeros de documentos de identificacin, de tarjetas de crdito, cuentas corrientes, etc. La Web es un objetivo interesante para todo tipo de personas mal intencionadas ya sea para obtener dinero, informacin o simplemente causar daos en forma anloga a como lo hacen los creadores de virus. Algunos datos nos pueden dar una visin ms clara del estado de la seguridad en Internet: Segn el Computer Industry Almanac (www.c-i-a.com) Internet tiene actualmente 148 millones de usuarios y para finales del ao 2000 sern 320 millones. De las contaminaciones por virus, se calcula que el 20% llegan a travs de Internet y de estas el 30% resultan en prdida de datos. 70% de las corporaciones en E.E.U.U. protegen sus redes internas por medio de firewalls, 60% usan mecanismos de clave de acceso y programas antivirus y 15% usan sistemas de cifrado para proteger informacin. Sin embargo el 20% sufren brechas de seguridad a travs de Internet (Ernst & Young, 1996). El 41% de las corporaciones permiten a sus empleados navegar en el World Wide Web y tienen acceso a bases de datos de la compaa. Sin embargo, slo el 53% de estas compaas tienen polticas de seguridad para el uso de estos servicios (estudios FBI/CSI y CDI de 1996). Se calcula que en Estados Unidos se pierden anualmente US$ 9.500.000.000 a travs de Internet por operaciones fraudulentas y brechas de seguridad. Segn [QUI98] Se calcula que a finales de 1998 un 43% de quienes usaban computadoras en E.E.U.U. hicieron parte de sus compras navideas por medio de mecanismos de comercio electrnico mientras que en 1997 slo fue un 10%. Los analistas calcularon las ventas a travs de Internet en US$ 2.300.000.000. 2.2. QU ES SEGURIDAD EN EL SERVICIO WWW? Para poder hablar de seguridad en la Web, primero debemos definir que se considera seguridad y que porcin de ella se va a estudiar en este trabajo. Una primera nocin proporcionada por [GAR97] es: Una computadora es segura si se puede confiar en que ella y el software que contiene se comportar como se espera. Por lo tanto un fallo de seguridad consiste en los eventos que producen comportamientos indeseables y no previstos. Esta definicin puede parecer muy general, pero es necesaria para agrupar todos los eventos que pueden afectar al correcto aprovechamiento de los recursos ofrecidos por el servicio World Wide Web. Adems incluye un concepto muy importante; la seguridad tiene que ver con las expectativas del usuario o del administrador. Para analizar la seguridad del servicio WWW se puede separar en tres componentes principales con caractersticas propias bien definidas: El servidor de Web. En general el servidor es la presa ms apetecible del sistema pues es un punto donde se almacena gran cantidad de informacin y que presta servicios, es decir

presenta puntos de acceso a la informacin y/o recursos que contiene. Por lo tanto es un objetivo importante dado que las brechas de seguridad que puedan existir pueden ser utilizadas para acceder a recursos o informacin importante y que en muchos casos tiene gran valor econmico. La conexin. El servicio Web es soportado por el conjunto de protocolos TCP/IP y por la red Internet, por lo tanto esta sujeto a los peligros comunes a todos los servicios que se basan en estos protocolos como sniffing (espionaje de los paquetes que se transmiten sobre la red), DNS spoofing (engaar a una de las partes sobre la identidad de una mquina para hacerse pasar por alguna entidad confiable), ataques de negacin de servicio como SYN flooding o smurfing (Diferentes formas de manipular paquetes en una red para agotar el ancho de banda o dejar los programas que soportan los protocolos en un estado errneo e inconveniente), etc. El cliente de Web. Los clientes tradicionalmente son ms difciles de atacar pues son entes pasivos, no responden a requerimientos del exterior sino que ellos hacen requerimientos a los servidores. Por lo tanto no se suele considerar al cliente como un punto de acceso a informacin o recursos. Sin embargo, el cliente de Web ya no es un elemento pasivo. La flexibilidad y potencia del programa visor se ha logrado aadiendo nuevas caractersticas y capacidades a un cliente que se ejecuta sobre mquinas cada vez ms potentes, de manera que l tambin pueda responder a requerimientos de los servidores y se puedan realizar procesos sobre l, liberando al servidor de parte de la carga. El cliente de Web si es un punto de entrada al equipo del usuario. Esta situacin se ve agravada por el hecho de que frecuentemente el cliente de Web esta a cargo de un usuario no experto y que por lo tanto no cuenta con el bagaje necesario para tomar decisiones de seguridad adecuadas.

Existen una serie de esfuerzos y metodologas tendientes a aumentar los niveles de seguridad en la Web por medio de mecanismos de transacciones seguras, canales SSL y SHTTP y servidores seguros de WWW. Es notorio que el enfoque de seguridad se hace principalmente sobre el servidor y la conexin. Despus de todo, la investigacin de cierta magnitud necesita patrocinio y las empresas grandes que pueden disponer fondos para tal fin estn del lado del servidor. Este trabajo va a tratar sobre la problemtica de seguridad en el cliente por dos razones. La primera es que, como ya se dijo, existen desarrollos y estudios intensivos en el intento de asegurar los dos primeros componentes del servicio Web. La segunda es que la informacin pertinente a seguridad en el lado del cliente de Web es escasa y aparece fragmentada, desperdigada y frecuentemente est destinada a usuarios con conocimiento de los protocolos y mecanismos que soportan el servicio y por lo tanto los usuarios no expertos (la gran mayora) no pueden utilizar efectivamente esta informacin. Existen aspectos caractersticos del servicio WWW y del uso del visor que se deben tener en cuenta a la hora de estudiar la seguridad en la Web. Por ejemplo, el hecho de que el usuario deba navegar explcitamente hacia la pgina Web que desea ver proporciona un cierto sentimiento de seguridad. Despus de todo nada garantiza a un posible atacante que crea una pgina con contenido hostil que un usuario especfico va a visitar su pgina y por lo tanto es poco probable que alguien pueda dirigir un ataque contra un usuario o una mquina especfica desde un servidor de Web. Este sentimiento de seguridad puede ser una fuente de dolores de cabeza. Existen muchas formas de sacar provecho de la intromisin en sistemas ajenos sin necesidad de que el ataque sea dirigido contra alguien en especial. Por otro lado, los autodenominados hackers han demostrado un gran altruismo a la hora de convertir la red en un lugar menos seguro, llegando a crear asociaciones para tal fin como el Chaos Computer Club y otras. No importa cuales son sus motivaciones (verificar la seguridad de la red para fortalecerla, diversin, probar sus propias habilidades, protestar contra el sistema, anarqua u obtener dinero), existen y hacen dao. Algunos medios de difusin (revistas, peridicos, e-zines) intentan advertir sobre los problemas en la Web pero los temas suelen ser tratados superficialmente y sin suficiente investigacin lo cual genera confusin e ideas erradas acerca de la situacin de seguridad de la Web. Frecuentemente los temas son tratados por periodistas que conocen superficialmente el manejo del cliente Web y nada sobre los mecanismos que soportan el servicio WWW, por lo tanto el

resultado son reportes alarmistas que no aportan mucho a la solucin y s confunden a los usuarios. No hay una conciencia clara sobre el estado actual de seguridad en Internet. Por un lado est el comprador que no se preocupa por las implicaciones de enviar su informacin de tarjeta de crdito a travs de la red; por otro, el usuario que no se atreve a llenar un formato cualquiera por miedo a revelar informacin inconveniente. Ni siquiera existe consenso entre las personas que conocen la industria a fondo y adoptan posiciones diametralmente opuestas que parecen basarse ms en los intereses de sus respectivas industrias que en un estudio serio del tema. Segn Jim Clark, presidente de Netscape, ... hay un problema de cultura tecnolgica. Mucha gente sigue teniendo miedo a usar su tarjeta de crdito en Internet; sin embargo, se la deja a cualquier camarero sin ningn reparo. Cuando los bancos empiecen a popularizar el uso de Internet para sus transacciones, nos daremos cuenta que es algo tan seguro como firmar una chequera. Por otro lado, Mark D. Rash, director de leyes sobre seguridad informtica de Science Applications International Corp. afirma que Las malas noticias son que nadie tomar en serio el cibercrimen hasta que ocurra una catstrofe global seria. Las buenas noticias son que ocurrir una catstrofe global seria. Como se dijo anteriormente, este trabajo hace nfasis sobre la seguridad en el lado del cliente por ser el ms descuidado o sobre el que menos trabajos formales existen. Sin embargo, se debe tener en cuenta que la seguridad en el Servidor WWW y sobre la conexin influyen definitivamente en la seguridad del cliente de Web. Por ejemplo, si un servidor Web pertenece a una organizacin plenamente confiable pero puede ser penetrado y modificado fcilmente, el usuario que accede a los servicios de dicho servidor no puede confiar en l. Teniendo en cuenta que muchos aspectos de seguridad se basan en distinguir entre entidades confiables, los problemas de seguridad de un servidor se trasladan a los clientes de Web. La seguridad en la Web no depende del nivel de seguridad en uno slo de los componentes, sino de una toma de conciencia general que permita aprovechar los mecanismos tecnolgicos existentes para alcanzar niveles de seguridad apropiados para las distintas actividades que se desarrollan sobre la red. Por lo tanto se delinearan los problemas y los mecanismos de seguridad existentes tanto para servidores Web como para la conexin antes de pasar al plato fuerte de este trabajo, el agente de usuario o visor de World Wide Web. 2.3 SEGURIDAD EN EL SERVIDOR WWW El servidor Web es el contenedor de la informacin y las aplicaciones que se comparten (publican) por medio de WWW, para muchas compaas que hacen uso de este medio con fines de publicidad y divulgacin parte de su imagen recae sobre su presencia en la Web, otras hacen uso efectivo de este mecanismo para desarrollar las actividades que son propias de la naturaleza del negocio, por lo tanto es importante que el servidor WWW y los recursos que contiene estn protegidos. Sin embargo el servidor WWW es uno de los puntos ms vulnerables en una red empresarial. Dado que presta servicios al exterior, presenta puntos de acceso donde un intruso puede aprovechar propiedades del software o defectos de los programas o del sistema operativo que lo soporta para poder penetrar subrepticiamente en el sistema y lograr aduearse de los recursos o la informacin de una red empresarial. Por esta razn el servidor Web y otros servidores que prestan servicios Internet deben estar separados de la red interna de una organizacin y conforman la periferia de la Intranet, una especie de zona aislada que se debe considerar especialmente peligrosas y que por lo tanto no deben contener recursos que sean vitales para la organizacin. Sin embargo el riesgo est siempre presente, si un intruso penetra un servidor Web, puede colocar informacin en l que afecte a la imagen de la compaa o colocar cdigo hostil que ser aceptado pues proviene de una compaa confiable y que cause dao al sistema del usuario. No hacer uso de Internet y de World Wide Web no es una opcin viable y ya existen organizaciones y negocios que basan toda su actividad en el servicio WWW. Por lo tanto, la seguridad en el servidor es un aspecto crtico en el estudio de la seguridad en Internet. Segn [STE98] existen los siguientes riesgos en el servidor cuando es penetrado por un intruso: Robo de documentos confidenciales. Ejecucin de comandos en la mquina que alberga al programa servidor, permitiendo modificar el sistema.

Obtencin de informacin sobre la mquina que albergue al programa servidor que permitir posteriormente penetrar en el sistema. Ataques de negacin de servicio dejando la mquina temporalmente inutilizada.

Estos peligros estn basados claramente en los riesgos clsicos de un servidor Internet y hacen referencia a la informacin y recursos del computador que alberga al servidor, sin embargo las caractersticas de un servidor Web abren las puertas a nuevos riesgos como: Modificar cdigo correspondiente a programas CGI, Server Side Includes u otros mecanismos para ejecutar aplicaciones en el servidor a peticin del cliente de manera que desarrollen acciones diferentes de aquellas para los que fueron diseados y que pueden ser inconvenientes para la organizacin y/o para el usuario. Es decir, se puede presentar una novedosa forma de crear programas estilo caballo de Troya, Bombas, etc. que atacan sistemas remotos gracias al servicio WWW. Alterar la informacin presentada en el servidor de manera que afecte negativamente la imagen de la empresa y de las actividades que desarrolla en la red. Una pequea alteracin en los precios de un catlogo presentado en la Web (por ejemplo un cero de ms en todos los precios) puede ser difcil de detectar por los administradores del sistema y causar que una gran cantidad de clientes opten por productos de la competencia. Existen multitud de programas CGI, applets Java o controles ActiveX que se ofrecen comercialmente para extender la funcionalidad de los servidores Web. La calidad de muchos de estos programas es discutible y en algunos se han descubierto errores de diseo o de programacin con efectos que van desde mostrar porciones de informacin que debera estar protegida hasta permitir ejecutar comandos en el sistema Se pueden implementar una serie de medidas para asegurar un servidor Web o minimizar el alcance de una posible intrusin, estas medidas se pueden tomar en dos niveles, administracin de la mquina y el sistema operativo que albergan al servidor y administracin del servidor mismo. 2.3.1 Medidas a tomar sobre el sistema operativo Seleccionar con cuidado el sistema operativo. Cuanto ms abierto es un sistema operativo (Unix es un ejemplo de sistema abierto) ms propenso a intrusiones es. Por otro lado es imprescindible que el sistema operativo tenga mecanismos bsicos de seguridad como bitcoras, administracin de cuentas de usuario, control de acceso, etc. Limitar el nmero de cuentas activas. Cada cuenta es un punto de entrada al servidor, por lo tanto deben existir nicamente las cuentas estrictamente necesarias. La cuenta guest o cuentas de acceso annimo deben estar prohibidas en servidores que contienen informacin confidencial. Las cuentas de empleados que se retiran de la organizacin o de personal que ya no tiene una necesidad clara para el uso del servidor deben ser eliminadas. Cuanto menor sea el nmero de cuentas ms fcil resultar controlarlas y hacer seguimiento. Control estricto de permisos en directorios y archivos. Adems de restringir el nmero de cuentas, se debe proporcionar a cada usuario la mnima capacidad de acceso que le permita desarrollar sus actividades. De esta manera se limita la capacidad de dao que un hacker pueda hacer si penetra una cuenta de un usuario. Buena administracin de claves de acceso. Esta es una medida comn en el rea de seguridad. Una de las grandes fuentes de intrusin son las cuentas conocidas como jones, es decir, cuentas cuya clave de acceso es el mismo nombre de la cuenta. Existen diferentes mecanismos para obligar a mantener un buen sistema de claves (por ejemplo, el sistema puede exigir cambio de claves cada cierto tiempo, slo admitir claves con un mnimo de dgitos y que incluyan nmeros y letras, etc.) y algunos autores recomiendan usar un programa de rompimiento de claves para poder verificar la seguridad de las claves utilizadas. Eliminar servicios innecesarios. El sistema operativo puede tener en ejecucin varios servidores que ofrezcan diferentes servicios (Web, Mail, FTP, Chat, etc.), cuantos ms servicios existan ms puertas de acceso habr para posibles intrusos. Aquellos que no se

utilicen se deben desactivar de manera que la complejidad de la administracin de la seguridad del servidor disminuya y por lo tanto sea ms eficiente. Tambin se debe tener en cuenta que para organizaciones en las cuales la seguridad es vital se puede considerar tener cada servicio en una mquina diferente y configurar el sistema operativo para cubrir las necesidades especificas de cada servicio. Eliminar shells e interpretes no indispensables. De esta manera se ofrecen menos mecanismos para hacer dao a un intruso que ha penetrado el sistema. Control estricto de bitcoras. Esto significa que el sistema debe estar en capacidad de registro u auditora. El registro tiene que ver con la verificacin de identidad de los usuarios y mantenimiento de los archivos de bitcora. Los archivos de bitcora (log) pueden ser muy tiles para detectar situaciones anmalas pero deben ser revisados peridicamente. Dado que esta tarea puede ser muy tediosa, se pueden usar herramientas que filtran la informacin de manera que slo aparezcan los datos relevantes o herramientas de anlisis que pueden destacar los hechos importantes o las variaciones anormales en el transcurso de la actividad del servidor. Como afirma [RUB97], la auditora es mejor cuanto ms automatizada est y presenta algunos paquetes comerciales de auditora comerciales (Secure-Max de Open Vision, http://www.ov.com y OmniGuard de Axent, http://www.axent.com) y de libre uso o freeware (COPS de Faniel Farmer y Eugene Spafford, ftp://info.cert.org/pub/tools/cops ; TAMU de David Safford, Douglas Schales y David Hess, ftp://net.tamu.edu/pub /security/TAMU y Tripwire de Gene Kim y Eugene Spafford, ftp://info.cert.org/pub/tools/tripwire. El uso de copias de seguridad es la primera medida para recuperarse cuando ha ocurrido una intrusin. Esta es una medida bsica para cualquier sistema que necesite mantener un nivel mnimo de seguridad. Si se trata de un servicio para una red interna se debe colocar el servidor WWW detrs del firewall corporativo para que no se pueda alcanzar desde el exterior. Si se van a ofrecer servicios al pblico en general, se deben dejar abiertas las puertas para el acceso al servidor, por lo tanto lo mejor es dejarlo completamente afuera de manera que no se pueda romper la seguridad de toda la red corporativa a travs del servidor de Web.

2.3.2 Medidas a tomar sobre el servidor Web Se debe seleccionar el programa servidor de Web cuidadosamente, verificando que no tiene agujeros de seguridad conocidos y revisando el conjunto de opciones de administracin que presenta para ver si se ajusta a las medidas que se han decidido tomar. Es normal que la informacin presentada por el servidor WWW sea elaborada por un grupo especfico de personas. Resulta importante definir un grupo de usuarios con permisos especficos para las tareas de publicacin de documentos. En caso que se considere importante separar las tareas puede haber distintos grupos de acuerdo a la naturaleza de la informacin presentada (documentos HTML, CGI, JAVA, etc.) de esta manera si un intruso penetra alguna cuenta slo podr modificar una porcin del sistema. Sin embargo se debe tener en cuenta que a mayor nmero de grupos ms compleja es la administracin y la complejidad es causa de errores u omisiones. Algunos servidores permiten publicar documentos a todos o gran parte de sus usuarios desde cualquier directorio reconocindolos por su extensin html para documentos o cgi, bin, pl u otros para programas CGI. Esto no debe ser permitido, pues controlar ese esquema es muy complicado para el administrador y por lo tanto no se puede asegurar que el contenido existente sea confiable y seguro. Los documentos que se publican deben estar en una rama de subdirectorios predefinida de manera que se puedan controlar permisos y contenidos. El programa servidor de Web (y cualquier servidor) debe ser ejecutado con un mnimo de permisos, si bien es cierto que un programa que desea abrir puertos de servicios estndar debe ser ejecutado con permisos de superusuario se puede configurar para que atienda los requerimientos bajo permisos de un usuario normal. De esta manera un intruso que pretenda aprovecharse de algn defecto en el cdigo para realizar daos encontrar lmites a su

actividad. Ejecutarlo con permisos nulos como usuario nobody no es una solucin, porque entonces cualquier usuario tendr acceso a los archivos que puede leer y escribir el servidor, entre ellos al de configuracin, por lo tanto la configuracin del servidor queda abierta a modificacin por cualquiera (incluso un usuario annimo o guest). Resulta conveniente crear un usuario especfico para la ejecucin del programa servidor, con permisos limitados a los necesarios para el buen funcionamiento del servicio WWW. Ejecutar el servidor en un ambiente chrooted. Este termino proviene de una instruccin Unix llamada chroot que permite limitar la visin que tiene un programa del conjunto de directorios indicando que considere como raz del rbol de directorios a algn subdirectorio. De esta manera, si algn atacante logra penetrar el servidor de Web, ya sea aprovechando un error en el programa o una configuracin incorrecta, el dao que podr causar ser limitado. No compartir el rbol de directorios de FTP que permite conexiones annimas, es decir, conexiones en las cuales no se verifica la identidad pues se corre el riesgo de que personas desconocidas enven documentos mal intencionados que despus son mostrados a travs de WWW. Desactivar caractersticas innecesarias del servidor de Web. Los servidores Web son cada vez ms complejos, esto lleva a que puedan ocurrir errores en el programa o que varias caractersticas del servidor que por separado son inocuas se puedan utilizar en conjunto para violar la seguridad en el sistema. Por lo tanto se recomienda tener activados solamente los servicios mnimos necesarios. Por otro lado existen algunos servicios que en s mismos presentan riesgos. Algunos servidores estn en capacidad de aceptar como URL un directorio cuyo contenido envan al visor, esto puede servir para que un atacante conozca detalles del sistema que le permitan planear un ataque posteriormente, por lo tanto esta caracterstica debe ser desactivada. El uso de links simblicos (terminologa Unix) o accesos directos (terminologa Windows) permite escapar del ambiente chrooted y por lo tanto puede dejar expuesta porciones del rbol de directorios que contengan informacin importante y que deba ser protegida, por ello conviene configurar al servidor para que no soporte este modo de acceso a archivos. Las opciones de ejecucin de programas en el servidor a peticin del cliente (CGI, Server Side Includes, Servlets y otras) son una fuente de agujeros de seguridad y deben estar desactivadas en caso de que no se haga uso de ellas.

2.3.3 Problemas de seguridad en el servidor por programas CGI Common Gateway Interface es un protocolo que permite ejecutar programas a peticin del usuario (probablemente a travs de una forma HTML o de un applet Java). El protocolo especifica el modo de pasar parmetros al programa y la forma de devolver la respuesta en formato HTML para que el visor presente al usuario el resultado del proceso. CGI es uno de los primeros esfuerzos desarrollados para proporcionar documentos dinmicos e interactivos. Los programas o guiones de comando CGI frecuentemente se elaboran sobre lenguajes interpretados como Perl, Tcl o Python y hay una gran cantidad desarrollados en C. Sin embargo ejecutar un programa interpretado significa en realidad ejecutar dos programas: el CGI y el interpretador. El interpretador suele ser un programa grande y complejo; por lo tanto, susceptible de contener errores que puedan ser aprovechados por un intruso. Por otro lado, los programas en lenguajes interpretados suelen estar en archivos de texto llano; por lo tanto, existe la posibilidad de que un intruso pueda llegar al cdigo, modificarlo y despus dejar que cause dao sin su intervencin directa. No se debe olvidar que los lenguajes interpretados pueden tener ventajas como menos lneas de cdigo, son ms fciles de entender y algunos estn especialmente adaptados al trabajo de script. Una posibilidad intermedia es usar extensiones de estos lenguajes que contienen medidas de seguridad como safePerl. Generalmente el cdigo CGI es ejecutado con la misma prioridad que el servidor Web. Si el cdigo CGI tiene un agujero de seguridad tendr tanto acceso al sistema como el servidor. Un aspecto importante es el control de los parmetros de entrada. Por ejemplo, un lenguaje como C no controla los lmites de los arreglos de caracteres. Por lo tanto, si se envan cadenas suficientemente largas a un programa CGI desarrollado en C, se sobreescribirn posiciones de

memoria de manera inesperada dejando al programa en un estado inconveniente que puede bloquear el programa o permitir que se ejecuten comandos del sistema en el servidor. Por otro lado, algunos lenguajes interpretados tienen la capacidad de invocar comandos del sistema y programas. En algunos casos se pueden enviar parmetros que intenten dar al CGI un uso distinto del que tiene originalmente. Por ejemplo en Perl se puede ejecutar el siguiente script: System(/usr/lib/sendmail t $direccion < $Archivo) Y se crea una forma que contiene la siguiente informacin: <INPUT TYPE=hidden NAME=direccion VALUE=yo@mi.servidor.mail> <INPUT TYPE=text NAME=archivo> El programa est destinado a enviar archivos al creador de la pgina y funciona correctamente, pero un atacante puede mirar el cdigo fuente de la pgina HTML y crear otra con una forma similar pero que contenga la siguiente informacin: <INPUT TYPE=hidden NAME=direccion VALUE=atacante@otro.servidor.mail> <INPUT TYPE=hidden NAME=archivo VALUE=/etc/passwd.txt > y utiliza el CGI para hacerse con una copia del archivo de claves de acceso la cual utilizar para penetrar el sistema. Existen multitud de programas y scripts CGI ofrecidos en la red comercialmente o de uso libre. Se debe tener mucho cuidado si se desea utilizar uno de estos cdigos pues un error de programacin o un diseo mal intencionado puede causar problemas graves en el servidor y a la organizacin que est detrs de el. Algunas medidas que se deben tomar con los programas CGI son: Se deben utilizar programas CGI confiables, para ello se debe probar el programa previamente a su publicacin e incluso se debe llegar a revisar el cdigo (operacin larga y tediosa) para asegurar que no es un caballo de Troya. Se pueden utilizar lenguajes que incluyen caractersticas de seguridad o a salvo de errores como safe Tcl o Java. Debe existir un directorio para scripts CGI (tradicionalmente cgi-bin) donde se puede controlar fcilmente cuantos CGI hay, quien los publica, cuando se modificaron por ltima vez, etc. De esta manera se puede detectar si un intruso plant otro programa o modifico alguno existente para sacar provecho. Adems se puede tener un control ms estricto sobre que usuarios tienen permisos para instalar programas CGI. 2.3.4 Problemas de seguridad en el servidor por Server Side Includes Server Side Includes es un mecanismo que permite insertar la salida de comandos del sistema o programas en la corriente de salida del servidor que es enviada al visor. Un documento HTML debe contener marcas SSI y en el visor aparecen los resultados del proceso reemplazando las marcas SSI. Las marcas constituyen una extensin a HTML (misma sintaxis) y tiene los siguientes comandos: ECHO Proporciona informacin del documento que se est presentando. Tienen los siguientes parmetros: $DOCUMENT_NAME Inserta el nombre del documento $DOCUMENT_PATH Inserta la posicin del documento en el rbol de directorios. $DATE_LOCAL Inserta la fecha y hora del servidor. $DATE_GMT Inserta la fecha y hora de Greenwich. $LAST_MODIFIED Ultima modificacin al documento. INCLUDE Incluye el contenido del archivo del cual se da su posicin en modo virtual (relativo a la raz de directorios) o file (relativo a la posicin del documento). FSIZE Proporciona el tamao en bytes del archivo especificado. FLASTMOD Proporciona la fecha y hora de la ltima actualizacin del archivo indicado. CONFIG Permite configurar como se comportar el servidor al ejecutar las diferentes marcas. Por ejemplo se puede indicar cual es el mensaje general

EXEC

de error, indicar el formato de fecha o si el tamao de los archivos se mostrar exacto o redondeado. Tiene dos modos: Cgi Permite insertar la salida de un programa CGI. Cmd Permite insertar la salida de un comando del sistema.

Se debe tener especial cuidado con el ltimo comando SSI, EXEC. Este es el que proporciona mayor flexibilidad a SSI pero tambin ofrece la posible aparicin de agujeros de seguridad. Por un lado, permite la ejecucin de programas CGI y, por consiguiente, se debe tener en cuenta todo lo dicho en 2.1.3. Por otro lado, la posibilidad de ejecutar comandos del sistema es muy peligrosa. Una medida que se puede implantar es deshabilitar el comando EXEC de manera que se puedan utilizar el resto de los comandos. El mayor peligro al ejecutar comandos del sistema es que el sistema puede interpretar metacaracteres que se pueden utilizar para que el SSI haga ms cosas de las esperadas. Por ejemplo se puede presentar un servicio finger de bsqueda de usuarios en la WWW con la siguiente marca: <STRONG>Escriva el nombre de la persona que busca</STRONG> <!-#EXEC CMD=finger $NOMBRE - -> Se espera que en $NOMBRE solo aparezca el nombre de la persona buscada, pero un usuario puede adicionar un ; (que sirve para separar instrucciones) y colocar otra instruccin, por ejemplo la cadena: Pedro ; echo Tu_Estas_muerto | mail jefe@empresa.com.co De esta manera se ejecutan dos comandos, uno busca a Pedro en la red y el otro le enva un mensaje desagradable al jefe del autor de la pgina dejndolo en mala posicin. Si adems el servidor se est ejecutando en modo root el segundo comando podra invocar el borrado de todos los archivos o dar formato al disco u obtener el archivo de claves de acceso as: Maxwell Smart ; cat /etc/passwd | mail hacker@Kaos.org 2.4 SEGURIDAD EN LA CONEXIN Uno de los grandes problemas de Internet es que no existe ningn control que pueda evitar el espionaje en algn punto intermedio entre dos partes que mantienen una conexin. An ms, TCP/IP no tiene medidas efectivas contra la modificacin de la informacin que viaja en la red, as que puede ser modificada en algn punto intermedio falseando la realidad y afectando gravemente el desarrollo de actividades que necesiten altos niveles de seguridad (correo empresarial o diplomtico, transacciones comerciales o bancarias, etc.). Existen dos mecanismos que ayudan a solventar esta situacin cifrado y autenticacin. Por cifrado se entiende el proceso de modificar el contenido de un documento para que no resulte reconocible por una persona a la cual no est destinado. Est implcito que al llegar a su destino debe ocurrir el proceso contrario, descifrado, para que el destinatario pueda tener acceso a la informacin. Existen dos formas de cifrado, simtrico y asimtrico, en el primero ambas partes conocen un secreto (llave) que es utilizado como base para cifrar y descifrar el documento, en el segundo los mecanismos de cifrado y descifrado usan llaves diferentes por lo tanto se puede publicar una de manera que cualquier persona que conozca la llave pblica del destinatario puede cifrar con ella un mensaje y el destinatario (y slo l) puede descifrar su contenido con la llave privada. Dado que Internet es un conjunto de redes y computadoras independientes es frecuente que dos sistemas que no se conocan y por lo tanto no comparten secretos deseen intercambiar informacin en modo seguro, el manejo de cifrado asimtrico proporciona tal comunicacin sin tener que intercambiar previamente un secreto en formato plano que puede ser visto por algn espa con lo cual la situacin resultara ms grave que no usar proceso de cifrado. Ambas partes tomaran una actitud relajada intercambiando informacin sin la prevencin que tendran en una conexin abierta de manera que el posible espa se enterara de muchos ms datos. Se debe tener en cuenta que el cifrado asimtrico es mucho ms costoso en

recursos de mquina que el cifrado simtrico, de manera que se suele utilizar para cifrar llaves que despus sern utilizadas en intercambio de mensajes cifrados con base en algoritmos simtricos. No todas las implementaciones de un mecanismo de cifrado tienen la misma potencia, esto se debe a que los productos de cifrado desarrollados en E.E.U.U. cuentan con fuertes restricciones para la exportacin. Actualmente aparecen dos tipos de producto, para E.E.U.U. con llaves de 128 bits y para el extranjero con llaves de 40 bits. Las llaves de 40 bits no son suficientemente fuertes para las capacidades de computo que se manejan actualmente (grupos de crackers han roto cifrados con llaves de 40 bits en menos de 18 horas) y por lo tanto no se debe confiar secretos vitales a llaves tan dbiles. Por autenticacin se entiende la verificacin del origen y de la integridad de los datos contenidos en el mensaje o en el flujo de bytes. La verificacin del origen del mensaje se puede realizar con base en firmas digitales o con certificados que permitan su verificacin a travs de una entidad certificadora confiable. En general una firma digital por si sola adolece de los mismos problemas de una firma sobre papel. Una firma en un documento de una persona desconocida no hace al documento confiable (no debera). Si encontramos la misma firma en otro documento se puede llegar a la conclusin de que la misma persona los firm pero no que el nombre que aparece sea el correcto. Por lo tanto resultan ms confiables los certificados aunque causan gastos y dependen de una tercera parte que debe ser confiable para las entidades en ambos puntos de la comunicacin. Para verificar la integridad de los datos se puede generar un resumen (Digest) basado en el contenido del mensaje, la firma digital e informacin de fecha principalmente. Un algoritmo de resumen produce una cadena que identifica al documento, el remitente enva ambos componentes, el mensaje y el resumen. Como cada bit en el mensaje influye en cada bit del resumen y el cambio de un bit en alguno de los datos de entrada hace que cada bit en la cadena de salida tenga un 50% de posibilidades de cambiar se puede asumir que si al llegar el mensaje al destinatario y ejecutar el mismo algoritmo de Digest produce el mismo resultado el mensaje no ha sido modificado. En general adems de procesar el mensaje, se incluye la fecha y la firma digital o certificado del remitente, de esta manera se puede comprobar la integridad de la informacin contenido,. Para establecer conexiones seguras ambas partes deben contener el cdigo necesario para soportar los mecanismos de cifrado, existen algunos estndares que son comnmente utilizados, principalmente SSL y S-HTTP. Existen otras propuestas propietarias pero no estn tan extendidas como las dos anteriores, tienen funciones muy especficas o estn todava en fase de desarrollo como Private Communications Technology (PCT) de Microsoft; SET para transacciones electrnicas basadas en tarjeta de crdito propuesto por Visa y MasterCard y apoyado por grandes compaas de la industria como IBM o Microsoft; CyberCash, DigiCash, Cyberbucks y otras propuestas para compras en red; 2.4.1 Secure Sockets Layer Es un protocolo propuesto por Netscape y es candidato ante la IETF como norma para seguridad HTTP. La idea principal de SSL es proporcionar un mecanismo de conexin segura (socket seguro) encima del cual puedan funcionar protocolos de alto nivel como HTTP, NNTP, FTP, etc. SSL tiene capacidad para verificar la identidad del servidor para el cliente, verificar la identidad del cliente para el servidor, cifrado de la informacin en curso (varios mecanismos, especialmente RC4 y DES) y verificacin de la integridad de la informacin. SSL est ampliamente difundido, lo cual es importante para que un esquema de cifrado y autenticacin sea realmente efectivo. Actualmente lo soportan los visores de Netscape, Microsoft y Secure Mosaic entre otros y servidores de Netscape, Microsoft, IBM, Quartedeck, Open Market y O reilly. Una transmisin SSL se desarrolla as: Fase inicial de negociacin (handshake) en el cual ambas partes llegan a un acuerdo en los mecanismos que se van a utilizar para cifrado, autenticacin y verificacin de integridad (generalmente los mecanismos ms fuertes de la interseccin entre el conjunto de mecanismos de ambas partes). Ambas partes pueden intercambiar certificados X.509 para

verificacin de identidad. El cliente y el servidor intercambian un conjunto de secretos (llaves) por medio de cifrado asimtrico. Proceso de comunicacin segura (modo de datos opacos). Fase final de negociacin. Este mecanismo cierra formalmente la conexin de esta forma se evita que una de las partes se quede escuchando y algn intruso trate de suplantar a la que se retir de la comunicacin.

En 1995, la IETF adopt SSL como parte de la norma de Capa de Seguridad de Transporte (TSL por sus siglas en ingls) el cual fue publicado por primera vez en 1997. TSL es muy similar a SSL con diferencias importantes en el uso de algunos algoritmos de resumen y cifrado. 2.4.2 Secure HTTP Es un esquema propuesto por CommerceNet, una coalicin de empresas que buscan utilizar la red para fines comerciales. Tambin es un candidato ante la IETF para convertirse en la norma de seguridad para HTTP. A diferencia de SSL, SHTTP es un protocolo de alto nivel que solo trabaja en el ambiente Web pero es potencialmente ms flexible y extensible que SSL. Se basa en un desarrollo anterior conocido como Private Enhanced Mail (PEM) que incorpora formatos de codificacin para texto y datos binarios adems de tener en cuenta firmas digitales y autenticacin. S-HTTP incluye adems un superconjunto de PEM desarrollado por RSA llamado PKCS-7. S-HTTP esta basado en mensajes, un conjunto de datos es cifrado, se le adicionan las firmas digitales y los cdigos de chequeo (con base en MD5 u otro algoritmo de digest) y es transmitido. El servidor recibe el mensaje y realiza todo el proceso de descifrado, verificacin de integridad, verificacin de identidad y ejecuta la peticin. Los mensajes del servidor al cliente son tratados en forma similar. La verificacin de identidad esta basada en certificados X.509. S-HTTP imita la sintaxis y la semntica de HTTP convirtindose en un superconjunto de HTTP. Los mensajes son encapsulados con cifrado, firma digital y/o verificacin de integridad. La negociacin consiste en encontrar un conjunto de mecanismos comn a ambas puntas de la conexin. Los mecanismos de transferencia de llaves y certificados se hacen a travs de la zona de encabezados HTTP. Las llaves pueden ser inband, outband, Kerberos o RSA entre otras. El formato de la lnea de encabezado es: <atributo de negociacin> = direccin, potencia, valor Por ejemplo: SHTTP-Key = recv, required=RSA, Kerb-5 Los valores de propiedad pueden ser recv u orig; de esta manera se puede definir diferentes mecanismos de cifrado para cada direccin de la conexin. Tambin se puede especificar que la caracterstica es optional, required o refused lo cual da la opcin de especificar la confianza que tienen cada una de las puntas en los diferentes mecanismos de seguridad. Junto con SHTTP existe una extensin de HTML que permite definir y configurar el comportamiento del protocolo a travs de marcas que recuerdan la sintaxis y la semntica de las de HTML y que se conoce como SHTML. Existen atributos de ancla o vnculo como DN (distinguised name), NONCE o CRYPTOPT. Estos atributos proporcionan informacin acerca de las medidas de seguridad esperadas en el documento al cual hace referencia el vnculo. DN permite especificar un identificador nico del documento para un directorio X.500. NONCE va acompaado de una cadena que el servidor debe devolver con el documento, sirve para verificar que la informacin que llega es en realidad una respuesta al requerimiento hecho, se debe recordar que esta informacin viaja cifrada y por lo tanto un intento de suplantar al servidor no contendr dicha cadena. CRYPTOPT permite especificar por adelantado algunas opciones de cifrado para el documento al que hace referencia el hipervnculo. Existe una marca CERTS que proporciona informacin acerca de certificados disponibles. Tambin hay una marca CRYPTOPT (el mismo nombre que uno de los atributos de vnculos) que permite crear un conjunto de opciones de cifrado y darles nombre, de esta manera en el atributo de vnculo se puede utilizar el nombre para hacer referencia al conjunto de opciones.

Esto permite administrar eficientemente diferentes conjuntos de mecanismos de seguridad para manejar niveles de seguridad. Este protocolo no est tan extendido como SSL aunque se considera tan fuerte en seguridad como cualquiera de sus competidores. Est diseado especficamente para el protocolo no orientado a conexin HTTP, sin embargo las necesidades de WWW han cambiado y se necesitan mecanismos orientados a flujos (streams) y bidireccionales como SSL.

3 SEGURIDAD EN EL VISOR
3.1 Tipos de fallas de seguridad en el visor Existen multitud de formas de intromisin en el ambiente de un visor Web, pero el conjunto de efectos logrados en el se puede clasificar para poder analizar la severidad del dao que se puede causar. En cierto modo este captulo resulta ser la base que justifica esta tesis, pues si se llega a la conclusin de que un ataque a un navegador no pasa de ser una molestia menor este trabajo no merecera la atencin ni el tiempo que se le ha dedicado. Sin embargo, se encontr que dependiendo de los diferentes tipos de ataques y de la aplicacin que se le d al ambiente de Web el tema de seguridad es vital. 3.1.1 Informacin del sistema no sensible expuesta OJO qu significa???? El programa visor proporciona al servidor informacin que en principio se considera inofensiva. Esto se realiza de forma automtica y sin permiso o aviso al usuario. Entre est informacin se encuentra: - El archivo histrico de navegacin, es decir el conjunto de vnculos que ha visitado en esa sesin antes de llegar a la pgina actual. - El tipo de cliente est utilizando, marca y versin. - direccin IP. - Sistema operativo. Esta informacin puede resultar til para configurar pginas Web que se adapten al programa cliente, sin embargo varias compaas estn utilizando esta informacin para mantener bases de datos de comportamiento de usuarios de la red para poder hacer anlisis de tipo comercial o crear listas de correo. Esto se considera una clara violacin a la privacidad del usuario. Por otro lado el anlisis de comportamiento del usuario puede ser utilizado como base para intromisiones ms sofisticadas y dainas, por ejemplo al conocer la marca y versin del programa cliente se podrn utilizar agujeros conocidos para lograr hacer dao o robar informacin. 3.1.2 Revelar informacin sensible Algunos clientes de Web pueden ser usados para revelar informacin vital como nombre de usuario, o la clave de acceso al sistema cifrada. Tambin se puede robar informacin crtica si algn script o applet presenta ventanas que simulan formatos de dilogo que solicitan informacin de registro en el sistema o de tarjeta de crdito. Los posibles espas, tanto para este punto como para el anterior, pueden ser los administradores del servidor Web al que se conecta el cliente, el proveedor ISP, los administradores del proxy que se utilice y cualquiera que tenga acceso al medio de transmisin y pueda realizar alguna labor de sniffing. 3.1.3 Bloqueo del programa cliente El bloqueo del visor es una tarea sencilla. Generalmente se realiza a travs de un ciclo infinito dentro del cual se invocan funciones vlidas que no se considera que afecten a la seguridad como abrir otra ventana del visor, escribir una lnea en el documento de Web, etc. Este mecanismo consume tiempo de CPU impidiendo en el mejor de los casos el trabajo normal con el visor y con otros programas. Si las instrucciones dentro del ciclo infinito consumen memoria (abrir una nueva ventana por ejemplo) se puede llegar a copar la memoria del sistema. Este efecto se puede lograr a travs de guiones de comandos (scripts) o aplicaciones ejecutadas en el agente de usuario (Java, ActiveX, Plug-In). En el caso de un guin de comandos el interprete es el mismo visor, por lo tanto este debera estar preparado para detener un script hostil, por desgracia algunas marcas y versiones de los visores ms populares no cuentan con esta capacidad.

La detencin del programa agente de usuario puede parecer un hecho trivial que se constituye ms en una molestia que en un problema de seguridad. Sin embargo el hecho de que el visor se considera una interfaz de usuario polifactica para aplicaciones de todo tipo. 3.1.4 Bloqueo del sistema El ataque de abuso de recursos que se explico arriba puede llegar a producir la cada del sistema, por ejemplo si se consume toda la memoria es posible que no exista espacio para nuevos procesos o que deje al sistema operativo en un estado inconsistente pues se siguen invocando nuevos procesos hasta agotar la memoria virtual. Otra posibilidad es aprovechar defectos en el sistema operativo o en el hardware que lo soporta. Por ejemplo se conoce un defecto en los primeros procesadores Pentium que detiene el sistema al dejarlo en estado inconsistente al usar cierta instruccin. Esta instruccin se puede invocar desde un applet Java o un componente ActiveX y dado que no es una instruccin privilegiada y puede ser invocada por usuarios con permisos mnimos, los mecanismos de seguridad del sistema operativo (en el caso de Unix o NT) no servirn para prevenir la ejecucin del comando. 3.1.5 Obtencin de informacin crtica del usuario por parte de terceros En este punto se trata sobre la informacin que proporciona el usuario de alguna manera, generalmente al introducir Si no se realiza en condiciones apropiadas de seguridad, una transaccin comercial que involucra informacin de tarjeta de crdito y de identificacin puede ser vista por terceras partes y hacer mal uso de ella posteriormente. 3.1.6 Acceso a medio magntico Fallos de seguridad de diferentes tecnologas (Java, el explorador de Internet de Microsoft o el componente de animacin de Macromedia Shockwave5) permiten acceder al disco duro y obtener informacin local. En algunos casos se puede escribir en el disco con lo cual se pueden introducir archivos que contienen programas dainos con nombres de programas comunes o modificar archivos existentes. 3.1.7 Ejecucin de programas sin control En MS Internet Explorer se han descubierto errores que permiten la ejecucin de programas sin ningn control de seguridad. Por lo tanto los recursos de la computadora quedan expuestos completamente y se puede realizar cualquier operacin, desde copiar archivos hasta dar formato al disco duro. 3.1.8 Obtencin de programas hostiles Muchos lugares en la red ofrecen programas gratis o bajo el esquema de probar y pagar despus, este mecanismo puede ser muy til y es usado por muchas casas productoras de programas incluyendo los creadores de programas visor. En muchos casos no existe ninguna garanta sobre la calidad y seguridad del programa, el archivo que se obtiene puede contener un virus, el programa deseado con modificaciones (un caballo de Troya), un documento con macros hostiles, etc. Un caso famoso es el de programas que se ofrecen para eliminar un troyano llamado Back Oriffice creado por los miembros del club de hackers Cult of the Dead Cow y que a su vez son troyanos que permiten a extraos tomar posesin de la mquina donde se instala. Los programas visor no son la excepcin: en el 98 a muchos usuarios del Explorador de Internet de Microsoft les llego un correo electrnico ofreciendo una actualizacin y conteniendo un programa que era un caballo de Troya. La obtencin de programas ejecutables en cdigo nativo o documentos que cuentan con capacidades de macro potentes es un gran peligro para cualquier sistema, Depende principalmente de la capacidad del usuario para tomar decisiones de seguridad el prevenir males que puedan surgir por este medio. 3.1.9 Intrusin en la red corporativa Cuando los usuarios de una Intranet tienen acceso a la navegacin Web, se abre una ventana por la cual se puede intentar violar la seguridad bsica de la Intranet y atacarla desde adentro. 3.2 CAUSAS PRINCIPALES DE LAS FALLAS DE SEGURIDAD Una vez vistas las consecuencias de los problemas de seguridad en el agente de usuario se deben analizar los factores que causan estas debilidades para poder encontrar posibles soluciones a este problema. A continuacin se presenta una generalizacin de los problemas

puntuales encontrados. De esta manera se contar con dos taxonomas definidas para clasificar los problemas puntuales que se traten ms adelante: la primera clasifica las fallas de seguridad por sus consecuencias (ayuda a determinar su gravedad) y la segunda por su origen (ayuda a encontrar posibles soluciones). Es claro que la primera fuente de inseguridad es el diseador y constructor de las pginas Web. Si l no produce cdigo daino (ya sea por error o malintencionadamente) los problemas de seguridad en la red seran mucho menores de lo que actualmente encontramos. Sin embargo, como ya se dijo, en esta tesis se trata la problemtica desde el punto de vista del usuario comn del cliente de Web que en general no tiene control sobre el servidor de Web. Las principales fuentes de inseguridad encontradas en el cliente son: 3.2.1 El usuario No se puede asumir nada sobre la experticia o conocimiento del usuario del cliente de Web, incluso un nio puede manejar un navegador. Por lo tanto el entorno del cliente debe proporcionar un ambiente adecuado para que un usuario no experto pueda trabajar con un mnimo de seguridad. Los programas visor contienen una serie de parmetros que permiten modificar el tratamiento que se le da a los diferentes tipos de documento y de contenido activo, pero este tipo de administracin se suele escapar de la comprensin del usuario promedio. Si nunca ha sufrido un percance en Internet es probable que el usuario que tiene que trabajar en la Web sobre un ambiente restringido piense en: Por qu debe salir siempre el mismo mensaje cada vez que llega una cookie? Por qu no puedo ver completas esas pginas llenas de sorprendentes animaciones o mens animados? Por qu no se instala automticamente ese nuevo plug-in de realidad virtual?. Despus de todo no es probable que todas las pginas que se van a visitar estn diseadas especficamente para hacer dao. Es ms, a medida que pasa el tiempo sin encontrar problemas, las medidas de seguridad comienzan a parecer absurdas y probablemente buscar la manera de saltarlas para poder acceder a todas las capacidades de las pginas que encuentra en el WWW. El problema es que el usuario no dispone de conocimiento para plantear una poltica de seguridad, y sin una poltica hablar de seguridad no tiene sentido como bien lo sealan Rubin, Geer y Ranum. 3.2.2 El programa cliente El cliente de Web es cada vez ms complejo, permite edicin de pginas Web, se integra con el sistema operativo, contiene interpretadores de Java, JavaScript, ActiveX, etc. Un programa cuanto ms complejo, ms propenso a errores es y los navegadores no son inmunes a esta situacin. Estos errores pueden en algunos casos ser aprovechados por personas mal intencionadas para lograr acceso a algunos de los recursos e incluso obtener datos importantes del sistema local. Adems existen multitud de mdulos adicionales plug-in que se pueden bajar directamente de WWW y que prometen ampliar la capacidad del navegador para presentar documentos multimedia, el usuario no tiene mayor garanta de seguridad sobre la correccin de estos componentes. Cada vez existen ms compaas nuevas (es decir, que no estn bien reconocidas) presentando nuevos productos de este tipo. El cliente de Web est diseado como un visor para diferentes tipos de documentos y permite ampliarse con otros programas para incrementar el nmero de tipos de documentos que puede mostrar. Esto quiere decir que el cliente de Web permite acceso directamente a programas diseados para trabajar nicamente en modo local y que no tienen ninguna previsin de seguridad en su diseo. Por ejemplo se puede indicar que un programa de shell o un interpretador ser el programa utilizado para presentar algn tipo de script o programa. Hacer esto es como dejar una puerta abierta para que cualquier persona que conozca este hecho pueda preparar una pgina Web frente a la cual el sistema local no tiene ninguna defensa. Otro ejemplo, ms comn en el ambiente de Windows, tienen que ver con los programas de Microsoft Office, las capacidades de macros de estos programas son cada vez ms potentes permitiendo desarrollar programas muy completos en lenguaje Basic (ya son comunes los virus de macro). Los navegadores de Internet ya tienen como visores por defecto a los programas de Office para poder presentar documentos con extensiones .DOC, .XL, .PPT, etc. y, por lo tanto, se puede presentar una hoja Web en la red que contenga algn documento Office con macros dainos que penetraran fcilmente cualquier medida de seguridad.

3.2.3 Extensiones de HTML HTML ya no es una herramienta suficientemente flexible y potente para las exigencias de los creadores de pginas Web. La idea bsica es que algunos procesos sencillos de presentacin de las pginas Web se puedan desarrollar sobre el cliente sin necesidad de proceso continuo por parte del servidor, algunas de las tecnologas basadas en esta idea son JavaScript, VBScript y Dynamic HTML. Este tipo de tecnologas estn confinadas al ambiente del cliente de Web y los recursos que pueden utilizar son los que proporciona el programa cliente. Esto parece aislar al resto del sistema de la actividad de los scripts desarrollados con estas tecnologas, sin embargo se pueden crear aplicaciones que causen actividad maliciosa. Un ejemplo ya clsico es el programa que utiliza un ciclo infinito para abusar de los recursos del sistema. A medida que la integracin del cliente de Web con el sistema operativo es cada vez mayor, y la distincin entre recurso del cliente y de S.O. se difumina, se debe tener ms en cuenta a estas tecnologas como una fuente creciente de agujeros de seguridad. 3.2.4 Contenido activo Un paso ms all de las extensiones a HTML, aprovechando la capacidad de integrar dentro de las hojas Web objetos de diversa ndole, se han incluido pequeas aplicaciones (applets o controles) desarrolladas bajo ambientes de programacin completos que tienen mayor potencia y alcance que los lenguajes de script. Las dos tecnologas ms utilizadas son Java desarrollado por Sun Microsystems y Activex de Microsoft. Las diferencias entre estos dos mecanismos y su influencia sobre el ambiente de Web son diferentes. David Presotto identifica los objetivos en que se debe basar la inclusin de contenido activo en las pginas HTML: Estar en capacidad de seleccionar software de autores conocidos y respetables y poder asegurar que el software ha sido realmente creado por dichos autores. Poder reconfigurar una mquina cuando se ejecuta software para asegurar la informacin crtica. Esto implica tener la seguridad que el software existente (visor) no esta corrupto y por lo tanto se comportar de la manera esperada. Poder conectarse y transmitir informacin en forma segura. esto implica identificacin de ambos puntos de la conexin y establecimiento de canales seguros basados en cifrado de contenido, firmas digitales y digest. Existen diferentes medidas sencillas que se pueden tomar para enfrentar los problemas bsicos del contenido activo. La primera es permitir la carga de componentes y applets slo desde sitios confiables. Otra es ejecutar el navegador con un mnimo de permisos (en los sistemas operativos que tienen caractersticas apropiadas como UNIX) de manera que si se ejecuta un programa que contiene errores o cdigo hostil afecte solamente a una porcin limitada de los recursos de la mquina. Algunos consultores y grupos de investigacin como el SIP (Secure Internet Programing) de Princenton recomiendan deshabilitar completamente la carga de contenido activo. En el mercado se encuentran mecanismos cortafuego (firewalls) que afirman filtrar los archivos de contenido activo. En general este proceso es muy complicado, La revisin del contenido del archivo HTML en busca de la marca <OBJECT> no es suficiente. Es sencillo crear scripts que se encarguen de colocar la marca y el contenido que invoca el programa en el momento en que se despliega la pgina en el programa cliente y de esta manera se engaa a muchos sistemas de control. Si el programa cortafuego se dedica a escudriar los paquetes que viajan por la red para descubrir el cdigo caracterstico de un applet Java toda la comunicacin resultar lenta. 3.2.4.1 ActiveX ActiveX es una combinacin de tecnologas, protocolos y APIs desarrollada por Microsoft para obtener contenido ejecutable a travs de la red. Se ha propuesto como una alternativa a Java de Sun, sin embargo parecen estar ms cerca de los plug-in de Netscape. Un componente ActiveX puede ser desarrollado y compilado en cdigo binario nativo o ser escrito en Java y ejecutado el bytecode resultante en un ambiente seguro como los applets normales. La premisa de ActiveX es ejecutar aplicaciones confiables en un ambiente no confiable, es decir, existe alguna manera de asegurar que una aplicacin no tiene como objetivo hacer dao. Para lograr esto se implement un sistema de firmas digitales (Authenticode) que permite al

autor del componente ActiveX autenticar el origen de la aplicacin. Una entidad verificadora (por ejemplo Verisign) se encarga de avalar la autenticidad de la firma. Cuando un componente ActiveX llega al cliente de Web, este lo compara con la lista de fuentes que se consideran confiables y si corresponde a alguna de ellas lo ejecuta, a partir de ese momento el componente ActiveX puede disponer de todos los recursos del sistema local. Si el componente no fue encontrado entre las entidades confiables, la decisin de ejecutarlo o no pasa a manos del usuario. Ya existen componentes ActiveX generados por el CCC (Chaos Computer Club) y otros, destinados a hacer dao pero que no estn avalados por ninguna firma digital vlida. Alfred McLain ha publicado un control ActiveX llamado Exploder , plenamente certificado y que realiza un shutdown de toda mquina Windows 95 momentos despus de que la pgina Web que lo contiene aparezca en el explorador. Microsoft y Verisign ya han revocado la certificacin de McLain. Sin embargo, los usuarios de IE 3.0 todava se pueden ver afectados por este componente ActiveX pues el programa no est preparado para cuestionar una firma despus de que se ha definido como vlida. Por otro lado, una certificacin vlida no defiende un sistema contra errores de programacin o contra virus que se hayan introducido en el sistema del desarrollador antes de liberar el producto. Tampoco evita que las caractersticas tiles de un componente puedan ser aprovechadas con malas intenciones. 3.2.4.2 Java Java se basa en la premisa opuesta ejecutar aplicaciones no confiables en un ambiente confiable. En este caso no se hace ninguna presuncin acerca del origen del applet, ni se deja la responsabilidad de la seguridad al usuario. Los applets Java que se transportan por la red se ejecutan en un ambiente mucho ms restringido que las aplicaciones autnomas destinadas a ejecutarse de manera local. El ambiente seguro se componen de una serie de mecanismos que intentan asegurar que una aplicacin no pueda producir efectos indeseables de seguridad, ya sea por errores de programacin o por mala intencin. Reglas del ambiente: Existen una serie de restricciones importantes para los applets Java. Por ejemplo una aplicacin Java no puede abrir un socket a otro lugar diferente del servidor que la origin, no se puede leer o escribir libremente en el disco duro, no puede sobreescribir libreras Java del sistema. Lenguaje de programacin robusto: Uno de los objetivos en el diseo de Java fue minimizar las fuentes de errores en el cdigo. Por ejemplo no se permiten punteros a posiciones de memoria, slo referencias a objetos y recoleccin automtica de basura, verificacin de desbordamiento de arreglos. Planificador de memoria: Al bajar un applet de la red, el planificador de memoria prepara el espacio y lo acomoda y asla en la memoria RAM Compilador: El compilador Java debe estar en capacidad de verificar el cdigo para prevenir la generacin de cdigo binario que no se ajuste a las normas de seguridad de Java. Verificador de cdigo binario: Cuando un applet Java es trado al sistema local, un verificador de cdigo lo vuelve a revisar en busca de secciones de cdigo que puedan generar dao al sistema local. Los programas que implementan las restricciones y verificaciones del ambiente de Java (conocido como caja de arena) son grandes y complejos, por lo tanto se han encontrado multitud de problemas de diseo y programacin que pueden explotarse para penetrar la seguridad del sistema local. Por otro lado, existe una corriente entre los especialistas en seguridad que no estn de acuerdo con la solucin de caja de arena de Java o con la filosofa sobre la cual ha sido creada. Segn William Wulfs se debe redisear todo el sistema desde cero dado que la idea de la caja de arena no es realista. Segn Felten del grupo de investigacin SIP de Princenton saltar fuera de la caja de arena es juego de nios. Por otro lado, las restricciones impuestas a los applets Java pueden resultar excesivas para algunas aplicaciones de manera que se ha desarrollado un sistema de firmas digitales similar al utilizado en ActiveX para poder verificar el origen del applet y poder eliminar las restricciones de la caja de arena. La implementacin de este mecanismo tambin ha tenido problemas, la

versin 1.1 de Java implementada nicamente en el explorador HotJava 1.0 permite que cualquier applet pudiese engaar al sistema y hacerse pasar como originado en una fuente confiable.

4 SEGURIDAD EN EL CLIENTE DE WEB

En los captulos anteriores se han descrito los problemas de seguridad que aquejan al visor de Web y qu factores los causan. Esto sirve como base para estudiar que caractersticas debe tener un programa visor para proporcionar un ambiente de navegacin seguro. Existen dos aspectos bsicos que se deben tener en cuenta a la hora de definir las caractersticas que debe tener un cliente de Web que se considere seguro: los mecanismos de seguridad en s y la interfaz de configuracin de estos mecanismos. Para poder tener la certeza que se est seleccionando un conjunto apropiado de mecanismos de seguridad se sigui algunos de los procedimientos para definir polticas de seguridad en redes como los describe [ACO98]. De esta manera se intenta asegurar que todos los recursos involucrados en la navegacin en el servicio Web estn protegidos y que existen mecanismos tecnolgicos suficientes para que las polticas de seguridad que se designen puedan ser implantadas. Una vez se tiene un panorama de las necesidades de seguridad en el visor, se va a estudiar los mecanismos de seguridad utilizados actualmente en las dos implementaciones comerciales de agente de usuario ms populares, Navegador de Netscape y Explorador de Internet de Microsoft y despus se discutirn las propuestas de este trabajo que se consideran importantes para proporcionar una herramienta segura de trabajo en WWW. 4.1 ANLISIS DE NECESIDADES DE SEGURIDAD Para alcanzar un programa visor seguro este debe contar con medios para poder plasmar las polticas que el administrador de la red o el usuario definan. Por lo tanto se debe encontrar el conjunto de mecanismos que mejor satisfagan los posibles requerimientos en los ambientes ms comunes en los cuales es usado el visor, esto implica hacer un anlisis general de las polticas requeridas por estos ambientes. Se debe tener en cuenta que aqu se van a delinear polticas basadas exclusivamente en las necesidades de seguridad para la navegacin en la Web. No se est tratando el problema de aplicaciones propietarias que funcionan sobre la Web y que presentan problemas especficos de seguridad. Por otro lado, si el programa visor es inseguro, ninguna aplicacin que funcione sobre l podr considerarse segura. Por lo tanto estas polticas deben estar incluidas en un plan ms amplio y ambicioso que cubra todos los aspectos de los recursos de hardware y software que soportan o conviven con el programa visor. Se han identificado dos ambientes de navegacin muy comunes, la navegacin desde un computador personal aislado a travs de un ISP y la navegacin desde una estacin de una red corporativa. Ambos casos son muy diferentes, y se van a analizar las vulnerabilidades, las diferentes alternativas de soluciones de seguridad, las polticas generales de seguridad y los requisitos tecnolgicos para poder implementarlas. Existen otros escenarios, pero estos dos parecen ser los principales y tienen caractersticas generales comunes a los dems escenarios. 4.1.1 Navegacin personal En este caso tenemos un computador personal que se conecta a Internet a travs de un proveedor de servicios de Internet (ISP). Este escenario es muy comn y probablemente uno de los ms dbiles pues el usuario suele carecer de conocimientos suficientes para tomar decisiones de seguridad.

Ilustracin 1 Esquema de navegacin personal En este ambiente suele haber un nico usuario/administrador o un grupo informal (familia o amigos). Adems, no existe garanta sobre la habilidad y experticia del usuario tanto para las labores de navegacin como de administracin. En general, el usuario que utiliza el programa visor para su uso particular no esta dispuesto a invertir sumas importantes de dinero en mecanismos de seguridad ni a invertir tiempo en estar al da con las actualizaciones de seguridad o cambios de versin del programa. La mayor parte de las pginas que ve el usuario privado provienen de servidores que estn fuera de su influencia y en los que no puede confiar salvo contados casos en que el nombre de la organizacin respalda la pgina o la necesidad de servicios especiales generan la necesidad de tratar en forma diferente el contenido de pginas de un servidor o de otro. 4.1.2 Navegacin desde una red corporativa En este caso se navega desde una estacin de trabajo de una red, existe una organizacin formal que respalda la red, existen responsables especializados por cada uno de los componentes de la red y que deben crear procedimientos y polticas formales de seguridad.

Ilustracin 2 Esquema de navegacin desde una red corporativa En este escenario existen dos ambientes claramente demarcados de navegacin, el que corresponde a la Intranet que se puede considerar confiable y el de Internet cuya confiafibilidad es, en el caso general, dudosa. Puede no ser conveniente para la organizacin tratar los contenidos de ambos ambientes de la misma manera. Por ejemplo, un programa basado en Web utilizado por la organizacin puede requerir acceso a disco duro o abrir conexiones TCP/IP a

diferentes servidores pero no se le pueden permitir los mismos permisos a cdigo de pginas que se obtienen de Internet sin garantas de calidad o seguridad. 4.1.2 Definicin del alcance del sistema El alcance y lmites del sistema se definen mediante el modelo TASCOI. T (Transformaciones) Presentacin de informacin multimedia Servicios clsicos de Internet con interfaz HTML o Java (correo electrnico, chat, etc.) Compras Banca virtual Entretenimiento interactivo (juegos, apuestas, chat) Aplicaciones empresariales A (Actores) Usuario Creador de la pgina Web S (Proveedores) Proveedor de servicios Internet Administrador de servidor Web Administrador de la Intranet C (Cliente) Usuario O (Propietario) Usuario Organizacin I (Contexto) Proveedor de Servicios Internet Administradores de servidores Web Administradores de enrutadores 4.1.3 Recursos del sistema Se debe definir qu recursos se deben proteger para asegurar que no queda alguno sin estar cubierto por las polticas de seguridad. Area Recursos Hardware CPU Disco Duro Pantalla Impresora Software Sistema Operativo Programa Visor Programas de ofimtica Datos Informacin sobre el sistema Configuracin del visor Archivos temporales del visor Cookies Historia de navegacin Archivos en disco duro Nombre y clave de usuario Humanos Usuario Administrador 4.1.4 Vulnerabilidades En el captulo 3 se mencionaron las diferentes amenazas generales a que est expuesto el visor y el impacto que pueden tener sobre el sistema. La gravedad del impacto depende del caso especfico que se est estudiando, como esta es la base para idear mecanismos para enfrentar los diferentes problemas de seguridad se deben tener en cuenta (en lo posible) todos los casos. Vulnerabilidad Amenaza Uso de programa visor modificado (caballo de Troya) Obtencin del programa visor a travs de la red. Puede crearse un programa que simula la operacin de un programa de navegacin popular pero que ataca el sistema del usuario (caballo de Troya) o libera algn virus. Este programa se pone a disposicin del pblico en la red o se distribuye por

medio de correo electrnico bajo el nombre del programa legtimo. Informacin del sistema no sensible expuesta Aceptacin de cookies por defecto Diseadores de pginas Web trabajando en conjunto pueden conocer las costumbres de navegacin del usuario para mercadeo dirigido. Espionaje. Visibilidad de cookies por servidores Web a los que Intrusos pueden observar las costumbres de no estaban destinadas. navegacin del usuario. Visor informa automticamente a los servidores de Un intruso puede crear una pgina que indica que la marca, versin y del sistema operativo que lo tipo de sistema operativo y visor utiliza el usuario soporta. en preparacin de un ataque ms serio. El programa mantiene un archivo de direcciones Personas con acceso fsico al computador pueden URL de todos los lugares visitados por el usuario analizar el comportamiento del usuario (invasin a (slo Explorador de Microsoft). la privacidad). Revelar informacin sensible Se puede intercambiar informacin entre pginas de Se crea una pgina que presente en un marco una diferentes orgenes que se presentan ventana de algn servicio que requiere alta simultneamente en marcos HTML. seguridad y en otro marco una pgina con cdigo que puede robar la informacin que se quera asegurar (nmero de documento de identificacin, nmero de tarjeta de crdito, clave de usuario, etc.) El uso de marcas ASP revela el nombre de usuario y Intrusos puede obtener el par nombre de la clave de acceso cifrada (slo Explorador de usuario/clave de acceso, utilizar un programa Microsoft). especial para romper la clave y obtener acceso a los recursos de computo del usuario. El programa visor guarda en archivos temporales Personas con acceso fsico al computador pueden informacin introducida por el usuario en formas conocer informacin sobre transacciones bancarias HTML (slo navegador de Netscape). y comerciales del usuario. Bloqueo del programa cliente y/o del sistema No existe lmite al nmero de marcos HTML dentro Una pgina cuyos marcos HTML contienen de una pgina. referencias a s mismas genera un ciclo infinito consumiendo recursos del sistema. No existe lmite al nmero de instancias del Un applet Java o un guin de comandos JavaScript programa visor. o VB Script puede entrar a un ciclo infinito y abrir instancias del visor. No existe control sobre los recursos a que puede Contenido activo puede entrar en un ciclo infinito y acceder el visor. consumir tiempo de procesador y memoria. Fallas en el motor de interpretacin de HTML y D- Al introducir cadenas muy largas en algunas HTML referencias especiales de HTML se genera un desbordamiento de buffer o de pila que puede bloquear el visor. Obtencin de informacin crtica del usuario por parte de terceros La informacin que viaja a travs de la red es Intrusos pueden espiar el trfico en la red para visible para administradores e intrusos que tengan obtener informacin sensible como claves de acceso a servidores y enrutadores. acceso, nmeros de documentos de identidad Acceso a medio magntico Mediante el uso de campos de tipo file y las Intrusos pueden crear pginas para robar archivos capacidades de programar las acciones de cortar y del computador del usuario. pegar se pueden enviar automticamente archivos del disco duro al servidor Web. Mediante la propiedad InnerText del objeto Intrusos pueden crear pginas para robar archivos Document se pueden enviar archivos de texto desde del computador del usuario. el visor al servidor Web.

 Ejecucin de programas sin control Fallas en el motor de interpretacin de HTML y DHTML El visor tiene configurados programas para presentar documentos que tienen capacidades avanzadas de macros. El visor puede tener configurados shells o interpretadores que no estn pensados para trabajar con cdigo no confiable (perl, python, awk) para abrir automticamente programas ejecutables. Una ventana generada en Visual Basic puede cubrir parcialmente una ventana de aprobacin de creacin de objetos o de ejecucin de controles Activex. Obtencin de programas hostiles Un applet Java puede seguir ejecutndose despus que el documento html que lo contena ha sido descartado. Se pueden obtener programas y documentos sin garanta de calidad o seguridad.

El desbordamiento de pila que puede ocurrir al introducir valores inconvenientes en algunas referencias puede utilizarse para ejecutar cdigo nativo. Se pueden crear pginas que aprovechen esta caracterstica para presentar documentos con macros hostiles que se abren automticamente. Se pueden crear pginas con programas que daen al sistema (virus, caballos de Troya, gusanos, etc.) Se puede presentar informacin que impulse al usuario a aceptar ejecucin de cdigo sin control de seguridad sin que l lo sepa. Un applet malicioso cargado previamente puede afectar a los applets cargados en documentos html vlidos y confiables El usuario puede traer a su mquina programas con errores graves o que contienen cdigo hostil (virus, caballos de Troya, gusanos, bombas lgicas, etc.)

Intrusin en la red corporativa Se puede engaar al mecanismo de zonas de Una pgina con contenido no confiable es tratada seguridad para que trate una pgina Web obtenida con niveles de seguridad bajos. en Internet como si fuese una pgina de la Intranet. Se puede engaar a la mquina Java para que Se puede atacar a un servidor de la Intranet considere un lugar dentro de la red corporativa mediante applets Java que abren sockets a puertos como el origen de un applet que viene de un de direcciones internas que el DNS engaado toma servidor fuera de la Intranet. como direccin de origen de la pgina. 4.1.5 Protecciones En esta seccin se presentan las protecciones que pueden evitar las vulnerabilidades mostradas arriba o paliar sus efectos. Una proteccin puede ser una solucin tecnolgica o un procedimiento a seguir por los usuarios o administradores para evitar el peligro. Vulnerabilidad Proteccin Uso de programa visor modificado Obtencin del programa visor a travs de la red. El programa de navegacin debe ser obtenido nicamente de la pgina Web de la casa de software que lo produce. Se debe desconfiar especialmente de promociones enviadas a travs de correo electrnico. Informacin del sistema no sensible expuesta Aceptacin de cookies por defecto La interfaz de configuracin debe permitir manejar la cookies as: Aceptar todas las cookies Preguntar al usuario antes de aceptar una cookie. No aceptar ninguna cookie. Visibilidad de cookies por servidores Web a los que Cambio del programa a una versin y/o marca que no estaban destinadas. no contenga la falla. Visor informa automticamente a los servidores de La interfaz de configuracin permite definir que la marca, versin y del sistema operativo que lo informacin no imprescindible se va a presentar. soporta. El programa mantiene un archivo de direcciones Configurar el sistema operativo para eliminar el URL de todos los lugares visitados por el usuario archivo al terminar la sesin (Windows NT, Unix,

(slo Explorador de Microsoft). Revelar informacin sensible Se puede intercambiar informacin entre pginas de diferentes orgenes que se presentan simultneamente en marcos. El uso de marcas ASP revela el nombre de usuario y la clave de acceso cifrada.

Linux). Borrar a mano el archivo peridicamente. Las pginas de diferente origen no deben compartir informacin. Desactivar la interpretacin de determinadas marcas ASP. Desactivar la interpretacin de todas las marcas ASP. No recibir documentos ASP. Cambio del programa a una versin y/o marca que no contenga la falla. Configurar el sistema operativo para eliminar los archivos temporales al terminar la sesin (Windows NT, Unix, Linux). Borrar a mano los archivos despus de transacciones crticas.

El programa visor guarda en archivos temporales informacin introducida por el usuario en formas HTML (slo navegador de Netscape).

Bloqueo del programa cliente y/o del sistema No existe lmite al nmero de marcos HTML dentro Mecanismo de contencin para el nmero de de una pgina. marcos en una instancia del visor. Mecanismo de contencin para la cantidad de memoria y de tiempo de procesador a disposicin del visor. No existe lmite al nmero de instancias del Mecanismo de contencin para el nmero de programa visor. instancias del programa visor. Mecanismo de contencin para la cantidad de memoria para instancias del programa visor. No existe control sobre los recursos a que puede Mecanismo de contencin para la cantidad de acceder el visor. memoria y tiempo de CPU para instancias del programa visor. Fallas en el motor de interpretacin de HTML y D- Actualizacin a la versin ms moderna del visor HTML Obtencin de informacin crtica del usuario por parte de terceros La informacin que viaja a travs de la red es Deben existir mecanismos de cifrado para proteger visible para administradores e intrusos que tengan la informacin que viaja por la red. acceso a servidores y enrutadores. Acceso a medio magntico Mediante el uso de campos de tipo file y las Configurar avisos antes de enviar archivos al capacidades de programar las acciones de cortar y servidor Web. pegar se pueden enviar automticamente archivos Cambio del programa a una versin y/o marca que del disco duro al servidor Web. no contenga la falla. Mediante la propiedad InnerText del objeto Configurar avisos antes de enviar informacin al Document se pueden enviar archivos de texto desde servidor Web. el visor al servidor Web. Cambio del programa a una versin y/o marca que no contenga la falla. Ejecucin de programas sin control Fallas en el motor de interpretacin de HTML y D- Cambio del programa a una versin y/o marca que HTML no contenga la falla. El visor tiene configurados programas para Configuracin presentar documentos que tienen capacidades avanzadas de macros. El visor tiene configurados shells o interpretadores Configuracin para abrir automticamente programas ejecutables.

Una ventana generada en Visual Basic puede cubrir parcialmente una ventana de aprobacin de creacin de objetos o de ejecucin de controles Activex. Obtencin de programas hostiles Un applet Java puede seguir ejecutndose despus que el documento html que lo contena ha sido descartado. Se pueden obtener programas y documentos sin garanta de calidad o seguridad. Intrusin en la red corporativa Se puede engaar a la mquina Java para que considere un lugar dentro de la red corporativa como el origen de un applet que viene de un servidor fuera de la Intranet. 4.2 NETSCAPE NAVIGATOR

Las ventanas de mensajes deben ser modales de sistema y siempre visibles.

Desactivar Java al navegar a pginas no confiables. Aceptar nicamente applets firmados. Programa antivirus que se integre con el visor. Aviso al usuario antes de obtener un archivo activado por defecto. El mecanismo de resolucin de URL debe hacer verificacin reversa con el DNS para verificar la direccin del servidor.

Se puede ver claramente que en Netscape 3.0 el nfasis de seguridad se realiza sobre la seguridad de conexin, y autenticacin de la identidad de ambos puntos de una conexin segura, por lo tanto la documentacin existente hace nfasis sobre mecanismos de cifrado (principalmente basado en RSA) y en manejo de certificados personales y de sitios Web. 4.2.1 Interfaz Netscape proporciona medios para que el usuario pueda discernir cuando est navegando en un ambiente seguro o inseguro. La primera pista es que la direccin URL empieza por https:// en vez de http://. Por otro lado en las versiones 2.X y 3.X, en la zona inferior izquierda aparece un diminuto icono de seguridad que presenta una llave rota sobre fondo gris para indicar que el documento que se est observando es inseguro, una llave con un diente sobre fondo azul para indicar un documento seguro bajo cifrado de 40 bits y dos dientes para cifrados con llaves ms poderosas. En el navegador 4.0 o superior el icono presenta un candado abierto o cerrado de acuerdo a si la pgina es insegura o segura, no hay discriminacin entre cifrado de 40 o de 128 bits. Sin embargo, estos mecanismos no resultan muy tiles para usuarios inexpertos pues fcilmente se pueden pasar por alto, adems se ha encontrado que en sitios Web que pueden presentar documentos seguros e inseguros simultneamente en diferentes marcos el mecanismo del icono no es confiable pues no cuenta con medios para mostrar claramente este ambiente mixto. El visor de Netscape presenta un aviso cuando se pasa de una pgina segura a una insegura y viceversa, el usuario debe actuar para que la ventana del aviso desaparezca con lo cual no la puede pasar por alto as que este es el mecanismo fundamental para que el usuario tenga conocimiento del estado bsico de seguridad en que se mueve. Si el usuario desea conocer detalles tiene disponible informacin sobre el documento a la que puede acceder pulsando sobre el icono para ver en detalle el tipo de cifrado y el contenido del certificado digital si lo hubiere. 4.2.2 Configuracin Netscape presenta sus mecanismos de configuracin en un tem de men separado de los dems lo cual permite que el usuario tenga claro donde encontrar las diferentes caractersticas de seguridad. Sin embargo la capacidad de deshabilitar Java y JavaScript se encuentra bajo el tem de Network preferences (preferencias de red), lo cual oculta el hecho de que las principales razones para deshabilitar estas formas de contenido activo tienen que ver con seguridad. Permite escoger en que eventos se debe presentar avisos de alerta. Los diferentes casos son: Entrar a un espacio de documentos seguros. Salir de un espacio de documentos seguros. Ver un documento con caractersticas mixtas (seguridad/no seguridad). Enviar el contenido de un formato en modo no seguro.

La interfaz tambin facilita habilitar o deshabilitar las diferentes caractersticas de SSL versin 2 (cifrado RC4 Y RC2) Y SSL versin 3 (RC4 con MD5, RC2 con MD5 Y MD5 sin cifrado). 4.2.3 Certificados El navegador puede administrar certificados personales, estos certificados son provistos por empresas confiables conocidas como entidades certificadoras y son un mecanismo para establecer la identidad del usuario al conectarse a un sitio Web que as lo requiera. La administracin incluye facilidades para conectarse con una entidad certificadora, mecanismos de importacin y exportacin de certificados para poder transferirlos, proteccin con clave de acceso, verificacin del certificado y borrado. El navegador tambin contiene informacin acerca de certificados de sitios en la Web. Estos certificados permiten establecer la identidad del servidor al que se conecta y asegurar que el intercambio de informacin se realiza con el dueo del certificado y no con algn servidor que lo este suplantando. Cuando el visor alcanza un sitio que presenta un certificado, el usuario puede decidir si rechaza el certificado, si acepta el certificado slo para esa sesin o si lo acepta permanentemente, caso en el cual no volver a recibir notificacin al volver al sitio seguro. El usuario tambin puede decidir si acepta por defecto todos los sitios avalados por una entidad certificadora en especial; de esta manera, los empleados de una empresa que posee certificados o acta como entidad certificadora para s misma se pueden conectar a las pginas Web de la empresa de una forma segura. 4.2.4 Cdigo mvil El navegador permite verificar los certificados que acompaan a applets Java o guiones de comandos JavaScript, editar los privilegios que obtiene el cdigo que est avalado por el certificado o eliminarlo para impedir la carga automtica del cdigo remoto. Se puede habilitar o deshabilitar la ejecucin de cdigo mvil. La opcin es de todo o nada: no existe mecanismo que permita seleccionar lugares confiables y no confiables, es decir no existe granularidad y por lo tanto este mecanismo pierde utilidad. Por otro lado la opcin de habilitar o deshabilitar las opciones de Java y JavaScript se encuentra en la seccin de Preferencias de Red en la zona de Lenguajes. El usuario inexperto probablemente no encontrar una relacin con seguridad y por lo tanto no tiene medios para discernir si le conviene o no ejecutar cdigo remoto sobre su navegador. 4.2.5 Mecanismos de cifrado Netscape tiene dos versiones, una para Estados Unidos y Canad que maneja cifrado con llaves de 128 bits y otra para el resto del mundo que slo soporta llaves de 40 bits. Esto se debe a las regulaciones de exportacin de algoritmos de cifrado de los Estados Unidos. Los mecanismos de cifrado bsicos para Netscape se basan en SSL 2 y SSL 3 pero el sistema permite adicionar mdulos de algoritmos de cifrado, de esta manera el sistema puede ser enriquecido con nuevos mtodos estndar o incluir mtodos propietarios para obtener mayor seguridad dentro de grupos cerrados de usuarios. Netscape tambin soporta normas con propsitos especiales; en colaboracin con Chrysalis, Datakey y Litronics ha desarrollado soporte para smart cards basado en PKCS 11 (Public Key Cryptography Standard) y con Visa, IBM e Integron proporciona soporte para Forms Signing, un mecanismo para verificar que una transaccin ha sido autorizada basado en PKCS 7. 4.2.6 Claves de acceso El visor de Netscape protege los certificados personales con claves de acceso. Cuando se navega hasta una pgina que requiere un certificado para identificacin, el visor preguntar por la clave de acceso. Sin embargo, el sistema no realiza ninguna verificacin sobre la palabra utilizada como clave de acceso. Se puede decidir si la clave de acceso debe ser solicitada al inicio de cada sesin, cada vez que es necesitada (se solicita un certificado que identifique al cliente) o cada X minutos. Las claves de acceso no protegen contra acceso fsico al computador que contiene el visor y los archivos de configuracin: los certificados y claves de acceso estn disponibles y en directorios estndares fciles de encontrar. Por lo tanto, estos archivos son susceptibles de ser borrados, sustituidos o modificados. La nica defensa reside en la capacidad del sistema operativo sobre el cual funciona el visor y la gran mayora de usuarios utilizan sistemas operativos personales

(Windows 3.1, MAC OS, Windows 95/98, etc.) que no cuentan con medidas de seguridad apropiadas. 4.2.7 Mission Control Mission Control es un sistema de administracin centralizado para los productos Netscape basado en LDAP (Light Directory Access Protocol) desde el cual se puede controlar la configuracin del navegador de Netscape y generar y proporcionar certificados a los clientes de Web de manera transparente para los usuarios finales. Netscape hace notar en sus documentos que este mecanismo es menos seguro que generar los certificados directamente en el cliente. 4.2.8 NetWatch Netscape utiliza una norma de calificacin conocida como PICS (Plataforma para Seleccin de Contenido en Internet) que permite filtrar contenido que se considera inconveniente. PICS ofrece un mecanismo para que los diseadores de pginas Web definan el contenido que presentan y para que los programas visores puedan obtener esa descripcin. Netwatch reconoce dos sistemas diferentes basados en la norma PICS, RSACi y SafeSurf y el usuario del navegador puede utilizar cualquiera de los dos sistemas o ambos simultneamente. Este esquema requiere que los diseadores de contenido Web voluntariamente califiquen sus pginas. Cuando Netwatch est activado, la informacin PICCS de cada pgina obtenida en la red es comparada con los niveles permitidos previamente configurados. La configuracin permite tambin filtrar pginas que no contienen informacin de calificacin. Este mecanismo necesita que tanto Java como JavaScript estn activados. Esto puede presentar problemas pues una de las recomendaciones al visitar sitios no confiables consiste en desactivar Java y/o JavaScript y las pginas que se intenta filtrar provienen probablemente de lugares no confiables. 4.3 MICROSOFT INTERNET EXPLORER 4.3.1 Niveles de seguridad normalizados La interfaz permite definir los niveles de seguridad estndar, Alta (recomendado para todos los usuarios), Media (para programadores y usuarios expertos), Ninguna (no recomendada) y tambin cuenta con Personalizada. La interfaz es muy sencilla y fcil de utilizar pero no existe ninguna granularidad, o se puede o no se puede ver el contenido activo, no existe ninguna discriminacin que permita adaptar la configuracin de seguridad a las necesidades del usuario. 4.3.2 Asesor de contenidos El Explorador cuenta con un asesor de contenidos, el cual se encarga de filtrar las pginas Web que el agente de usuario puede mostrar. Permite configurar los niveles de violencia y sexo que se pueden presentar. Este mecanismo, al igual que Netwatch de Netscape, se basa en PICS del Consorcio World Wide Web para auto calificacin. Existen ms de un milln de sitios Web registrados. Este mecanismo parece ser inoperante ante la gran cantidad de nuevas pginas Web que aparecen todos los das y la pequea fraccin que cubre. Aparece el concepto de supervisor el cual tiene una clave la cual puede usar para modificar los parmetros definitiva o temporalmente. Sin embargo, este concepto slo parece ser til en ambientes restringidos como un padre haciendo de supervisor para sus hijos o en organizaciones pequeas. 4.3.3 Certificados Tambin permite administrar certificados personales, certificadores de servidores y editores. Estos ltimos permiten definir qu empresas se consideran confiables y por lo tanto se le deben permitir instalar software automticamente sin consultar al usuario. Una forma especial de certificados utilizada por Microsoft se conoce como Authenticode. Bsicamente consiste en una firma digital que permite identificar a la persona u organizacin que respalda una pieza de cdigo ejecutable y verificar la integridad del contenido. La firma tiene un tiempo lmite de uso que se calcula a partir del tiempo requerido para violar las claves de cifrado utilizadas. Authenticode tambin permite proporcionar un ambiente menos restrictivo a applets Java. Junto con la firma Authenticode que avala un applet puede ir tambin una lista de recursos requeridos que en condiciones normales la Mquina Virtual Java no proporcionara a un applet que no es

del sistema. De esta manera, aunque el usuario acepte la ejecucin del applet no se le proporciona acceso libre, slo a los recursos que aparecen dentro de la informacin Authenticode. Adems, se cuenta con un Administrador de Paquetes (Package Manager) que permite instalar clases en las cuales no se tiene plena confianza en el disco local y firmarlas con una lista restringida de recursos; de esta manera no se les proporciona la misma libertad que a las clases del sistema. 4.3.4 Contenido activo En cuanto contenido activo permite habilitar o deshabilitar las siguientes caractersticas: Permitir la transferencia de contenido activo. Activar controles y complementos ActiveX. Ejecutar secuencias de comandos ActiveX. Permitir programas Java. Aparte de la ausencia de configuracin para JavaScript y a VBScript, es notoria la pobreza de la ayuda provista con el programa acerca del significado de cada uno de los tems mostrados. Bsicamente indica que para configurar la seguridad del programa se deben marcar los tems apropiados, sin explicar qu significa cada uno de ellos. 4.3.5 Zonas de Seguridad Un mecanismo para identificar lugares confiables es el concepto de zonas de seguridad segn el cual se configuran diferentes medidas de seguridad para diferentes zonas de seguridad y se puede asignar lugares en la Web por direccin o nombre a las diferentes zonas. Cuando el usuario est observando pginas o ejecutando cdigo, las medidas de seguridad se ajustan a las que corresponden a la zona a la que pertenece la pgina o el cdigo y al nivel de seguridad existente. Microsoft presenta una implementacin inicial basada en cuatro zonas, Local, Intranet, Internet y personalizada y el usuario puede aadir ms a medida que lo necesita. La configuracin no es obvia pues para una zona se deben resolver ms de 50 opciones de seguridad. En el caso corporativo, el administrador puede utilizar el Internet Explorer Administration Kit para preconfigurar las zonas de seguridad antes de instalar la versin 4.0 del explorador y se pueden realizar actualizaciones a estas zonas dinmicamente. Por otro lado, parece existir un problema grave con la implementacin de este mecanismo. La zona Intranet que se considera confiable se reconoce por que la URL no contiene puntos y tiene menos de 15 caracteres. Este mecanismo es dbil y permite que el sistema pueda ser engaado con direcciones externas que cumplen con la condicin para la zona Intranet. 4.3.6 Interfaz Los avisos que se presentan al ocurrir un evento que tiene que ver con la seguridad no se configuran en la parte de seguridad sino en la de configuracin avanzada. Los avisos pueden aparecer al enviar informacin a travs de una conexin abierta, cambiar al modo no seguro, al encontrar certificados no vlidos o al recibir una cookie. 4.4 PROPUESTAS PARA LA INTERFAZ DE CONFIGURACIN Existen diferentes tipos de usuarios del servicio WWW y cada uno de ellos juega diferentes roles en diferentes situaciones. Es cuando menos inocente suponer que una configuracin bsica de seguridad va a ser til para cualquier usuario en cualquier situacin. Se busca llegar a un estado donde se tenga la seguridad suficiente para proteger la informacin y los recursos del usuario pero sin interferir con las actividades que este desarrolla. Para lograr este objetivo el usuario debe contar con medios para adaptar la actividad de los diferentes mecanismos de seguridad a sus necesidades especficas. A continuacin se enumeran una serie de caractersticas que debera tener la interfaz de configuracin. 4.4.1 Sencillo Esta caracterstica busca que el usuario comn pueda manejarlo. Esto slo se puede lograr a travs de una interfaz clara (los conceptos presentados sean claros para el usuario comn) y que la informacin sea completa, es decir que cubra todos los aspectos importantes de seguridad pero no debe abrumar al usuario. Esto ltimo se puede lograr estructurando la informacin a travs de hipertexto.

4.4.2 Ampliable Debe existir una manera de ampliar las caractersticas del mecanismo de seguridad para enfrentar las nuevas tecnologas que continuamente se estn desarrollando. Los conceptos en que se basa la interfaz de configuracin deben ser suficientemente generales para ser aplicados a diferentes tipos de tecnologas. Se podra llegar a pensar en un diseo modular de los programas en el cual cada mdulo contiene unos mecanismos bsicos de seguridad estandarizados y un API que permita a la interfaz manejar la seguridad del mdulo o bloquear la ejecucin del mismo si no cumple con unos estndares mnimos predefinidos. 4.4.3 Personalizado Una computadora personal o de oficina puede ser usada por varias personas. Por lo tanto el mecanismo de configuracin debe estar en capacidad de mantener varios conjuntos de caractersticas de configuracin (perfiles en la jerga de Microsoft) de manera que se pueda adaptar a las necesidades de diferentes usuarios. 4.4.4 Protegido El sistema operativo de un computador personal no suele presentar mecanismos serios de defensa para los recursos locales en el caso que una persona extraa tenga acceso fsico a la mquina. Por lo tanto el acceso al cliente de Web y a sus recursos debe permitir proteccin con claves de acceso y los archivos de configuracin generales y personales deben estar cifrados de manera que no estn expuestos a modificaciones indeseadas. 4.4.5 Unificado El usuario que desea mejorar la seguridad de su ambiente de navegacin actualmente debe enfrentarse a la administracin de las implementaciones de las diferentes tecnologas que se integran en el agente (visores de documentos, Java, JavaScript, Activex, Plug-In, etc.). El usuario quiere que los recursos de informacin y de mquina estn protegidos, no aprender los fundamentos en que se basa cada tecnologa posible para poder configurarla. La idea es que si no desea que se pueda leer el disco duro libremente desde el cliente de Web, exista una interfaz de configuracin que permita al usuario indicarlo as y el sistema internamente haga los ajustes necesarios sobre las diferentes tecnologas. Esta no es una tarea sencilla, cada una de estas tecnologas se basan en conceptos diferentes y que pueden no ser compatibles. Una forma de solventar esto es encontrar un conjunto de conceptos comunes generales que permitan un acercamiento simplificado a la administracin del contenido que llega a travs de la red. Tambin debe existir la posibilidad de llegar a las caractersticas de bajo nivel de cada uno de los mecanismos para que los usuarios expertos puedan afinar la configuracin. Las caractersticas generales que se deben configurar para el visor son: Descarga de documentos sin firma digital: Este concepto engloba cualquier tipo de contenido, desde el documento HTML hasta las cookies pasando por contenido activo y los documentos definidos en el agente de usuario. Se refiere nicamente al proceso de obtener un documento a travs de la red y guardarlo en memoria RAM o en medio magntico. En el caso de documentos firmados digitalmente las decisiones de seguridad dependen de la confianza en la entidad firmante y no de la naturaleza del documento. En principio debe haber como mnimo tres permisos posibles: Permiso de presentacin/ejecucin: Una vez descargado el documento se puede presentar en el visor o con ayuda de una extensin Plug-In u otro programa o si se trata de cdigo ejecutarlo. Los permisos bsicos son: Acceso a medio magntico: Esto tiene que ver con cdigo ejecutable Java, ActiveX y algunos documentos con capacidad de macros. Sin embargo en este punto se empieza a perder influencia sobre algunos documentos que son ejecutados por aplicaciones invocadas automticamente por el navegador. Acceso a la red: Como en el anterior este apartado corresponde a cdigo ejecutable y tiene el mismo problema con cdigo nativo o aplicaciones. Para cada una de estas operaciones se debe tener un conjunto mnimo de opciones que puede escoger el usuario: Nunca permitir la accin (por ejemplo no permitir descargar cdigo Java).

Permitir la accin a discrecin del usuario. Por ejemplo para permitir ejecutar cdigo ActiveX se presenta una caja de dilogo con informacin sobre el componente que se va a ejecutar y opciones para aceptar o rechazarlo. Permitir la accin de acuerdo a alguna condicin. Slo aceptar contenido activo de la red interna de la compaa. Permitir la accin siempre.

Este conjunto de opciones puede ser ampliado pero se debe tener en cuenta que buscar una granularidad muy fina puede afectar el desempeo del sistema. 4.4.6 Centralizado En ambientes de organizaciones o empresas con una Intranet en las cuales se necesita garantizar unos niveles mnimos de seguridad no se puede depender de las habilidades de los diferentes empleados para configurar el cliente de Web. En este caso debe existir un mecanismo que permita a un administrador configurar los clientes desde su propia computadora de manera centralizada y remota. Resulta conveniente que el sistema de administracin se integre con el sistema de control de acceso del sistema (generalmente listas de control de acceso en Unix o Windows) con las mismas definiciones de usuarios y grupos de usuarios para que la administracin global resulte ms sencilla. Esta capacidad puede generar un problema de seguridad. Si un intruso es capaz de configurar remotamente el agente de usuario tendr a su disposicin todo el sistema y podr instalar aplicaciones, configurar errneamente la seguridad, etc., etc. Por lo tanto esta caracterstica debe estar deshabilitada por defecto o pueden existir dos versiones del visor, una personal sin el mdulo de administracin remota y otra Intranet que contenga la capacidad de administracin centralizada. 4.5 MECANISMOS DE SEGURIDAD PROPUESTOS Existen algunos requisitos generales para la implementacin de las diferentes propuestas tecnolgicas que se van a proporcionar. Eficiente: Debe tener un impacto mnimo sobre el desempeo del programa cliente de Web y del contenido activo que este presenta. Completo: Debe cubrir todos los aspectos de seguridad. Centralizado: La seguridad en el cliente de Web la debe manejar el cliente de Web y no debe estar dispersa a lo ancho y largo del cdigo, es decir, la seguridad debe estar centralizada y no debe depender solamente de las diferentes implementaciones de las diferentes tecnologas. Auditable: Debe existir la posibilidad de mantener archivos de bitcora (log) y mecanismos de auditora para hacer seguimiento a los eventos que tengan que ver con la seguridad. Flexible: Debe adaptarse a las diferentes tecnologas existentes utilizadas por los visores, a los diferentes roles que juegan los usuarios y a los diferentes ambientes en que se mueven. Extensible: Debe estar en capacidad de aceptar la presencia de nuevas tecnologas. Confiable: Debe implementarse en un lenguaje seguro y bajo rgidos parmetros de ingeniera de software para verificar formalmente su confiabilidad. Explcito: La informacin presentada en el cliente de Web acerca de las condiciones generales y puntuales de seguridad deben ser explcitas, inequvocas e imposibles de ocultar por medio del contenido. Unico: Resulta inconveniente tener un mecanismo de seguridad para cada una de las posibles tecnologas que se implementan en el programa cliente de Web. Tener un solo mecanismo o conjunto de mecanismos unificados en un diseo coherente y bien estructurado permitir ahorrar recursos, tendr un menor impacto sobre el desempeo del programa y permitir una administracin ms sencilla Independiente de las diferentes tecnologas: Es importante mantener en lo posible la independencia de cualquier tecnologa de presentacin de documentos o ejecucin de cdigo, es decir no debe basarse en caractersticas o propiedades de una tecnologa en especial.

Independiente de la plataforma: Tambin debe ser independiente de la plataforma sobre la que trabaja de manera que los mecanismos propuestos no se limiten a casos especficos. Compatible con mecanismos existentes: No debe chocar con implementaciones de seguridad previstas en otras tecnologas como Java o JavaScript.

Un requerimiento general para las casas fabricantes de programas de navegacin para cumplir muchos de los requisitos expuestos anteriormente es una correcta comprobacin de la seguridad de las diferentes herramientas tecnolgicas implantadas en los navegadores. En los primeros captulos de este trabajo se ha hablado de la acelerada introduccin de nuevos mecanismos tecnolgicos y de la adicin de capacidades a los existentes en un ambiente de fuerte competencia que obliga a una rpida sucesin de versiones cada una con nuevas habilidades. Es notorio que la preocupacin de las casas de software es que la herramienta funcione (esto en principio es correcto), pero muchas veces no se controlan los alcances de las nuevas herramientas tecnolgicas2 o el resultado de la interaccin entre diferentes mecanismos tecnolgicos3. En algunos puntos es notoria cierta lasitud de los ingenieros de desarrollo pues se ve el mismo tipo de error repetido en partes que no estn no directamente relacionadas e incluso a lo largo de diferentes versiones 4. Las empresas productoras de software deben crear y utilizar polticas y mecanismos de verificacin de sus programas de navegacin que proporcionen una mayor seguridad sobre la calidad de los programas. La implantacin de mecanismos tecnolgicos ms eficientes es intil si los programas que lo soportan no son confiables. Para hablar de mecanismos de seguridad se debe tener en cuenta que el contenido obtenido en la red puede dividirse en tres categoras de acuerdo a la forma de procesarse: Documentos procesados por el visor de Web directamente. Por ejemplo pginas HTML, grficas GIF y JPEG, texto ASCII y otros. Contenido activo procesado por interpretadores integrados en el visor como Java, JavaScript o VBScript. Contenido activo que no necesita interpretador o documentos procesados por otras aplicaciones, componentes ActiveX o Plug-In y documentos Office. Esta distribucin es conveniente para estudiar como se pueden implementar mecanismos de seguridad. Tenemos tres escenarios bsicos: el visor, interpretadores integrados en el visor y aplicaciones externas invocadas por el visor. En el visor y en los interpretadores se puede implementar el mecanismo de control de eventos directamente pues la implementacin es controlada por la compaa que desarrolla el visor. El ltimo caso es ms complicado pues una vez invocada la aplicacin en cdigo nativo se escapa al control del visor. En [GOL96] se describe una posible solucin, pero est limitada a plataformas que cuentan con primitivas para control de eventos con lo cual se pierde la independencia de la plataforma. Sin embargo, este documento presenta ideas que pueden ser utilizadas para mantener control sobre aplicaciones en cdigo interpretado sin afectar gravemente el desempeo del sistema. Por otro lado [NEC97] propone un mecanismo que parece ser eficiente y que permitira tratar cdigo en cualquier escenario pero todava falta experimentacin concluyente en casos reales. No se conoce una solucin simple a este problema y se debe llegar a soluciones de compromiso entre las necesidades de seguridad y el cdigo ejecutable perdindose uno de los objetivos, que los mecanismos de seguridad sean independientes de las tecnologas utilizadas.
2

Esto resulto notorio con la adicin de programas para ver documentos que no eran soportados directamente por el navegador (helpers) y que no tenan ningn control de seguridad permitiendo incluso invocar comandos del sistema operativo sin ningn control. 3 por ejemplo el uso de JavaScript y marcos HTML para robar informacin o el uso de la marca file de formas HTML y la capacidad de copiar y pegar programable de VBScript para robar archivos del disco duro. 4 Es absurdo que hayan aparecido problemas de desbordamiento de buffer en la interpretacin de diferentes marcas DHTML en diferentes versiones de programas de navegacin cuando es un error clsico y que ha sido estudiado hasta la saciedad.

Dado que algunas de las tecnologas que enriquecen el visor de Web tienen sus propios mecanismos de seguridad, se debe asegurar que siempre prima la definicin ms restrictiva. 4.5.1 Sistema de control de eventos de seguridad. Una caracterstica apropiada en un visor seguro es un sistema de control de eventos que permita controlar el estado de hechos puntuales que afectan a la seguridad y definir reacciones del ambiente de navegacin frente a estos eventos. Por ejemplo, si en una pgina que ha sido cargada por el visor de Web aparece contenido no aceptable se puede tomar una decisin de desechar la pgina y presentar un mensaje de error, presentar el documento sin el contenido inaceptable o presentar un dilogo de decisin al usuario. De esta manera la aplicacin de las dems tecnologas de seguridad no depende de en que lugar de cdigo es invocada cierta funcin, sino que se cuenta con un mecanismo configurable desde el cual son llamados los diferentes mdulos. Este mecanismo ofrece la capacidad de mantener control con una granularidad bastante fina, sin embargo debe tener una configuracin bsica que sirva para los casos ms comunes que se suceden en el ambiente de navegacin. De esta manera no se obliga al usuario a enfrentarse, si no est en capacidad de ello o no lo desea, a una configuracin que puede ser complicada. La configuracin de este mecanismo debe permitir definir el comportamiento del agente de usuario en respuesta a los diferentes eventos. Por ejemplo que se pueda definir si se debe mostrar o no una hoja que tiene referencias a contenido activo que no es aceptado por la seguridad del sistema (el contenido activo no se descarga o ejecuta) e incluso indicar que programa antivirus se debe ejecutar cuando se obtiene un archivo ejecutable a travs de la red. Con este mecanismo tambin se puede configurar los mensajes de aviso que se presentan en algunos casos de manera que sean ms claros. En caso de que exista un mecanismo de administracin remota centralizada deben poderse definir tambin reacciones a eventos de seguridad en el sistema central. De esta manera el administrador puede tener un mayor control sobre el estado de seguridad en la Web. 4.5.2 Sistema de bitcora Un sistema de seguridad debe permitir mantener archivos de bitcora donde se puedan registrar los eventos de seguridad relevantes, por lo tanto se complementa con el sistema de control de eventos. Debe existir una configuracin bsica que permita definir que eventos se consideran relevantes y se deben registrar. Como en el caso anterior si existe un sistema centralizado de administracin, este debe estar en capacidad de presentar el contenido de la bitcora de un visor en algn computador ya sea por que accede remotamente al archivo de bitcora (lo cual limita el funcionamiento a periodos en que el computador remoto este activo) o tenga una copia local de las bitcoras de todos los computadores de la Intranet(consume medio magntico). 4.5.3 Archivos de configuracin seguros Un ambiente de navegacin muy comn es el de la computadora personal familiar a la cual tienen acceso toda la familia y los amigos, o una PC en una oficina que es compartida por varias personas. Esto crea un problema de seguridad, si no se puede prevenir el acceso fsico al PC debe existir un mecanismo que evite modificaciones indeseadas a la configuracin del visor de Web. Por lo tanto el sistema de configuracin para las caractersticas de seguridad debe estar en capacidad de aceptar una clave de acceso, de hecho los visores actuales tienen esta opcin. Los archivos de configuracin deben estar cifrados de manera que no se puedan modificar mediante editores de texto o programas especiales y deben existir diferentes conjuntos de especificaciones de configuracin para cada usuario. 4.5.4 Control de recursos Resulta conveniente un mecanismo que permita conocer qu recursos se estn utilizando a travs del visor de Web. De esta manera el usuario o el mecanismo de control de eventos puede verificar que no se est abusando de recursos del equipo o de la informacin de manera indebida. Adems resulta til a la hora de evaluar un sitio Web desconocido o para depurar pginas Web que se estn desarrollando. Los principales tems a controlar son: Sockets abiertos en modo servidor: La implementacin actual de Java permite crear sockets en modo servidor, por lo tanto se puede crear un applet que ofrezca servicios hacia el exterior. Esto, combinado con algn otro ataque puede crear una brecha de seguridad grave.

Sockets cliente abiertos: Un applet puede crear conexiones slo con el servidor de donde proviene, de esta manera se busca evitar el desvo de informacin hacia una tercera parte. Sin embargo se puede usar esta caracterstica para utilizar algn servicio como un servidor de correo o tal vez FTP para que la informacin sea enviada a otro computador. Slo se debe permitir abrir sockets a applets plenamente confiables. Memoria y uso de CPU: Un ataque sencillo de realizar y por lo tanto relativamente frecuente se basa en la repeticin sin fin de alguna accin que consume recursos (abrir ventanas, cambiar de color el fondo del documento, etc.). El sistema de control debe estar en capacidad de mostrar el porcentaje de uso de estos recursos para evitar ataques de negacin de servicio. Instancias del programa visor: Es poco probable que un usuario necesite 1000 instancias de un visor para navegar por Internet; sin embargo, el no controlar este hecho permite a algunas aplicaciones consumir memoria y tiempo de CPU hasta bloquear el sistema que soporta al programa visor. Mtodos Get y Post: Existen mecanismos para enviar archivos al servidor por medio de formas, esta capacidad se puede usar para obtener archivos locales sin permiso del usuario. De manera que aquellos mtodos que cumplen algunos parmetros (un tamao superior a un mnimo esperado o el hecho de que algn argumento tiene formato de Path) deben ser notificados al usuario. Frames: Algunos ataques de robo de informacin se pueden desarrollar desde marcos de tamao cero que el usuario no puede ver, de manera que los marcos de caractersticas poco comunes deben presentarse en este mecanismo.

El mecanismo puede generar eventos que podran utilizarse en el sistema de control de eventos, de esta manera se pueden implementar alarmas cuando ocurre una situacin que se ha definido como indeseable. 4.5.5 Cdigo interpretado Los diferentes interpretadores de cdigo deben implementarse a partir de un grupo de rutinas seguras nico. Este conjunto de rutinas debe constituir un API de seguridad que los ingenieros de desarrollo puedan utilizar a la hora de implementar los programas interpretadores. De esta manera se busca simplificar el cdigo para disminuir la posibilidad de errores y facilitar el mantenimiento. El concepto base de este mecanismo es que debe existir una poltica de seguridad nica y no una poltica de seguridad por cada tecnologa que est implementada en el visor. Existen algunos puntos a tener en cuenta a la hora de implementar esta medida: Diferencias entre las diversas tecnologas: Java Script, Java, VB Script, etc. tienen diferentes usos y radios de accin, por lo tanto sus necesidades de medidas de seguridad son diferentes. Por ejemplo un script no est en capacidad de abrir sockets para comunicaciones por lo tanto no debe preocuparse de ese aspecto, en cambio Java si considera este un asunto importante. Por lo tanto el conjunto de rutinas debe abarcar todos los aspectos de seguridad que puedan requerir las diferentes tecnologas para que cada implementacin de interpretador pueda hacer uso de las funciones que requiere. Intereses de las compaas productoras de visores: Es notorio como cada marca de visor presenta sus propias tecnologas de manera diferente a como soporta las tecnologas creadas en otras casas de software. Es muy probable que la idea de mantener el mismo nivel de restriccin para todas las tecnologas no agrade a las compaas pues en general intentan mostrar sus creaciones como la opcin ms dinmica e interactiva del mercado y por lo tanto tener un API nico de seguridad para todas ellas proporciona un equilibrio entre las diferentes tecnologas que puede resultar inconveniente desde el punto de vista comercial. Compatibilidad con normas de la industria: Algunas tecnologas se basan en normas de la industria o en normas privadas (por ejemplo Java cuya norma es dictada por Sun). Se debe estudiar con cuidado la implementacin para no provocar incompatibilidades con las diferentes normas pues esto puede tener consecuencias importantes.

4.5.6 Reforzar la caja de arena de Java El estudio de los diferentes problemas de seguridad indican que se deberan tomar algunas medidas en la caja de arena para mejorar la seguridad de las aplicaciones para Web: Atar los applets a la pgina que los contiene. Actualmente un applet puede seguir ejecutndose despus que el documento en que estaba incrustado ha sido descartado, esto resulta inconveniente pues permite Proteger los threads de accesos indeseados. Un applet tiene acceso a los hilos de control de los otros applets que estn ejecutndose en la misma mquina y esto resulta inconveniente. En algunos casos esta capacidad puede resultar conveniente, pero jams se debe permitir que haya visibilidad entre applets de diferentes documentos. Control en el usuario de los recursos a los que tiene acceso la Mquina Virtual Java y los applets que sobre ella se ejecutan. De esta manera un applet que est firmado por una entidad confiable y que ha sido aceptado no puede ejercer influencia sobre todo el sistema sino que se puede restringir el ambiente sobre el que va a trabajar.

5. ALGUNAS PROPUESTAS EXPERIMENTALES PARA MEJORAR LA SEGURIDAD

Existen una serie de propuestas experimentales que no se aplican actualmente pero que proporcionan nuevas luces acerca de la problemtica de seguridad en el ambiente de Web. En este captulo se presentan algunas de las ms importantes para mostrar el estado actual de la investigacin. 5.1 FILTRO PARA JAVA Es una propuesta de Dirk Balfanz y Edward Felten del grupo Programacin Segura para Internet (SIP segn sus siglas en ingls) para mejorar los niveles de seguridad en Java. Segn los autores existen dos razones para buscar nuevos mecanismos de seguridad en Java: EL estado de seguridad actual no es confortable para una gran cantidad de usuarios, por lo tanto no usarn este mecanismo. Los mecanismos actuales de seguridad son excesivamente restrictivos o presentan problemas importantes. La propuesta es disponer un mecanismo que permita desactivar selectivamente el soporte para Java del explorador. De esta manera applets no confiables pueden ser evitados sin afectar la ejecucin de los applets confiables. El mecanismo se basa en la clase Applet ClassLoader. Cada vez que el ambiente de ejecucin de Java requiere la presencia de una nueva clase, se crea una instancia de esta clase para recibir el archivo que contiene la clase e integrarlo al ambiente de ejecucin y pueda ser utilizado desde el resto del programa Java. Para no interferir con el cdigo existente se decidi crear una nueva clase AppletClassLoder que heredase todas las caractersticas de la clase actual. Renombraron la clase original de AppletClassLoader a XppletClassLoader y crearon una nueva clase AppletClassLoader heredera de XppletClassLoader. No se incluy toda la funcionalidad del filtro de Java en la AppletClassLoader, si no que desde ella llama a los objetos que necesita, basta con adicionar los archivos correspondientes a la librera de clases del sistema. El constructor de la nueva clase llama al constructor de XppletClassLoader y al objeto que realmente realiza la funcin de filtrado. El funcionamiento de esta herramienta es sencillo. Cuando se invoca el AppletClassLoader para traer una clase remota uno de los argumentos proporcionados es la direccin URL de donde proviene la clase. El nuevo AppletClassLoader pasa este argumento al objeto guardin en su constructor. El objeto guardin puede decidir con base en una lista ordenada de lugares en la red confiables o no confiables. Si la direccin no aparece en la lista, el sistema presenta al usuario una caja de dilogo con informacin acerca del applet y la da la oportunidad de decidir si se debe permitir o no la ejecucin del applet y si esta decisin debe ser almacenada para futura referencia la lista ya mencionada. Si la decisin es negativa (ya sea automtica o manual) el objeto guardin lanza una excepcin, por lo tanto AppletClassLoader detecta un error y termina ejecucin sin siquiera haber invocado la clase XppletClassLoader que traera la clase remota. Ventajas: Las clases no confiables ni siquiera son transportadas al sistema local pues en caso de que el objeto guardin la rechace, el objeto que se encarga de traer el applet remoto al sistema local no ser invocado. Encaja bien con el diseo general de Java. Puede funcionar bien en Intranets corporativas en las cuales la configuracin del navegador es realizada por un administrador central. Desventajas: La solucin es especfica de Java,

La decisin de permitir la descarga de un applet se basa en la direccin de donde proviene el applet. La herramienta no cuenta con mecanismos para distinguir entre applets firmados y no firmados. Se vuelve a un problema recurrente, el usuario comn no tiene herramientas para decidir que applet es bueno o malo.

5.2 AMBIENTE SEGURO PARA VISORES DE DOCUMENTOS Ian Goldberg, David Wagner, Randi Thomas y Eric Brewer de la Universidad de California tratan de paliar uno de los problemas ms graves en el cliente de WWW, como proporcionar mecanismos de seguridad que cubran aplicaciones que son invocadas por el navegador pero que no estn diseadas para tratar con los problemas inherentes a documentos que son obtenidos a travs de la red. La motivacin inicial ya es conocida, los visores de documentos (Word, Excel, Ghostview y otros) son programas grandes y por lo tanto propensos a presentar errores, pueden permitir ejecucin de comandos del sistema o poseer complejos lenguajes de macro que pueden ser mal utilizados. Estos programas pueden ser utilizados en ataques basados en datos (data driven attacks) para producir daos o robar informacin. La solucin propuesta se conoce como Janus y consiste en un ambiente en el cual se puede monitorear y restringir las llamadas al sistema de una aplicacin. Bsicamente se busca crear una sencilla sand box para aplicaciones utilizadas como visor. EL estudio de las diferentes aproximaciones para crear este ambiente de ejecucin seguro es interesante y presenta ideas que pueden ser aplicadas en otros casos. Construir los mecanismos de seguridad directamente en cada aplicacin visor. Esto significa que se deben reescribir todas las aplicaciones lo cual es un trabajo monumental. Cada aplicacin debe ser considerada aparte. Los autores desechan esta idea inmediatamente pues no consideran una aproximacin prctica. En principio, considero que no se puede confiar en unos mecanismos de seguridad implementados en cada uno de estos programas pues son muchos y muy diversos programas e inevitablemente alguno tendr fallas o conflictos de polticas de seguridad. Sin embargo, el mercado actual se orienta a computadoras que estn conectadas a la red, por lo tanto las aplicaciones tradicionales deben modificar los paradigmas sobre los que estn diseadas. Las aplicaciones deben contener mecanismos de seguridad para proteger a sus clientes en la misma forma que algunas ya implementan mecanismos para protegerlos contra sus propias capacidades de macros. Por ello es importante que los usuarios tomen conciencia de la necesidad de seguridad de manera que se reconozca la necesidad de tener programas preparados para soportar documentos no confiables y la industria se vea obligada a moverse en esta direccin. Adicionar nuevas medidas de seguridad en el sistema operativo. Esta aproximacin es inconveniente tambin, entre otras razones por que la implementacin de medidas de seguridad en el kernel del sistema operativo es muy arriesgado pues un error de programacin puede abrir las puertas a nuevos problemas de seguridad. De nuevo mi posicin es que no se puede confiar en el S.O., el navegador debe ser seguro por si mismo y no puede presumir nada sobre el ambiente en que est instalado. Sin embargo los sistemas operativos deben ser desarrollados teniendo en cuenta que el usuario actual est conectado a la red y que se mueve en un ambiente no confiable. Monitor de referencias preexistente. Este mecanismo es particularmente reactivo, previene que se propague el dao (tpicamente otras cuentas de usuario) pero no impide que este se produzca e histricamente solo ha servido para asegurar que el atacante tiene un mnimo de conocimientos. Firewall.Los filtros de paquetes y los mecanismos de proxy parecen no tener nada que hacer aqu. Para empezar son sistemas de todo o nada, lo cual es o demasiado permisivo o demasiado laxo. OJO permisivo y laxo tienen la misma idea??? Adems, difcilmente se puede tener un firewall que reconozca todos los tipos posibles de documentos para

bloquearlos. Un firewall que explore los documentos para buscar datos inconvenientes para decidir si lo permite o no sera lento y complejo (es decir propenso a errores). En vista de lo anterior., los autores proponen una solucin en el mbito de aplicacin basada en la siguiente presuncin: Una aplicacin puede hacer poco dao si su acceso al sistema operativo que la soporta es restringido apropiadamente. Es decir la aplicacin puede desarrollar todas las tareas que no requieran de llamadas al sistema, entonces y slo entonces el ambiente de ejecucin deber tomar una decisin de seguridad. Aunque puede haber discusin sobre qu significa una restriccin apropiada, en general el concepto es aceptable. La solucin debe contar con las siguientes caractersticas: Seguro: La aplicacin no debe tener acceso al sistema operativo o a la red por fuera del ambiente de ejecucin. Adems el sistema debe ser simple lo cual ayuda a prevenir errores. Versatil: El sistema debe estar en capacidad de permitir o negar una llamada al sistema flexiblemente, tal vez con base en los argumentos a la llamada al sistema. Configurable: Diferentes lugares tienen diferentes requisitos. Los autores dejan claro que su solucin no trata el problema de la seguridad de la aplicacin en si misma, es decir no la protegen de sus propios errores como lo hacen otros ambientes de ejecuci al estilo de Crash Guard de Norton. El sistema no impide invocar cualquier programa que el usuario desee y que deja que este funcione a su antojo dentro de su espacio de direcciones. El sistema esta divido en un framework configurable y un conjunto de mdulos especializados en diferentes aspectos de las politicas de seguridad mediante el filtrado de llamadas al sistema. De acuerdo con el tipo de documento que se intenta abrir y de la configuracin, el framework llamar diferentes mdulos cada uno de los cuales est en capacidad de filtrar un conjunto especfico de llamadas al sistema. Algunos mdulos pueden tener llamadas al sistema en comn pero slo se permitir la llamada si alguno de los mdulos explicitamente as lo permite. El filtrado se realiza con base en el anlsis de los argumentos de la llamada al sistema de manera que se evita que la llamada sea ejecutada si no se considera conveniente. Algunos mdulos pueden ser putenv (controla modificacin de variables de ambiente), display (protege la pantalla), tcpconnect (restringe acceso a conexiones TCP) o path (filtra accesos a medio magntico). Cada vez que el navegador invoca una aplicacin externa se ejecuta primero el framework el cual carga los mdulos convenientes para el documento y en seguida llama a la aplicacin externa. En caso que la aplicacin intente crear otro proceso hijo, el ambiente de ejecucin creara otro ambiente de ejecucin sobre el cual se ejecutar el hijo hasta que termine. Cuando el programa incoa una llamada al sistema, el framework toma el control y analiza los argumentos, si es aceptada devuelve el control al programa, si no produce un error de sistema que muestra al programa que fall la interrupcin. Si la aplicacin persiste en intentar la invocacin de la llamada al sistema se mata el proceso de la aplicacin y se presenta un mensaje explicativo al usuario. Ventajas El sistema es eficiente, los programas son interrumpidos nicamente en las llamadas a sistema que se consideran crticas. Se cubren aplicaciones ya existentes o futuras de cualquier naturaleza sin que estas tengan que ser modificadas para integrar mecanismos de seguridad. La granularidad es adecuada. El desempeo del sistema no se ve afectado sensiblemente. Desventajas: El sistema descansa sobre caractersticas del sistema operativo que no son comunes. En este caso mecanismos de seguimiento de llamadas al sistema se basa en el sistema de archivos

virtuales /proc que proporcionan Solarix 2.4 y OSF/1. Por lo tanto es dependiente del sistema operativo. La administracin puede ser compleja. Los autores consideran que debe existir un administrador del sistema. En un ambiente casero esto no va a existir.

5.3 ESPACIOS DE OBJETOS SEGUROS Esta propuesta de Jan Vitek de la Universidad de Ginebra busca crear una infraestructura para la interactividad segura en comunidades poco acopladas (loose) en ambientes de plataformas heterogneas, especialmente en procesos crticos como transacciones comerciales. La propuesta consiste en un nuevo mecanismo de control de recursos e interaccin entre agentes de usuario que es parte de un nuevo lenguaje de programacin llamado SEAL. El trabajo se enfoca ms en la proteccin del agente que de la plataforma que lo alberga. La motivacin es que mientras que la seguridad de la plataforma es importante, la del agente lo es ms pues es el que lleva la responsabilidad de realizar procesos sensibles a la seguridad en un ambiente no confiable. Los mtodos clsicos de seguridad integrada en el lenguaje son refutados. La tipificacin (typing) esttica y encadenamiento dinmico propios de Java se considera inconveniente pues originalmente son concebidos para reforzar el proceso de ingeniera de software y no de seguridad, por lo tanto muestra algunas debilidades. El hecho de que en la implementacin 1.1.2 de Java se pudiese confundir a la JVM entre una clase del sistema y una clase remota mediante un proceso no demasiado complejo apoya esta consideracin. Adems generalmente las interfaces de un objeto son estticas y los derechos de acceso y las condiciones de confiabilidad son dinmicas. Por otro lado el chequeo de seguridad a nivel del objeto suele tener un alto costo en tiempo de ejecucin. Sin embargo los resultados presentados por Goldberg y compaa en su propuesta presentada en 5.2 parecen indicar que se puede desarrollar seguridad a nivel de objetos sin tanto impacto en el desempeo. La base del sistema se conoce como comunicacin generativa como una alternativa al paso de mensajes al estilo del modelo LINDA para proceso paralelo. En linda los procesos se comunican por medio de tuplas que se almacenan en una estructura de datos compartida (el espacio de tuplas). El espacio de tuplas se comporta como una memoria asociativa en la cual las tuplas son recuperadas por medio de pattern matching. Con base en este modelo se crea un nuevo mecanismo llamado Espacio de Objetos Seguros (SOS por sus siglas en Ingls) que ampla el modelo LINDA haciendo nfasis en la comunicacin entre procesos que pueden tener objetivos conflictivos. El modelo se basa en un rea activa llamada espacio de agentes en el cual se encuentran los agentes en ejecucin y un espacio pasivo, el espacio de objetos. El SOS controla la ejecucin de los agentes en el rea activa, responde a solicitudes de memoria, controla la escritura y lectura de tuplas en el rea pasiva. SOS no es distribuido y por lo tanto toda la comunicacin es local, esto lo distingue de algunas implementaciones de LINDA que ofrecen espacios de trabajo distribuidos. Cada agente es identificado por una tupla de cinco elementos (a, g(a), ID, PK, SK, T) donde g(a) es un grafo de objetos cuya raz est en el objeto a, ID es el identificador del agente, PK es una llave pblica, SK es una llave secreta y T es un conjunto de hilos de control (threads). El rea pasiva contiene tuplas de diferentes longitudes y los valores que contienen estn limitados a un restringido conjunto de tipos, Integer, mutableString, Character, Real, PrivateKey, PublicKey, y Capsule. No se permite la redefinicin de estos tipos. El corazn de la comunicacin se basa en cinco mensajes, out para escribir valores, in y rd para recuperar valores, mkKey para crear un nuevo par de llaves pblica y secreta y keyFor para obtener la llave de un agente. Los datos de tipo cpsula contienen una porcin del estado del objeto con la garanta que no existen referencias entre el contenido de la cpsula y el resto del sistema. De esta manera se pueden intercambiar tipos complejos de datos sin comprometer la seguridad al dejar referencias que permitan ver el estado interno de un objeto. Para crear una cpsula se proporciona una identificacin a una porcin del grafo de objetos y se separa del grafo para asegurar que no

queda ninguna referencia. El contenido de la cpsula es pasivo y slo puede ser abierta una vez. Esto produce un encapsulamiento ms fuerte que el tradicional de la programacin orientada a objetos. El proceso de pattern matching consiste en buscar tuplas que encajen con una antitupla. Una antitupla es una tupla en la cual no todos sus elementos tienen valores. En una antitupla los elementos pueden contener un valor literal o un formal que puede ser un identificador con especificacin de tipo o un comodn que indica que acepta cualquier cosa en reemplazo. En el lugar de elementos de tipo PrivateKey o PublicKey slo se permiten literales, es decir se obliga a que exista un valor definido contra el cual contrastar la llave. Para seleccionar una tupla, todos los literales deben coincidir y los formales deben encajar. En el caso de las llaves una tupla que tiene un valor de tipo PublicKey slo encaja con una antitupla que tenga el valor correspondiente de PrivateKey. Las llaves son administradas por el SOS y no se basan en mecanismos de criptografa asincrnica. El SOS mantienen control sobre las llaves que conoce cada objeto de manera que ninguno pueda adivinar la llave privada de otros. Para intercambiar informacin entre objetos se pueden definir llaves secretas compartidas. Ventajas Es una base para el desarrollo de aplicaciones seguras y por lo tanto puede tener un manejo similar al de Java pero con una fundamentacin ms profunda.

Desventajas Esta orientado a una herramienta particular, no es una solucin generalizable. La seguridad depende de objetos construidos pensando en dicha seguridad, a diferencia de Java que provee un ambiente seguro para objetos diseados libremente. La proteccin de la plataforma es importante, sin embargo este modelo no la tiene en cuenta. 5.4 PRUEBA CONTENIDA EN CDIGO Controlar la seguridad en programas desarrollados en cdigo nativo es un problema grave y difcil de manejar dado que, como ya se ha visto, no es sencillo confinarla en una sand-box y las firmas digitales que permiten reconocer al autor de una pieza de cdigo tienen una utilidad limitada. George Necula de la Universidad Carnegie Mellon propone el mecanismo de Prueba Contenida en Cdigo para determinar si una pieza de cdigo es segura; es decir, se ajusta a una poltica de seguridad. Para lograr esto el creador del cdigo debe proporcionar una prueba de seguridad que certifique que el cdigo se ajusta a las polticas de seguridad sin necesidad de acudir a tcnicas de cifrado o recurrir a una entidad certificadora externa. El usuario del cdigo tambin verifica que la prueba es vlida y corresponde al cdigo al que est vinculada y de est manera puede decidir si confa o no en el cdigo obtenido por medio de la red. Esta tcnica permitira que programas Plug-In o ActiveX y extensiones en cdigo nativo de applets Java pudiesen probar que son seguros antes de ser ejecutados en el visor. Adems los programas desarrollados en lenguajes interpretados como Visual Basic Script o Java tambin pueden hacer uso de este mecanismo para verificar que el cdigo es seguro. La implementacin de este mecanismo asegura que algn intento de modificar el cdigo o la prueba causarn un error en la verificacin en la mayora de los casos. Por otro lado, si la manipulacin del cdigo y/o la prueba resultan en una verificacin vlida, el cdigo resultante ser seguro, es decir, se apega a las polticas de seguridad aunque probablemente desarrolle acciones diferentes de las pensadas originalmente. Una vez que el consumidor del cdigo ha verificado la validez de la pieza de cdigo no necesita repetir la verificacin para ejecuciones posteriores. Esto crea un problema adicional que el autor no menciona. Cuando se ha probado que el cdigo es seguro antes de la primera ejecucin, se

debe probar de alguna manera en ejecuciones posteriores que en realidad se est ejecutando el cdigo probado y que no se ha suplantado una pieza de cdigo con otra que pueda desarrollar actividad indeseable. Una solucin rpida es utilizar un mecanismo de digest que el mismo productor del cdigo puede asociar al archivo binario y que el usuario puede verificar antes de ejecutar el programa. Un mecanismo de comprobacin de digest resultar mucho ms simple que el mecanismo de verificacin de seguridad que tiene que verificar cada lnea de cdigo contra las reglas de la poltica de seguridad. El primer paso para que esta metodologa tenga xito es crear una poltica de seguridad y plasmarla para que el programa de certificacin pueda crear la prueba de seguridad. Esta poltica debe ser creada por una entidad que sea confiable tanto para el creador de cdigo como para el consumidor del mismo. El autor slo plantea el caso de una poltica de seguridad aceptado por ambas partes; sin embargo, sta puede no ser la situacin en la vida real. Los visores ms populares suelen presentar implementaciones ligeramente diferentes de las diversas tecnologas. Es probable que en el caso de que los visores adopten este tipo de tecnologa, cada implementacin posea caractersticas diferentes en alguna medida. Por lo tanto resulta conveniente dirigir la investigacin para el caso en que los procesos de certificacin y de verificacin se desarrollan con base en conjuntos diferentes de reglas de seguridad. En caso que el conjunto de reglas contra las cuales se certific el cdigo sea un hiperconjunto de las reglas contra las cuales se validar, es decir las normas de seguridad mnimas se decidiran en le visor y slo aquellos programas que hayan sido certificados contra un conjunto de normas similar o ms estricto sera aceptado. Esto quiere decir que la prueba de seguridad de cdigo debe ser vlida para el proceso de certificacin y para el proceso de verificacin bajo conjuntos de reglas que no son exactamente iguales. Ventajas Con esta metodologa se puede tener un mecanismo de seguridad de contenido activo nico sin importar como se ejecuta este cdigo. Dado que la verificacin slo se hace una vez cuando se va a ejecutar el programa por primera vez, la ejecucin debe ser mucho ms eficiente que en el caso de esquemas de caja de arena en el cual se controla la seguridad en tiempo de ejecucin. Esta metodologa es apropiada para mantener seguridad entre diferentes piezas de cdigo de diverso origen que interactan entre s. Desventajas Como lo seala el mismo autor, el generar pruebas de certificacin de cdigo requiere un trabajo manual intenso por parte del productor de software e incluso puede requerir el uso de costosas herramientas de anlisis de cdigo de manera que el cdigo presentado contenga invariantes apropiadas que permitan a los programas de certificacin y verificacin desarrollar su trabajo eficientemente. Las pruebas de esta metodologa se han desarrollado sobre cdigos cortos y no existe aun garanta sobre la extensibilidad de esta metodologa para programas de tamao normal. Idealmente debera existir compiladores-certificadores que puedan generar cdigo y la prueba de seguridad en paralelo pero se han desarrollado pocas experiencias en este campo. El trabajo se ha desarrollado con base en lgica de primer orden, sin embargo resulta conveniente ampliarlo a lgicas ms expresivas como lgica lineal o lgica temporal. Por lo tanto la complejidad de la implementacin puede crecer apreciablemente y la viabilidad de esta tecnologa queda en entredicho.

6 VERIFICADOR DE SEGURIDAD
6.1 JUSTIFICACION Se considera que el principal problema de inseguridad en la red es el desconocimiento de la relacin real del navegador con Internet, de los problemas que pueden surgir y de cmo resolverlos. Por lo tanto resulta necesario un mecanismo que provea dicha informacin al usuario. Existen muchas pginas Web en la red que se dedican a tratar uno u otro problema especfico de seguridad muchas veces utilizando lenguaje muy tcnico y otras con muy poca profundidad. Si una persona desea buscar todos los problemas de seguridad que afectan al cliente de Web que est utilizando deber realizar un gran esfuerzo. Si cambia de cliente de Web (marca o versin) deber volver a buscar por todo el WWW. Este trabajo busca proporcionar al usuario informacin sobre la seguridad de su ambiente de trabajo con una aplicacin basada en Web que expone las debilidades del visor y las posibles soluciones existentes, es decir un Verificador de Seguridad en Clientes de Web. Este verificador consiste en un conjunto de pginas Web que contienen la inteligencia para detectar fallos de seguridad en el cliente de Web al estilo como lo hace SATAN con mquinas UNIX. Con el VSCW presenta la informacin resultante de manera centralizada y estructurada constituyndose en una herramienta apropiada para que el usuario pueda crear un ambiente ms seguro para trabajar en la Web. Mucha gente tiene reservas acerca de la conveniencia de presentar informacin que revela la falta de seguridad en la red. La ms comn es la idea de que se est promocionando los ataques a la red al exponer informacin que permite replicar estos ataques. Este es un punto que ha generado largas discusiones (la mayora bastante ridas). Normalmente una persona que esta empeada en hacer dao buscar y encontrar informacin tarde o temprano, mientras que, una persona que necesita hacer uso de la Web no dispone muchas veces del conocimiento o el tiempo para buscar informacin de cmo defender su sistema, por lo tanto el presentar la informacin en un lugar centralizado, de fcil acceso y disponible para todo el mundo significa poco para un hacker y mucho para un usuario. Por otro lado, la similitud de este proyecto con SATAN puede hacer pensar que al igual que SATAN se puede utilizar para descubrir agujeros de seguridad en un sistema para despus atacarlo. El caso es diferente, estamos hablando de clientes de Web que deben conectarse explcita y voluntariamente al servidor que contiene el verificador, un atacante potencial debera lograr atraer a la vctima a su sitio Web y convencerla de pasar por el verificador antes de poder desarrollar un ataque. Esto resulta ser muy tortuoso, enrevesado y no tiene garanta de xito. Sin embargo se considera conveniente implementar un mecanismo que permita verificar que el conjunto de pginas pertenece a una fuente conocida y confiable. Matthew D. Healy expone algunos metarriesgos que pueden surgir al revelar las fallas de los clientes de Web en http://tbtf.com/aresource/metarisks-mh.html. El artculo est dirigido especficamente contra los reportes de fallos que son diferentes a est trabajo en filosofa y metodologa, sin embargo se considera conveniente dar respuesta a estos argumentos para apoyar la validez y conveniencia de este trabajo. Los metarriesgos que considera Healy son los siguientes: La reaccin del nio-que-gritaba-lobo. La gente puede empezar a ignorar los reportes sobre Otro Problema De Seguridad En La Web. Segn este argumento si los usuarios se acostumbran a los problemas de seguridad en la Web, entonces perdern inters en ellos. Sin embargo, para acostumbrarse deben estar expuestos por lo menos a los conceptos de problemas de seguridad, es decir existir un conocimiento bsico lo cual en s es bueno. Por otro lado, parece que se est haciendo una generalizacin a la ligera. La creacin de una conciencia entre los usuarios acerca de la seguridad en la Web empieza por informarles de los riesgos a los que estn expuestos. Miedo exagerado que har que los usuarios se alejen de la red. Una de las causas de la paranoia es la abundancia de verdades a medias. Si una persona no conoce la diferencia

entre una conexin segura y una conexin abierta, no puede entender que se puede hacer transacciones con alto nivel de seguridad sobre la Web ni podr decidir si la Web es un mecanismo ms o menos seguro o eficiente que otras formas tradicionales de transaccin. La seguridad 100% es un mito. Las personas deben estar en capacidad de conocer los mrgenes de seguridad para poder manejarlos. Aquellos que estn a favor de estrechas medidas de control gubernamental sobre Internet pueden utilizar la informacin de fallos de seguridad como evidencia de que no se puede confiar en la comunidad de la red para manejar una infraestructura de comunicaciones que crece y evoluciona rpidamente. Considero ms importante resolver un problema real actual que uno posible en el futuro. No existen mecanismos suficientemente eficientes ni parmetros universales para calificar la informacin que aparece por la red y restringirla. Por ejemplo, Cmo se puede distinguir un comic para nios de uno para adultos?, La maja desnuda de Goya se considera pornografa?. Por otro lado, existen multitud de grupos y empresas que veran afectados sus intereses por decisiones de este tipo y disponen de tiempo, dinero y diferentes motivaciones para realizar la defensa de la libertad de expresin en la red.

Intentos precipitados para arreglar los errores conocidos por programadores inexpertos y que son implementados con prisa pueden causar ms errores. La raz principal de los agujeros en la Web es la presin que el mercado ejerce sobre los programadores para implementar nuevas caractersticas rpidamente, sin tiempo para hacerlo correctamente. Este punto en especial no atae directamente a este trabajo, pero subraya la importancia de que la informacin presentada haya sido comprobada previamente. 6.2 DEFINICION El Verificador de Seguridad para clientes Web es un conjunto de pginas HTML y DHTML, cdigo JavaScript, VisualBasicScript y Java que permiten verificar la existencia o ausencia de problemas de seguridad conocidos en un cliente de Web. Existen algunas restricciones al tipo de fallas que se van a analizar. Primero se va a trabajar sobre problemas de seguridad que ocurren al obtener documentos en la red, los problemas debidos a acceso fsico al computador que contiene el visor no son tenidos en cuenta. Adems se va a trabajar solamente sobre agujeros de seguridad que no requieren una preparacin previa, por ejemplo el proceso para atacar un computador dentro de una Intranet protegida con un firewall por medio de Java requiere un laborioso proceso de DNS spoofing previo que resultara muy complicado simular en un ambiente seguro. Jams se puede estar seguro de que se conocen todas las fallas de un cliente en especial, la industria de herramientas Web es altamente competitiva y frecuentemente aparecen nuevas versiones de programas visor y una seleccin esttica de clientes de Web se vera desactualizada rpidamente. Adems algunas fallas dependen de los mdulos plug-in, de la configuracin especfica del cliente de Web o del sistema operativo sobre el cual se est ejecutando, de manera que no se puede predecir todos los posibles casos que se pueden presentar. Por lo tanto el sistema debera ser actualizado peridicamente y la estructura debe permitir la comprobacin de las diferentes configuraciones posibles. En principio no se desea hacer ninguna restriccin sobre las marcas, versiones de los clientes de Web o los sistemas operativos sobre los que se ejecutan. Sin embargo, dado que esta es una tesis y existe lmite de tiempo, se escogi un conjunto de marcas y versiones especfico como demostracin de que el proyecto es viable y efectivo. La seleccin de clientes de Web se basa en la popularidad del mismo (nmero potencial de usuarios que se beneficiaran) y la cantidad de informacin disponible. El verificador se orienta hacia Navegador de Netscape versiones 3.0 a 4.5 y Explorador de Microsoft versiones 3.0 a 5.0. 6.3 ESPECIFICACIONES 6.3.1 Fcil de mantener La aplicacin debe adaptarse al desarrollo de nuevas tecnologas y al descubrimiento de nuevos agujeros de seguridad, por lo tanto debe actualizarse constantemente. As que el diseo debe ser sencillo para facilitar las labores de actualizacin y mantenimiento.

6.3.2 Robusta La utilizacin aplicacin no debe constituirse en un riesgo para los usuarios por lo tanto es importante que no produzca efectos inesperados de ninguna clase, por esta razn el conjunto de pginas Web y el cdigo que contienen se ha desarrollado pensando principalmente en la seguridad del visor y el equipo del usuario. 6.3.3 Independencia del servidor La aplicacin funciona sobre cualquier servidor Web y sistema operativo, slo requiere un conjunto de directorios separado que albergue los archivos que la contienen. De esta manera se facilita la distribucin y el uso de la aplicacin. 6.3.4 Segura La aplicacin debe contar con mecanismos de certificados digitales para que el usuario pueda verificar el origen de las pginas Web. De esta manera se busca que los posibles usuarios no queden a merced de intrusos que simulen una presentacin idntica a la de la aplicacin con lgica que pueda causar dao o robar informacin. 6.3.5 Protegida El cdigo de los guiones de comandos JavaScript, VBScript y otros se encuentra en texto llano y el cdigo binario de Java (bytecode) no tiene proteccin frente al anlisis mediante diferentes programas para hacer ingeniera de reversa. Por lo tanto es factible que una persona mal intencionada intente obtener el cdigo de la aplicacin para aprender como desarrollar pginas Web. Las medidas que se tomaron son: Se utilizaron mecanismos de oscurecimiento de cdigo tanto manuales como automticos para proteger el cdigo. El cdigo JavaScript estar en archivos separados de los HTML y ser llamado desde pginas marcadas para que no sean guardadas en el Cach. Cualquier navegador que no sea identificado como uno de los clientes de Web a los que est destinada la aplicacin slo se le presentar una pgina de error sin vnculos hacia el resto del cdigo. Cualquier intento por acceder directamente a una pgina de la aplicacin sin pasar por la pgina de identificacin ser rechazado. 6.3.6 Tipos de Usuarios Los usuarios de navegadores que pueden acceder a la aplicacin se han dividido en tres conjuntos: usuarios inexpertos con un programa cliente vlido, usuarios expertos con un programa cliente vlido y usuarios con un programa cliente no vlido. Un programa cliente vlido pertenece al conjunto de navegadores hacia los cuales est orientado el sistema. Cada grupo debe ser manejado en forma diferente presentando informacin y permitindole o no el acceso a diferentes porciones de la aplicacin. 6.4 DISEO 6.4.1 Estructura general La distribucin del contenido de las pginas Web se basa en una estructura de marcos HTML como la que muestra la figura.

Ilustracin 3 Formato general de la aplicacin Existen cuatro zonas delimitadas mediante marcos HTML. Zona de Variables: Se encuentra en un marco de tamao cero, es decir no est visible al usuario. En esta parte se mantienen las variables que definen la actividad del usuario dentro de la aplicacin. De esta manera se puede mantener un concepto de sesin sin necesidad de recurrir a mecanismos de cookies que son ms lentas. Se asegura que una vez fuera de la aplicacin la informacin recopilada se destruye. Zona de titulo: Contiene informacin acerca de la aplicacin, del autor y de la institucin. Zona de men: Sirve como barra de navegacin a travs de los diferentes conjuntos de pginas de la aplicacin. Zona de contenido: En esta zona se presenta la informacin y se desarrolla la actividad principal del usuario. El documento HTML que contiene esta estructura debe estar en capacidad de atender debidamente requerimientos por parte de programas visor que no tienen capacidad de macros presentando informacin que gue al usuario y no lo deje frente a una pgina en blanco. 6.4.2 Estructura de pginas de verificacin Por cada vulnerabilidad que se va a analizar existe un documento HTML que contiene el cdigo necesario para hacer la verificacin. Este documento est dividido en dos zonas, una de cdigo en donde se encuentra el cdigo que realiza la comprobacin de la vulnerabilidad y otra en donde se presenta la informacin que resulta de la comprobacin.

Ilustracin 4 Estructura de pginas de verificacin Estas pginas son presentadas una por una en la zona de contenido de la estructura general de la aplicacin. 6.4.3 Pgina principal La primera pgina (index.html) es puramente informativa. Presenta la aplicacin, cual es su propsito y metodologa y le da la oportunidad al usuario de salir de la aplicacin si no desea utilizarla. 6.4.4 Pgina de identificacin En esta seccin se estudia el tipo de navegador utilizado (marca y versin), el sistema operativo utilizado, los plug-in instalados, etc. Estos valores son guardados en variables en el marco de tamao cero de la estructura principal. El usuario es informado de todos los datos obtenidos en esta seccin y se le da la oportunidad de empezar la verificacin o salir del sistema. 6.4.5 Men de verificacin Este documento es creado dinmicamente para presentar hipervnculos a cada una de las pginas que contienen el cdigo para verificar los diferentes agujeros de seguridad que pueden existir en el programa visor utilizado. 6.4.6 Pginas de verificacin Cada agujero de seguridad se prueba en una pgina diferente. Estas pginas contienen cdigo para simular un ataque pero sin llegar a completarlo. Despus de realizar la prueba, la pgina muestra si tuvo xito o no y que posibles soluciones existen para el problema estudiado. El formato de esta pgina debe ser sencillo de imprimir. El resultado de la verificacin es almacenado en variables que se encuentran en la zona de variables globales. 6.4.7 Reporte de resultados Al terminar todas las verificaciones se presenta una pgina con la descripcin del programa visor obtenida en la pgina de identificacin y un resumen de los resultados de las pruebas en un formato adecuado para impresin. 6.5 ANLISIS DE ATAQUES En esta seccin se va a estudiar una serie de ataques sobre diferentes visores, para cada uno de los ataques se consigna la siguiente informacin: - Nombre que permita identificarlo (preferiblemente el que le haya dado el autor del mismo o el que se haya hecho popular en el medio). - Fuente de donde se obtuvo. - Que tecnologa o tecnologas se estn utilizando para desarrollar el ataque. - Clientes de Web (marca, versin, plataforma) que son vulnerables ha dicho ataque. - Cual es el efecto de este ataque sobre el sistema y la informacin contenida en l.

Uno o ms escenarios en los cuales se podra usar este ataque en contra de los usuarios de la red. Posibles soluciones.

Esta forma de trabajar pretende organizar la informacin obtenida en Internet que es fragmentada y de muy diversa calidad para poder tener una idea de la situacin actual de la problemtica de la seguridad en el lado del cliente del servicio Web. Al mismo tiempo, se intenta encontrar las causas de esta situacin y se enuncian posibles soluciones puntuales para cada uno de los problemas encontrados.

6.5.1 ApplettKiller.java Fuente: Mark D. LaDue. Tecnologa: Java. Clientes Web afectados: Todos los que soportan Java. Efecto: El applet crea un hilo de control (thread) que destruye todos los dems hilos de otros applets que se hayan bajado de la red y se estn ejecutando. Causa: No existen suficientes restricciones para la interaccin entre applets. Escenarios: Si se logra penetrar en la pgina Web de alguien a quien se quiere desprestigiar, se puede instalar este applet (tal vez reemplazando a otro applet de la pgina) para que los visitantes de la pgina supongan que existen problemas de diseo o de programacin. En el caso de personas o empresas cuyo prestigio depende del manejo de tecnologa esto puede ser determinante para su imagen. Adems una applet puede continuar su ejecucin despus de que se ha descartado la pgina Web que lo contena de manera que puede afectar la ejecucin de applets de las hojas Web que se vean a continuacin. Posibles soluciones: Slo recibir applets firmados por entidades confiables Desactivar Java al navegar a pginas Web que no pertenecen a entidades confiables. 6.5.2 Attacker.java Fuente: Mark D. LaDue. Efecto: Este programa ataca al archivo que contiene el cdigo binario de la clase Beginer.java y le adiciona tres bytes al final que conforman una instruccin que hace que el control se devuelva al principio del applet dejndolo en un ciclo infinito. Adems modifica los atributos de longitud de cdigo y longitud de atributos de modo que la clase continua siendo aceptada por la JVM. Causa: Las clases compiladas de Java no tienen un nivel apropiado de seguridad, razn por la cual es relativamente sencillo decompilarlas o modificar su contenido sin dejar de cumplir con las reglas de verificacin de clase de la JVM. Escenario: Los applets Java son ofrecidos a lo largo y ancho de la red en forma gratuita de manera que resulta sencillo tomar applets conocidos (como los ejemplos de JAVASOFT), corromperlos y ofrecerlos para que diseadores de pginas Web los usen. Posibles soluciones: Slo recibir applets firmados por entidades confiables Desactivar Java al navegar a pginas Web que no pertenecen a entidades confiables. 6.5.3 AttackThread.java Fuente: Mark D. LaDue. Tecnologa: Java Clientes Web afectados: Aquellos que soportan Java. Efecto: La pantalla se llena de grandes ventanas que se superponen impidiendo el trabajo del usuario. Al cubrir toda la pantalla impide que el usuario pueda usar el ratn para cerrar el explorador, si se intenta mover el foco al cliente de Web usando ALT+TAB la aparicin de nuevas ventanas cubre inmediatamente el navegador impidiendo cerrarlo. Si se utilizan varios procesos se puede bloquear rpidamente el computador. Causa: No existe control apropiado sobre la terminacin de ciclos (este applet se basa en un ciclo infinito) y no hay limites sobre la cantidad de recursos que se puede apropiar un applet siempre y cuando el programa no parezca daino para el verificador de cdigo binario. Escenarios: Esta clase no se detiene si el explorador pasa a visualizar una pgina diferente de la pgina que lo contiene, de manera que se puede usar un evento de reloj para despertar el applet cuando se est presentando otra pgina para ocultar su origen y que el usuario piense inicialmente que la otra pgina contiene el applet. Posibles soluciones: Slo recibir applets firmados por entidades confiables Desactivar Java al navegar a pginas Web que no pertenecen a entidades confiables. 6.5.4 Infinity, Mr. Freeze, Seizure. Fuente: Daniel Prez, http://www.terminator3armaggedon.com/conspira/hostile.html Tecnologa: JavaScript, JScrip

Clientes Web afectados: Netscape e Internet Explorer todas las versiones a partir que soportan JavaScript. Efecto: Estos guiones de comandos entran en un ciclo infinito y desarrollan alguna actividad continuamente agotando tiempo de CPU y memoria RAM, de esta manera Internet Explorer queda bloqueado y la nica manera de detenerlo es cerrando el proceso desde la ventana Cerrar Programa, Netscape permite terminar la ejecucin del script presionando el botn Stop. Causa: JavaScript no tiene un planteamiento claro acerca de la seguridad, dado que se supone que un script est confinado al ambiente del programa visor y no puede hacer dao fuera de este mbito los mecanismos de seguridad brillan por su ausencia. Escenarios: Estos guiones de comandos se pueden incluir Posibles soluciones: Slo recibir applets firmados por entidades confiables Desactivar Java al navegar a pginas Web que no pertenecen a entidades confiables. 6.5.4 <Input Type = File> exploit Fuente: Edwin Li-Kai Liu. http://www.geek-gil.com/bugtraq/1997_2/0454.html Tecnologa: Formatos de HTML, JavaScript y CGI. Clientes Web afectados: Netscape versiones anteriores a la 4.01 sobre plataforma Windows. Efecto: Si un atacante conoce el nombre y camino de subdirectorios de una archivo especfico y si la vctima entra a un sitio diseado por el atacante este puede obtener el archivo por medio de una Forma (tal vez oculta) que contenga una entrada <INPUT TYPE=FILE> con el nombre del archivo y un guin JavaScript que enve la forma a un programa CGI en el servidor que recupere el archivo. Causa: La guerra de visores de Web a llevado a la creacin de nuevos mecanismos para hacer ms interactivo el ambiente del servicio World Wide Web Escenarios: Existen archivos importantes para el usuario/administrador de cualquier mquina AUTOEXEC, BAT, CONFIG.SYS, PASSWORDS, etc. Y que se suelen encontrar en directorios conocidos. Por lo tanto se puede crear una pgina que obtenga estos archivos ms algo de informacin de identificacin y la enve a un programa CGI que almacenen la informacin apropiadamente. Es probable que despus de algn tiempo se obtenga informacin relevante sobre diferentes sistemas y que alguno de ellos pueda ser atacado gracias a la informacin obtenida. Posibles soluciones: Configurar el programa visor para que presente una ventana de aviso siempre que se enva un formulario. No contestar formatos a entidades no confiables. 6.5.5 Error en la marca <OBJECT> Tecnologa: HTML Dinmico. Efecto: Abusa de memoria y tiempo de procesador afectando a los dems procesos en ejecucin y bloquea la ejecucin del visor y algunas veces el equipo en que se ejecuta. Descripcin: Se genera recursin infinita por medio de una marca OBJECT donde el atributo DATA hace referencia al archivo que la contiene. Otra variante puede requerir dos archivos HTML, cada uno con dos marcas OBJECT, una en la cual se hace referencia al otro archivo y otra en la que se hace referencia a s mismo. Este ataque no abre nuevas ventanas del visor, slo crea nuevos objetos sin cesar. Visores afectados: Internet Explorer 4.01 para Windows 95 y NT Fuentes: BUGTRAQ, primera referencia por Abe L. Getchell el 16 de marzo de 1998. Archivo: VS0001a.html y VS0001b.html Soluciones: Actualizacin a la ltima versin de Internet Explorer. 6.5.6 Problema con direcciones URL de tipo res:// Tecnologa: HTML Efecto: Se bloquea la ejecucin del visor y se puede ejecutar cdigo nativo. Descripcin: La marca res:// sirve para acceder a recursos incrustados dentro de una DLL. El motor de interpretacin de HTML utilizado por Internet Explorer y Outlook no puede

interpretar correctamente una referencia de este tipo con un nombre de longitud mayor a 265 caracteres pues no controla lmites y cae en un desbordamiento de la memoria asignada. Visores afectados: Visor Internet Explorer versin 4.0 Fuentes: BUGTRAQ Archivo: VS0002.html Soluciones: Actualizacin a la ltima versin de Internet Explorer. 6.5.7 Problema con la marca <EMBED> Tecnologa: Extensiones de Microsoft a HTML estndar. Efecto: Bloquea el programa visor y potencialmente puede ser utilizado para ejecutar cdigo nativo. Descripcin: Al crear una referencia con un nombre Visores afectados: Internet Explorer 4.0 y 4.01 Fuentes: BUGTRAQ, primera referencia por Georgi Guninski el 20 de marzo de 1998. Archivo: VS0003.html Soluciones: Actualizacin a la ltima versin de Internet Explorer. Obtener el archivo en http://www.microsoft.com/ie/security/?/ie/security/embed.htm 6.5.9 Sustraccin de archivos de texto Tecnologa: JavaScript, Jscript. Efecto: Archivos en texto llano (txt, html y otros) almacenados en el computador del usuario pueden ser sustrados al abrir una pgina con cdigo JavaScript hostil. Descripcin: Mediante el uso de la propiedad innerText del objeto body de JavaScript se puede obtener el contenido de un archivo y despus enviarlo al servidor por medio de una aplicacin CGI o de un applet Java. El nombre y localizacin del archivo deben ser conocidos previamente. Visores afectados: Netscape desde la versin 2.0 hasta la versin 4.1 e Internet Explorer desde la versin 3.0 hasta la versin 4.5. Fuentes: BUGTRAQ, primera referencia por Georgie Guninski, 5 de septiembre de 1998. Archivo: VS0005.html Soluciones: Desactivar Java. Utilizar la versin ms actualizada del programa visor. 6.5.10 Agujero de seguridad de Cuartango (Untrusted Script Paste) Tecnologa: JavaScript. Efecto: Informacin del computador local puede ser robada cuando el visor despliega una pgina Web con cdigo JavaScript Hostil. Descripcin: Un campo de tipo file de un formato html usado para enviar archivos desde el cliente al servidor en teora no puede ser llenado por programacin, nicamente por el usuario, sin embargo la capacidad de copiar y pegar si puede ser manejada por medio de cdigo en Internet Explorer y utilizada para introducir cualquier contenido en un campo de tipo file y robar un archivo. De esta manera se rodea el control y se puede indicar cualquier archivo para ser enviado a un programa CGI. El nombre y localizacin del archivo deben ser conocidos previamente. Visores afectados: Internet Explorer 4.01 y versiones beta de Internet Explorer 5.0 Fuentes: Pgina Web de Juan Carlos G. Cuartango. http://pages.whowhere.com/computers/cuartangojc/cuartangoh1.html Archivo: VS0006.html. Soluciones: Desactivar JavaScript. Obtener parche de seguridad de Microsoft en http://www.microsoft.com/ie/security/paste.htm 6.5.11 Problemas con Zonas de seguridad en Internet Explorer Tecnologa: Programa Visor. Efecto: Se puede engaar a un visor que se encuentra en una red interna empresarial que un sitio externo pertenece a la Intranet y por lo tanto goza de los mismos privilegios de seguridad

que los sitios Web de la empresa. Por ejemplo, http://3475932041/ lo lleva al sitio de Microsoft. La configuracin por defecto del Explorador da las mismas caractersticas de seguridad para la Intranet local y para Internet (rango de seguridad media) pero al configurarlo se suele dar una definicin de caractersticas de seguridad ms relajada para la Intranet que para Internet, por lo tanto este problema de seguridad puede ser aprovechado para penetrar una red empresarial. Adems el visor est configurado para que se identifique (Logon) automticamente slo en la Intranet, con esta falla de seguridad se puede obligar al visor a presentar el nombre del usuario y la clave cifrada para robarlas. Descripcin: Por defecto se considera que un sitio Web pertenece a la Intranet si su URL no contiene puntos y tiene menos de 16 caracteres. Sin embargo existen sitios en Internet que cumplen estas condiciones, Visores afectados: Internet Explorer 4.0 Fuentes: Sune Hansen en http://www.WorldWideWait.com. Archivo: VS0007.html Soluciones: Se debe configurar el visor para que slo considere en la Intranet aquellos sitios que se adicionan manualmente. 6.5.12 Ejecucin de macros en documentos Office 97 Tecnologa: Visor. Efecto: Se pueden ejecutar programas en Visual Basic para Aplicaciones. Esto quiere decir que no hay limitaciones de seguridad a lo que se puede ejecutar. No se necesita interaccin previa del usuario y no se muestran mensajes de advertencia. Descripcin: Internet Explorer invoca automticamente los programas de Office cuando se selecciona una URL que apunta a un archivo DOC, PPT o XLS. Office avisa si un documento tiene macros para prevenir y permite seleccionar si se desea abrirlo tal como est, abrirlo sin macros o no abrirlo, el problema es que la revisin se realiza solamente sobre el documento, la plantilla en que se basa no se tiene en cuenta y no se revisa por macros. Adems una plantilla de un documento en Office 97 no necesita ser local sino que puede ser obtenida por medio de una URL. Con estas premisas un atacante puede crear un documento Office 97 con macros hostiles en la plantilla. Visores afectados: Internet Explorer 4.01 con Office 97. Fuentes: BUGTRAQ, primera referencia por Vesselin Bontchev, 27 de enero de 1999. Archivo: VS0008.html Soluciones: Actualizacin de seguridad para Office que revisa macros en la plantilla, http://officeupdate.microsoft.com/downloaddetails/wd97sp.htm. 6.5.13 Agujero de seguridad de Cuartango 2 Tecnologa: JavaScript Efecto: Informacin del computador local puede ser robada cuando el visor despliega una pgina Web con cdigo JavaScript Hostil. Descripcin: Similar al primer problema de seguridad USP (Untrusted Script Paste) pero no se ve afectado por la solucin de seguridad proporcionada por Microsoft. En este caso la operacin de pegado no se realiza directamente sobre el documento sino sobre un objeto TextRange creado previamente. As se puede llenar mediante programacin un campo de tipo file y enviarlo automticamente y sin conocimiento del usuario al servidor. Visores afectados: Internet Explorer 4.01 y versiones beta de Internet Explorer 5.0. Fuentes: Pgina Web de Juan Carlos G. Cuartango. http://pages.whowhere.com/computers/cuartangojc/cuartangoh1.html Archivo: VS0006.html. Soluciones: Desactivar JavaScript. 6.5.14 Ventana de Cuartango Tecnologa: VBScript Efecto: Se puede engaar al usuario para que acepte la ejecucin de un guin de comandos VBScript con plenos derechos sobre el sistema. Descripcin: La ventana que avisa que se est creando un objeto desde un guin de comandos VBScript puede ser ocultada parcialmente (manteniendo visibles los botones) por otra generada desde la misma pgina de manera que presente informacin que convenza al usuario de

presionar la tecla Ok aceptando la creacin del objeto y dndole al guin de comandos plenos derechos sobre el sistema. Visores afectados: Internet Explorer 4.01 y versiones beta de Internet Explorer 5.0. Fuentes: Pgina Web de Juan Carlos G. Cuartango. http://pages.whowhere.com/computers/cuartangojc/cuartangoh1.html Archivo: VS0009.html. Soluciones: Desactivar JavaScript. 6.5.15 Negacin de servicio con Scripts Tecnologa: Lenguajes de Script. Efecto: Una pgina que contiene un Script puede consumir los recursos de memoria y/o tiempo de procesador dificultando la ejecucin de otros programas Descripcin: Mediante un loop infinito o recursividad sobre si mismo un guin de comandos VBScript, JavaScript u otro puede abusar de los recursos del ordenador. Visores afectados: Todos los que utilizan lenguajes de script sin mecanismos de contencin. Fuentes: Varias. Archivo: VS0009.html Soluciones: Desactivar el lenguaje de script. 6.5.16 Negacin de servicio con autorreferencias Tecnologa: HTML. Efecto: Una pgina Web puede abusar de los recursos del computador dificultando la ejecucin de otros programas, bloqueando el programa visor y en algunos casos haciendo caer el sistema. Descripcin: Una pgina basada en marcos puede contener referencias a s misma generando un ciclo infinito abusando de espacio de memoria y de tiempo de procesador. Visores afectados: Internet Explorer 3.0 y Netscape Navigator 3.0. Fuentes: Varias. Archivo: VS0010.html Soluciones: Actualizar a versiones recientes de los programas visor.

7 Control de recursos en Java

Los ataques ms comunes en Java son de negacin de servicio a travs del abuso de los recursos del computador en el que reside. Estos ataques normalmente se realizan gracias a instrucciones vlidas que se colocan dentro de un ciclo infinito o de recursividad cclica de manera que las instrucciones se repiten hasta que se agotan los recursos del sistema, a veces para aumentar la efectividad del ataque se abren varios hilos de control (threads) para aprovechar las caractersticas multitarea de Java. Los efectos de estos ataques van desde bloqueo del programa visor hasta detencin anormal de todo el sistema con la consiguiente prdida de informacin en los programas que estn activos en el momento del ataque. En este captulo se propone un mecanismo de contencin para proteger al programa visor de cdigo errneo o malicioso que genera este tipo de situaciones. Ya existen mecanismos que permiten controlar los recursos que son proporcionados a un applet. El primero tiene que ver con la caja de arena de la Maquina Virtual Java para cdigo obtenido remotamente que protege recursos crticos del sistema en un ambiente muy restrictivo, este ambiente se puede configurar para que a todos los applets se les proporcione acceso o no a ciertos recursos. Este mecanismo slo discrimina entre cdigo local (confiable) y cdigo remoto (no confiable) y proporciona acceso total o ningn acceso a los recursos. Por otro lado existe el mecanismo de cdigo Java firmado y encapsulado en archivos JAR (Java Archive) que permite asignar recursos a un applet Java que esta avalado por una entidad considerada confiable. Este mecanismo tambin se comporta como un esquema de restriccin, es decir se permite o no el acceso al recurso, adems el usuario tiene la opcin de aceptar o no el applet pero una vez aceptado no conoce que recursos va a usar el applet y en que cantidad Con el mecanismo de contencin que se propone en este captulo se busca: Un mecanismo de contencin antes que uno simplemente restrictivo, es decir no se trata de permitir o no el acceso a un recurso, si no regular su utilizacin para que el cdigo no pueda causar daos. Una interfaz de configuracin para que el usuario pueda adaptar el mecanismo a sus necesidades especficas. Es decir el control lo tiene el usuario. Integracin con los mecanismos existentes, especficamente con la aceptacin de applets firmados. De esta manera acta como una barrera en el caso de applets firmados que no tienen restricciones de operacin. Aun en el caso de que el applet no contenga cdigo malicioso puede tener errores que abran agujeros de seguridad; el mecanismo de contencin permite asignar recursos mnimos suficientes para que el posible dao ocurrido por una brecha en el software sea limitado. 7.1 RECURSOS QUE SE VAN A PROTEGER Los recursos que se planean proteger son los siguientes: Recurso Abuso Procesador El programa se apodera del procesador gracias a un ciclo infinito. En sistemas operativos con mecanismos eficientes para multitarea se pueden utilizar varios hilos de control para ocupar el procesador. Memoria principal Se crean objetos incesantemente hasta que se agota la memoria. Disco duro y rbol de Java por defecto no tiene acceso al disco duro; sin embargo, los applets directorios firmados por una entidad confiable no tienen tal restriccin y por un error de programacin pueden saturar el disco duro sin dejar espacio para documentos de otras aplicaciones o modificar o borrar archivos en el rbol de directorios. Interfaz de red Un applet puede abrir sockets hacia el servidor del cual proviene, sin embargo est medida puede no ser suficiente para reforzar la seguridad. Por ejemplo un applet puede conectarse al puerto 25 de su servidor (correo electrnico) y enviar un mensaje con informacin robada a un tercer servidor.

7.2 NIVELES DE PROTECCION El mecanismo funcionara a dos niveles, Mquina Virtual Java y Applet. Esto quiere decir que debe existir un control general de recursos en el mbito de la MVJ que limita hasta donde puede extenderse los recursos que utilizan todos los Applets y tambin se pueden fijar lmites para cada uno de los Applets. La asignacin de recursos para cada applet es necesaria pues en un mismo momento pueden coexistir dos applets activos con diferentes niveles de confiabilidad, por lo tanto un mismo nivel de proteccin para los applets no resulta eficiente. Se podra llegar a fijar recursos para cada una de las clases que componen el cdigo pero dado que varios applets pueden utilizar una misma clase en diferentes circunstancias y el mecanismo debera adaptarse a cada situacin el sistema podra hacerse demasiado pesado y lento. La limitacin de recursos debe tener una granularidad suficiente para que proteja el sistema y al mismo tiempo sea flexible, sin embargo una granularidad excesiva puede hacer muy pesado el mecanismo. Por lo tanto se busca como medir los recursos seleccionados para ser protegidos de manera que se pueda ejercer control sobre ellos con un mnimo de sobrecarga. Recurso Medida Nivel CPU Porcentaje mximo de utilizacin MVJ Memoria principal Porcentaje mximo de utilizacin MVJ / Applet Disco duro y rbol de Applet Porcentaje mximo de utilizacin directorios Directorio base al que puede acceder. Permiso para crear directorios. Permiso para borrar directorios. Tipos de archivo que puede operar (expresin regular). Permiso para crear archivos. Permiso para eliminar archivos. Permiso para modificar archivos. Permiso para ejecutar archivos. Interfaz de red Conjunto de direcciones y puertos a las que Applet puede conectarse. 7.3 ASIGNACION DE RECURSOS PARA LOS APPLETS Para asignar recursos a un applet se debe decidir que tan confiable es y que recursos se pueden asignar. Existen dos mecanismos bsicos: Firma digital: El applet contiene una firma digital para que una entidad certificadora pueda comprobar la identidad del propietario de la firma (principal) que respalda el applet. El navegador informar que se ha verificado la identidad de la entidad firmante cada vez que se cargue el applet o puede configurar el programa visor para que siempre acepte las firmas de algunas entidades sin 7requerir confirmacin manual. Origen: Se puede definir un conjunto de direcciones URL como fuentes de contenido confiable o especficamente el par (<URL de origen>, <nombre de archivo>). Sin embargo este mecanismo es ms dbil que el anterior. Recurso CPU Memoria principal Disco duro y rbol de directorios Interfaz de red Asignacin Porcentaje reportado por el sistema operativo para los procesos activos. Cantidad de memoria asignada por la MVJ contra cantidad total de memoria existente. Tamao de los archivos en el subrbol de directorios asignado contra tamao total de disco duro. Control de cadenas Control de cadenas

Control de cadenas significa que al realizar una operacin permitida sobre el rbol de directorios o la interfaz de red, los parmetros son verificados contra la lista de directorios o archivos vlidos o contra la lista de direcciones URL y puertos vlidos, en caso que exista una coincidencia la operacin se considera vlida. 7.4 DISEO El control de contencin se implementa en una clase cuyos mtodos son invocados para realizar la medicin de los diferentes tipos de recursos, si la verificacin indica que se estn violando las polticas de seguridad se desencadena una excepcin de contencin. El llamado a un mtodo de la clase de contencin siempre se realizarn despus de los llamados al Administrador de Seguridad de Java, de esta manera no se afecta el esquema actual de la MVJ. 7.4.1 CPU La medicin de ocupacin de ciclos de CPU se basa en primitivas normales en el sistema operativo sobre el cual est ejecutndose la Mquina Virtual Java. La medicin debe realizarse peridicamente y si excede los niveles fijados se debe generar una excepcin de contencin. La clase debe mantener el lmite mximo de uso y el periodo de tiempo en milisegundos. 7.4.2 Memoria principal Dado que instancias de ClassLoader se encargan de asignar memoria a las clases que son cargadas, el control de asignacin de memoria principal debe invocarse desde esta clase cuando ya se ha calculado la cantidad de memoria a asignar. La primitiva para liberar memoria que ya no se utiliza tambin debe llamar al mtodo encargado de controlar el uso de memoria principal para actualizar adecuadamente los valores de utilizacin. La clase de control de contencin debe mantener los valores totales de memoria asignados a las clases de cada aplicacin y la suma total de todas las aplicaciones. Antes de cargar la clase se comparan los valores con los limites especificados y si exceden las restricciones se genera una excepcin de contencin. 7.4.3 Disco Duro y rbol de directorios En este caso se estn restringiendo tres aspectos del recurso, que cantidad de espacio puede ocupar en total, que porciones del rbol de directorios (subrboles) estn visibles para el applet y el tipo de operaciones que puede realizar el applet (lectura, escritura, modificacin, creacin de subdirectorios, etc.) sobre cada subrbol. La clase debe mantener registro del espacio total del disco, espacio libre disponible y espacio ocupado por los subrboles visibles para la aplicacin, la lista de caminos (paths) de los directorios base de los subrboles con la descripcin de operaciones permitidas. La lista de subrboles tiene la siguiente estructura (<directorio raz>, <permisos concedidos>). <directorio raz> contiene el camino hacia el directorio a partir del cual se hace visible el subrbol para el applet. <permisos concedidos> es el conjunto de permisos que se otorgan al applet en esa porcin del rbol, bsicamente crear archivos, modificar archivos, borrar archivos, obtener contenido de directorio, crear directorios, cambiar de directorio y eliminar directorio. Los mtodos de Java que realizan estas operaciones deben invocar al mtodo que implementa el mecanismo de contencin para el rbol de directorios. El mtodo primero busca un tem en la lista de subrboles que contenga al directorio o archivo sobre el cual se va a hacer la operacin. Si se encuentra un tem coincidente se verifica si en el campo de permisos se ha proporcionado permiso para la operacin que se est desarrollando, si no es as se busca el siguiente tem que coincide con el objetivo y se repite el proceso. Si se llega al final de la lista sin encontrar permisos para realizar la operacin se genera una excepcin de contencin. 7.4.5 Interfaz de red Para el acceso a la interfaz de red, el mtodo de control de contencin es invocado desde la implementacin del mtodo constructor de la clase Socket. La direccin Internet y el puerto son comparados con la lista de objetivos permitidos por lo tanto la clase debe mantener la lista de objetivos permitidos.

Cada tem de la lista es un par (<direccin Internet>, <Puerto>) indicando a que direcciones Internet se puede conectar. El campo para la direccin Internet puede contener la direccin de un servidor especfico o de un dominio de servidores, el campo para el puerto puede contener, un nmero de puerto, un nombre de servicio o un asterisco que indica que se acepta conexiones desde cualquier puerto. El mtodo correspondiente recibe como parmetros la direccin Internet y el puerto al que se desea abrir una conexin (objetivo), primero busca un tem que contenga una direccin que encaje con la del objetivo. Para que una direccin sea vlida debe existir un tem cuya direccin sea exactamente igual o contenga a la direccin del objetivo. Es decir si existe un tem cuya direccin es uniandes.edu.co, las cadenas pollux.uniandes.edu.co y agamenon.uniandes.edu.co seran aceptables. Una vez encontrada una coincidencia de direccin se revisa el campo del puerto, si contiene un asterisco se acepta la conexin, si contiene un nmero de puerto y es igual al del objetivo se acepta la conexin. Si falla la coincidencia con un tem se sigue recorriendo la lista, si se llega al final de la misma sin encontrar una coincidencia se genera una excepcin. La lista es recorrida secuencialmente hasta encontrar el primer tem que genere coincidencia, esto debe ser tenido en cuenta al crear reglas generales de un dominio y especficas para servidores dentro de ese mismo dominio pues el orden de los tems ser determinante para definir el resultado de la verificacin. Para las direcciones se aceptan direcciones DNS (nombres como uniandes.edu.co) o direcciones TCP/IP (numricas como 153.257.12.1). En el caso de las direcciones DNS deben tener por lo menos un componente no genrico, por componente genrico se quiere decir los que designan al pas (co para Colombia, au para Australia, etc.) o los que indican la actividad de la organizacin que respalda el servidor (com para compaa comercial, gov para institucin gubernamental, edu para instituciones educativas, etc.). Esta medida se debe a que resultara inconveniente crear reglas que sean vlidas para todos las direcciones de un pas o para todas las organizaciones de un mismo tipo pues resultaran demasiado generales. Por ejemplo la direccin co que representa a direcciones de Colombia, la direccin com que representa compaas comerciales y com.co que representa compaas comerciales colombianas no seran aceptadas para incluirlas en la lista de tems para conexin. 7.4.6 Interfaz del usuario La interfaz de configuracin esta implementada a travs de una funcin dentro de la clase Contencin para que se pueda extender las capacidades de la clase con facilidad ya sea modificando los diferentes mtodos o a travs de herencia. La interfaz del usuario debe facilitar la configuracin de los diferentes valores y asignar el conjunto de caractersticas a un applet o conjunto de applets especficos 7.4.7 Interfaz de la clase A continuacin se muestran las definiciones de las clases que contienen la lgica para realizar las labores de control de contencin tal como se explic en las secciones anteriores. // Estructura para almacenar los permisos que tiene un applet sobre // una porcin del rbol de directorios public class Item_Subrbol { // Constantes que representan cada una de las operaciones que se // pueden realizar sobre medio magntico. byte SA_ESC_ARC = 1; // Escritura en archivos byte SA_LEE_ARC = 2; // Lectura de archivos byte SA_CRE_ARC = 4; // Creacin de archivos byte SA_BOR_ARC = 8; // Borrado de archivos byte SA_LEE_DIR = 16; // Lectura de directorios byte SA_CRE_DIR = 32; // Creacin de directorios byte SA_BOR_DIR = 64; // Borrado de directorios string camino_subrbol; byte permisos;

} // Estructura para almacenar cada una de las direcciones y puertos a los // cuales puede acceder un applet public class item_Conexin { string CON_TODOS = * string direccin; int puerto; } public class ContencinApplet { byte ram%_Max_App; byte hd%_Max_App; item_Subrbol: Lista_Subrbol[] item_Conexin: Lista_Conexin[] } // La clase que se encarga de realizar las verificaciones y lanzar las // excepciones. public class Contencin throws violacinContencin { // Propiedades byte cpu%_Max; byte cpu_ms byte ram%_Max; contencionApplet listaApplets[]; // Mtodos public void init(); public void start(); public void nuevoApplet(firma); // Limite mximo para la MVJ // Periodo de control de CPU // Limite mximo para la MVJ // Valores asignados a cada applet

// Debe existir un elemento por applet // Lmite de medio magntico ocuado // Debe existir un elemento por applet // Lista de subrboles y permisos visibles // para cada applet // Lista de conexiones permitidas para // cada applet

// Inicializacin // Inicio de threads // Inicializa los valores asignados a // un applet especfico public void nuevoApplet( string URL, string nombre); public void control_CPU (); public void control_RAM (); public void control_DD (String Camino; byte Operacin); public void control_Red (string Direccion; int Puerto); public void InterfazConfiguracin(); // Interfaz de configuracin para // el usuario }

8 CONCLUSIONES
La primera conclusin que surge de este trabajo es que el ambiente actual de operacin en la Web no permite el desarrollo de aplicaciones serias que resulten crticas para una organizacin o persona. La razn principal es que no existe un ambiente que proteja adecuadamente los recursos de hardware y software que soportan o conviven con el programa visor; por lo tanto, el uso de aplicaciones basadas en Web puede generar riesgos para la informacin y los equipos del usuario y para el resto de la Intranet si se est utilizando el visor dentro de una red Corporativa. Esta situacin de inseguridad se ve agravada por las caracterstica de la Web de ser un servicio abierto y disponible para el pblico en general. Segn el boletn de marzo del 93 de NIST, En los sistemas de acceso privado, los procedimientos para enrolar usuarios frecuentemente incluyen entrenamiento y reconocimiento formal de las responsabilidades de los usuarios. En los sistemas de acceso pblico, por el contrario, los usuarios frecuentemente son annimos y no estn entrenados en el sistema y sus responsabilidades, por lo tanto es imposible suponer que los usuarios de un sistema pblico estn en capacidad de tomar decisiones de seguridad; sin embargo muchos de los mecanismos utilizados para reforzar el ambiente de navegacin se basan en decisiones del usuario. Existen dos posibles caminos para enfrentar este problema, crear mecanismos de seguridad que no requieran interaccin continua con el usuario y proporcionar al usuario. OJOpproporcionar qu???? Ambos caminos son necesarios. Por un lado, los mecanismos que pueden ser configurados para que resuelvan automticamente los sucesos puntuales que ataen a la seguridad facilitan la aplicacin de medidas de seguridad; por otro, la configuracin de estos mecanismos o la solucin de eventos que no pueden ser tratados automticamente debe ser realizada por una persona que tenga unos conocimientos bsicos y en muchos casos esta persona tiene que ser el usuario. Para poder alcanzar un nivel de seguridad que se considere aceptable se debe desarrollar un proceso formal cuyo resultado es un conjunto de polticas de seguridad que cubra todos los aspectos del sistema que se est estudiando. En este trabajo se ha desarrollado un proceso para proponer un conjunto de mecanismos de seguridad para el visor de Web que permita implementar polticas de seguridad apropiadas que cubran todos los aspectos del ambiente de navegacin. Uno de los grandes problemas que se han encontrado es la aparicin de agujeros debidos a errores de implementacin de las diferentes tecnologas que albergan los programas visores y problemas en la interaccin entre diferentes tecnologas. Estos errores se deben principalmente a la falta de periodos de prueba adecuados y son causados por la presin que existe sobre las casas de software que desarrollan los programas visor, la presin que ejercen el mercado y la competencia los ha llevado a presentar al pblico nuevas versiones en periodos muy cortos de tiempo. Muchas veces estos errores de implementacin slo pueden ser cubiertos por medio de la instalacin de soluciones especficas (hotfix) o nuevas versiones que las casas de software ponen a disposicin de los usuarios para que las obtengan gratuitamente. Esta situacin es claramente reactiva, es decir, se est respondiendo a eventos negativos despus que han causado dao, la solucin ideal sera que las compaas fabricantes de programas visor tuvieran mejores polticas para el desarrollo de programas para evitar errores que en muchos casos no son difciles de evitar y que no son admisibles en programas que son desarrollados en empresas lderes de la industria. En la situacin actual, el problema es mayor de lo que parece porque, si bien aparecen soluciones a los problemas existentes, el usuario promedio que no est consciente de los problemas de seguridad en el visor tampoco conoce las soluciones de seguridad que las compaas de software presentan y muchas veces no le interesa y no encuentra una razn vlida para cambiar el programa al que est acostumbrado por una nueva versin del visor.

REFERENCIAS BIBLIOGRAFICAS
[AC098] [BAG97] ACOSTA, Beatriz Elena. Metodologa de implantacin de seguridad en redes. Universidad de los Andes. Santaf de Bogot, 1998. BAGWILL, Robert y GUTTMAN, Barbara. Internet Security Policy: A Technical Guide (NIST Special Publication 800-XX). Information Technology Laboratory. Computer Security Division. National Institute of Standards and Technology Julio, 1997. BALFANZ, Dick y GONG, Li. Experience with Secure Multi-Procesing in Java. Princenton University and JavaSoft, Sun Microsystems. Septiembre, 1997. BALFANZ, Dick y FELTEN, Edward. A Java Filter. Department of Computer Science. Princenton University. 1998. BROWN, Laurie. Mobile Code Security. School of Computer Science, Australian Defence Force Academy. Camberra, Australia. 1996. COMER, Douglas E. Y STEVENS, David L. Internetworking with TCP/IP Volumen III. Prentice Hall, 1993. DEAN, Drew y WALLACH, Dan S. Security Flaws in the HotJava Web Browser. Department of Computer Science. Princenton University. Noviembre, 1995. DEAN, Drew. The Security of Static Typing With Dinamic Linking. Computer Science Laboratory. SRI International. 1996. DEPARTMENT OF DEFENSE. Trusted Computer Security Evaluation Criteria (Libro Naranja), DoD 5200.28-STD. 1985. ECKEL, George. Building a Unix Internet Server. New Riders Publishing. ESSEN, J. Security Requirements on Computers and Operating Systems. En Security and Protection in Information Systems, Proceedings of the Fourth IFIP TC 11 International Conference on Computer Security. North-Holland, Holanda, 1989. FELTEN, Edward W., BALFANZ, Dick, DEAN, Drew y WALLACH, Dan. Web Spoofing: An Internet Con Game. Department of Computer Science, Princeton University. Septiembre, 1997. FRAY, J.; DESWARTE, Y. y POWELL, D. A Secure Distributed System Based on Intrusion Tolerance. En Security and Protection in Information Systems, Proceedings of the Fourth IFIP TC 11 International Conference on Computer Security. NorthHolland, Holanda, 1989. GARFINKEL, Simson y SPAFFORD, Gene. Web Security & Commerce. OReilly & Associates, 1997, Cambridge. GLIGOR, V. D. y CHANDERSEKARAN, C. Sekar. Towards the Development of Secure Distributed Systems. En Security and Protection in Information Systems, Proceedings of the Fourth IFIP TC 11 International Conference on Computer Security. North-Holland, Holanda, 1989. GOLDBERG, Ian; WAGNER, David; THOMAS, Randi y BREWER, Eric A. A

[BAL97] [BAL98] [BRO96] [COM93] [DEA95] [DEA97] [DOD85] [ECK] [ESS86]

[FEL97]

[FRA86]

[GAR97] [GLI86]

[GOL96]

Secure Environment for Untrusted Helper Applications. Confinig the Wily Hacker. University of California, Berkeley. 1996. [GRI97] GRIM, Robert y BERSHAD, Brian N. Security for Extensible Systems. Dept. of Computer Science and Engineering. University de Washintong. Seattle, WA 98195, U.S.A. 1997. JAVA-SIG Team, The. JAVA-SIGs 100 best applets. John Wiley & Sons. New York, 1997. JONES, R. W. The Creation and Use of Explicit Rights in a Distributes System. En Security and Protection in Information Systems, Proceedings of the Fourth IFIP TC 11 International Conference on Computer Security. North-Holland, Holanda, 1989. JOLIA-FERRER, L. Penetration Testing as an Audit Tool, En Security and Protection in Information Systems, Proceedings of the Fourth IFIP TC 11 International Conference on Computer Security. North-Holland, Holanda, 1989. KAZUHIKO Kato et al. Protected and Secure Mobile Object Computing in Planet. Institute of Information Sciences and Electronics of Tsukuba. Tsukuba, Japan. 1996. KIRTLAND, Mary. Safe Web Surfing with the Internet Dowload Service. En: Microsoft Systems Journal. Julio, 1996. LINDHOLM, Tim y YELLIN, Frank. The Java TM Virtual Machine Specification. Sun microsystems, 1999. LIU et al. Administracin de servicios de informacin en Internet. McGraw Hill Interamericana Editores S.A.- OReilly. Mxico,1997 LEMAY, Laura y MONCUR, Michael. JavaScript 1.1. Sams.Net 1996. MACGRAW, Gary y FELTEN, Edward. Java Security. John Wiley & Sons. New York, 1996. MARLON, Carlos y ORTIZ, Coral. Estudio del impacto de la seguridad en el desempeo de Internet. Universidad de los Andes, Santaf de Bogot, 1997. MEHRMANN, L. W. Y AMERY C. T. H. Security Practices for Information Systems Networks. En Security and Protection in Information Systems, Proceedings of the Fourth IFIP TC 11 International Conference on Computer Security. North-Holland, Holanda, 1989. NECULA, George C. Proof-Carrying Code. School of Computer Science. Carnegie Mellon University. Pittsburgh, 1998. NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY. CSL Bulletin, Security Issues In Public Access Systems. Mayo, 1993. NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY. CSL Bulletin, Connecting To The Internet: Security Considerations. Julio, 1993. NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY. CSL Bulletin, People: An Important Asset In Computer Security. Octubre, 1993. NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY. CSL Bulletin, Threats To Computer Systems: An Overview. Marzo, 1994. NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY. CSL Bulletin,

[JAV97] [JON86]

[JOL86]

[KAZ96] [KIR96] [LIN98] [LIU97] [LEM96] [MAC96] [MAR97] [MEH86]

[NEC97] [NIS0593] [NIS0793] [NIS1093] [NIS0394] [NIS1295]

An Introduction To Role-Based Access Control. Diciembre, 1995. [NIS0595] [NIS0298] [QUI98] [RUB97] NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY. CSL Bulletin, The World Wide Web: Managing Security Risks. Mayo, 1995. NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY. Information Security And The World Wide Web (WWW). Febrero, 1998. QUICK, Rebeca y WEBER, Thomas E. Internet, el nuevo trineo de Santa Claus. El tiempo. Lunes 16 de noviembre, 1998. RUBIN, Aviel D., GEER, Daniel y RANUM, Marcus J. Web Security Sourcebook: A Complete Guide to Web Security Threats and Solutions. John Wiley and Sons, New York, 1997. RYNSON, W. H. Lau, Kwok-Yan Lam y Siu-Leung Cheung. The failure of AntiHacking Legislation: A Hong Kong Perspective en 3rd ACM Conference on Computer and Communications Security. March 14-16 1996. New Delhi, India. STEIN, LincolnD. The World Wide Web Security FAQ, Versin 1.9.0. 1998. VITEK, Jan. Secure Object Spaces. Object Systems Group, university of Geneva. Geneva, Switzerland. 1995. WALLACH, Dan S. y FELTEN, Edward W. Understanding Java Stack Inspection.Secure Internet Progamming Laboratory. Department of Computer Science. Princenton University. 1997. WISEMAN, S. A Capability Approach to Multi-level Security. En Security and Protection in Information Systems, Proceedings of the Fourth IFIP TC 11 International Conference on Computer Security. North-Holland, Holanda, 1989. WUTKA, Mark et al. Hacking Java, The Proffesionals Resource Kit. Que, 1997.

[RYN96]

[STE98] [VIT95] [WAL97]

[WIS86]

[WUT97]

DIRECCIONES URL
Hacked.net - Web Surfers Security Report. http://www.hacked.net/wssr.html Do you want to crash your browser? http://www.newdream.net/crash/index.html. Are you sure you really want to crash your browser?. http://www1.minn.net/Crash/crash.htm. Click here to crash Communicator 4.0. http://pages.nyu.edu/. CA-97.20 javascript en info.cert.org (FTP). http://info.cert.org/pub/cert_advisories/CA-97.20.javascript. Security update: The Singapore Privacy Bug. http://home.netscape.com/assist/security/resources/singapore_privacy.html. Internet Explorer File Corruption Bug. http://web.mit.edu/twm/www/expbug2/. List of Browser Security Problems (Netscape, MSIE, Lynx). http://www.columbia.edu/acis/rad/browser-bugs.html. Center for Democracy and Technology. Privacy Demonstration Page. Http://www.13x.com/cgi-bin/cdt/snoop.pl. Request Headers in the HTTP protocol. http://www.w3.org/Protocols/HTTP/HTRQ_Headers.html. A note about Web Browsers & Privacy. http://ww.cen.uiuc.edu/~ejk/WWW-privacy.html. Erasing Netscape. http://www.eecs.hardvard.edu/~tlb/kill-ns.html MSIE spoofing. http://www.dartmouth.edu/~rmccull/MSIEspoof.html. Ryans How to make your browser LIE like a RUG. http://www.ryan.net/fakeMSIE.html. MS scurity plugs not airtight. http://www.news.com/News/Item/0.4.10909.00.html. ABC 7 Online: WJLA-TV Washington, D.C. News: Netscape Navigator Glitch Found. http://www.abcnews.com/local/wjla/news/1522_6131997.html. Java Security in the Corporae Environment. http://www.ics.com/intranet/Abstracts/shoffner.html.

Microsoft fixes Explorer; promises tighter security. http://www.zdnet.com/zdnn/content/zdnn/0325/zdnn0001.html. LA NACION online/Informtica: Seguridad en la red. Es seguro enviar mis datos personales a travs de Internet?. http://www.lanacion.com/suples/infor/00notas/10-segu/nota.htm. Microsoft Internet Explorer Security Warning. http://web.kunsan.af.mil/security/ Netscape 2.0 Security Risks. http://technology.ksc.nasa.gov/ETEAM/security1.html. Security Information & Code Updates. Baje ahora el Scurity Fix de Explorer 3.0 y 3.1. http://www.cnet.net/ayuda/security.htm. Urgent Ames Netscape Navigator 2.0 Security Alert. http://www.arc.nasa.gov/arcnic/security/secure.notice01.html. NEWSwatch - New Browser Security Flaw Discovered. http://www8.zdnet.com/zdimag/news/199703/28/news1.html. IE 4.0 Security Flaw. http://www.zdnet.com/pcmag/trends/t971017a.htm. Netscape security hole also exists in Website server. http://www-archive.stanford.edu/lists/www-managers/hyper95/0541.html. The Web Developers Virtual Library: Introduction to JavaScript. http://wdvl.Internet.com/Authoring/JavaScript/Events/1.html Electronic Privacy Information Center- Privacy and Control of Personal Data. http//www.epic.org/privacy/consumer/action.html. Web Security Center (Symantec). http://www.symantec.com. The Worl Wide Web Security FAQ: Client Side Security. http://www.w3.org/Security/Faq/wwwsf7.html. The java filter. http://www.cs.princeton.edu/sip/JaaFIlter/index.html. Exploiting Orthogonal Bugs. http://www.ee.surrey.ac.uk/Personal/L.Wood/IE$res. Hostile Applets Home Page. http://www.cyber.com/mirror/mladue/HostileApplets.html. Secure Internet Programing. Related Web Sites. http://www.cs.princeton.edu/sip/Links.html. Java Security: Frequently Asked Questions. http://www.cs.princeton.edu/sip/java-faq.html.

Security Tradeoffs: Java vs. Activex. http://www.cs.princeton.edu/sip/java-vs-activex.html. Plug in Premier. ComputerLife. http://www.zdnet.com/products/content/articles/199709/plugin.primer/