Autor: Marco Aurélio Bonato - GSR

"Uma variação deste artigo foi apresentado no seguinte congresso: 10th FIRST - Conference Computer Security Incident Handling", relizado em Monterey no México em junho de 1998.

1. Introdução

Com o avanço no uso da Internet, a criação de ferramentas que facilitam o desenvolvimento de aplicativos é inevitável, pois a busca do aperfeiçoamento tecnológico na disseminação de informações através da Internet é cada vez maior. O WWW tem se mostrado uma das ferramentas mais utilizadas na Internet para a disseminação de informações, bem como a de maior e mais rápida evolução.

Juntamente com a utilização do WWW, que codifica suas páginas em linguagem HTML, surgiram diversos tipos de aplicativos que foram integrando suas funcionalidades ao Browser WWW. Estes aplicativos interagem com a linguagem HTML, visando melhorar os recursos oferecidos para quem desenvolve as páginas que serão disponibilizadas na Internet. A utilização de Applets Java, que derivou da linguagem Java, é um exemplo de aplicativo que foi incorporado na linguagem HTML.

Para desenvolvedores de páginas WWW que estão interessados em melhorar os recursos oferecidos por suas páginas, os aplicativos que foram incorporados na linguagem HTML têm se mostrado de grande utilidade, mas há quem use suas potencialidades de maneira indevida, furando esquemas de segurança e proporcionando incômodo para quem os acessa.

A designação de conteúdo executável hostil será evidente quando após o recebimento, sua execução tentar monopolizar ou explorar os recursos do sistema de uma maneira indevida e sem autorização.

Um conteúdo executável hostil pode violar as políticas de segurança e conseguir rodar códigos nativos dentro da máquina que os recebeu, tomando o controle total do sistema.

Este tipo de comportamento vem ressaltar que o acesso aos conteúdos executáveis por pessoas que desconhecem suas potencialidades pode ser perigoso, pois quem está navegando na Internet não sabe quando seu Browser está recebendo um conteúdo executável, desconhecendo também qual vai ser o resultado de sua execução.

Não são comuns ferramentas que consigam bloquear um ataque cujo intermediário é a própria aplicação, isto é, o bloqueio a um protocolo de aplicação não é comumente factível, pois a maioria dos esquemas atuais de proteção para redes corporativas ligadas à Internet não controlam este tipo de acesso.

A maioria dos esquemas de segurança para Intranets que estão ligadas à Internet são baseadas nas Firewalls. Elas conseguem bloquear o acesso indevido baseando-se na filtragem dos protocolos de nível 3 (Rede) e 4 (Transporte) do Modelo de Referência ISO/OSI, IP e TCP, respectivamente, na arquitetura Internet. Como um conteúdo executável faz parte da aplicação, eles conseguem acessar qualquer máquina, estando esta dentro de uma Intranet teoricamente protegida por uma Firewall ou diretamente ligada à Internet, desde que a Firewall não tenha um filtro que impeça a entrada de alguns conteúdos executáveis para o interior de uma Intranet. Mesmo assim, ataques que utilizam tecnologias em conjunto podem ignorar os filtros impostos por algumas Firewalls.

2. Características Funcionais dos Conteúdos Executáveis

Como são várias as tecnologias empregadas na construção de conteúdos executáveis e cada uma delas possui características próprias, nas próximas sessões cada uma delas é detalhada.

A linguagem Java foi desenvolvida pela Sun Microsystems para possibilitar que aplicações e Applets pudessem ser desenvolvidos, sendo diferenciada da seguinte maneira: Aplicações Java são desenvolvidas para serem executadas por um interpretador Java, dentro de um ambiente Java e os Applets Java são executados por um Runtime da linguagem Java que está embutido nos Browsers WWW.

Quando um Browser recebe um Applet para ser executado, pelas definições de segurança impostas pela linguagem, este Applet teria uma execução restrita dentro da máquina do usuário, isto é, o recebimento de Applets Java pelo Browser WWW não deveria causar riscos às máquinas, não importando se este Applet foi carregado de uma Intranet ou da Internet. Por sua definição as ações executadas por um Applet Java estão restritas a uma área no Browser WWW dedicada ao Applet, sendo esta área chamada de Sandbox. Um Applet pode fazer qualquer coisa dentro da Sandbox, mas não pode ler, gravar ou executar nada que esteja fora do alcance da Sandbox. A Sandbox visava garantir que se o usuário receber um Applet hostil, ele não provocará nenhum dano na máquina. Uma Sandbox é constituída pelos seguintes elementos: Características de Segurança, verificação do ByteCode, ClassLoader e gerente de segurança. Características de Segurança: Esta parte é responsável pelas definições de funcionamento da linguagem Java que irão tentar impedir que os ataques mais comuns possam ser aplicados utilizando artifícios de programação. Para exemplificar uma das características de segurança da linguagem Java, podemos dizer que um programador Java não poderá forjar endereços para a memória, pois a alocação e o modelo de referência da memória são totalmente obscuros, sendo controlados pelo sistema Runtime da plataforma.

Verificação do ByteCode: Quando um compilador Java compila um código fonte ele gera um ByteCode. Para o Runtime da linguagem, um fragmento compilado de código pode ter vindo de qualquer parte de uma rede, e não se sabe se o compilador que gerou o ByteCode era confiável ou não, isto é, se ele seguiu ou não as regras de segurança especificadas pelo fabricante da Linguagem Java. O Runtime da linguagem simplesmente não confia nos ByteCodes que são trazidos pela rede, e submete-os a uma série de verificações. Estas verificações tentam garantir que o código que será passado para o Interpretador Java estará apto para ser executado sem nenhum problema.

Fig. 2.1 - Processo de verificação do ByteCode.

 ClassLoader: A ClassLoader é definida como sendo uma classe abstrata que pode ser usada para escolher a política de carga de classes Java para o ambiente de execução, definindo assim quais classes podem ser executadas e quais não podem.

Como mecanismo padrão de recuperação de classes, o sistema Runtime carrega as classes que estão armazenadas em arquivos locais, podendo recuperá-las a qualquer momento, sem a necessidade de passar pela ClassLoader. Entretanto, algumas classes podem não estar armazenadas no sistema de arquivos locais, e sim em outras máquinas espalhadas por uma rede. Neste caso, o sistema Runtime chama uma subclasse da ClassLoader para carregar a classe remota. Classes carregadas via rede são transportadas como uma seqüência de caracteres. A ClassLoader então é usada para dizer ao sistema Runtime para converter a seqüência de caracteres em uma instância da classe Class. A conversão de informações é feita pelo sistema Runtime utilizando o método defineClass e as classes que são criadas por este método podem referenciar outras classes através de seus nomes. Para resolver estes nomes, o sistema Runtime chama a ClassLoader que originalmente criou a classe.

Gerente de Segurança: O Gerente de Segurança tenta reforçar as fronteiras ao redor da Sandbox. Quando um Applet Java tenta executar uma ação que poderia corromper ou acessar informações da máquina local, a Máquina Virtual primeiramente pergunta ao Gerente de Segurança se a ação pode ser executada com segurança. Se a ação solicitada for recusada pelo Gerente de Segurança, será mostrado um erro de execução.

Muitos usuários da Internet ficam surpresos ao saber que Javascript não derivou da linguagem Java, isto é, a similaridade entre elas se dá no nome e pelo fato de serem linguagens de programação usadas para desenvolver conteúdos executáveis que serão recebidos por Browsers WWW através da Internet. Javascript foi desenvolvida pela Netscape para permitir que um código de programação pudesse ser incluído dentro de documentos HTML. Este código pode modificar dinamicamente o HTML que será interpretado, baseando-se nas condições de execução do Browser WWW que recebeu o documento HTML. Por Exemplo, um segmento de código Javascript pode modificar a maneira com que um Browser irá mostrar as informações na tela do computador baseando-se nos valores dos Cookies que estão armazenados na memória da máquina.

Uma das funcionalidades mais usadas da linguagem JavaScript é a habilidade de definir eventos baseando-se nas reações do usuário. Estas reações podem ser as mais variadas possíveis como, por exemplo: o posicionamento do mouse em um determinado ponto da tela do computador pode acionar a execução de um pequenos pedaço de código JavaScript. Mas as características da linguagem JavaScript não param somente nisto, ela é uma linguagem completa, com funções matemáticas, algoritmos de ordenação e a possibilidade de abrir caixas de diálogo para que o usuário possa interagir na sua execução e ações possam ser executadas baseando-se nas repostas.

JavaScript não tem o mesmo poder nem funções de afetar recursos do sistema como a linguagem Java, entretanto JavaScript tem sido usado para criar os mesmos problemas de segurança que são criados com a linguagem Java.

Fundamentalmente, a plataforma ActiveX é uma readaptação de tecnologias da Microsoft para o WWW. O padrão ActiveX baseia-se nos padrões de desenvolvimento para Windows conhecidos como OLE (Object Linking and Embedding) e COM (Component Object Model).

2.3.1 OLE (Object Linking and Embedding) e COM (Component Object Model)

COM é o modelo de objetos no qual foram construídas as plataformas ActiveX e OLE. COM permite que um objeto exponha suas funcionalidades para outros componentes e para aplicações. Ele define, principalmente, como o objeto será exposto e como esta exposição funcionará através dos processos e através das redes de computadores, definindo também como será o ciclo de vida de cada Objeto.

OLE é uma ferramenta que permite aos desenvolvedores criar aplicações sofisticadas que operam através de múltiplas plataformas. Com o OLE documentos complexos podem ser construídos, isto é, um documento pode conter vários objetos de diferentes formatos como, por exemplo: uma figura, uma planilha eletrônica e um pedaço de um texto de outro documento. Estes objetos podem estar embutidos no documento ou simplesmente ligados a ele, isto é, no documento só vai haver uma ligação indicando onde o objeto está localizado. Se o documento inicial que contém o objeto for modificado, o documento que contém as ligações para ele também será automaticamente modificado.

2.3.2 Controles ActiveX

Os controles ActiveX permitem que um programador crie um objeto reutilizável de alto nível com algum comportamento genérico. O programador pode, então, passar o controle (ou vendê-lo) para um outro desenvolvedor, que pode usá-lo como um bloco de construção dentro de qualquer ferramenta de programação que aceite os controles ActiveX. A maioria das principais ferramentas Windows tais como, C/C++, Basic, Pascal e muitas outras linguagens, é compatível com os controles ActiveX. Um controle ActiveX poderia ser qualquer coisa, desde um botão até uma planilha eletrônica cheia de recursos. Milhares de controles ActiveX estão disponíveis comercialmente a partir de uma variedade de fabricantes. A riqueza e a abrangência destes controles representam o maior potencial da ferramenta.

Qualquer controle não residente no sistema de arquivos locais tem de ser recebido da Intranet ou Internet antes de ser executado, por esta razão os controles ActiveX usados nas páginas HTML devem ser os menores possíveis. Isto não é, e está longe de ser, uma característica dos antigos controles OLE que evoluíram e deram origem aos controles ActiveX. Para que isto fosse possível, os controles ActiveX foram remodelados para que suas estruturas, quando construídas, ocupassem o menor espaço possível.

2.3.3 Documentos ActiveX

ActiveX também introduziu o conceito de OLE em documentos, habilitando, assim, documentos referenciados para serem usados pelas páginas que serão mostradas pelo Browser WWW. Isto quer dizer que um documento que foi editado no editor de textos WORD da Microsoft, e que tem características próprias na sua formatação, pode ser visualizado em um Browser WWW.

SockWave é uma plataforma multimídia que possibilita a construção de uma grande quantidade de aplicativos. Jogos, interfaces animadas, apresentações e animações para serem executadas pelos Browsers WWW são possíveis de serem construídas a partir dela. Uma animação ShockWave pode ser construída a partir de três ferramentas denominadas Flash, Director ou Authorware. Para que as animações ShockWave possam ser executadas pelo Browser WWW um programa (plug-in) deverá ser adicionado ao Browser. Uma exigência requerida quando se está desenvolvendo uma aplicação para ser disponibilizada na Internet, é que os arquivos não devem ser muito grandes, pois isto inviabiliza o seu recebimento para os usuários que estão conectados na Internet com ligações de baixas velocidades, sendo que uma das principais características da ferramenta ShockWave é construir códigos de pequeno porte.

3. PROBLEMAS DE SEGURANÇA DAS TECNOLOGIAS DE CONTEÚDOS EXECUTÁVEIS

Cada tecnologia acima descrita possui problemas de segurança, sendo através deles que os ataques praticados através de conteúdos executáveis são possíveis. Os principais problemas e suas características estão explicadas a seguir

A linguagem Java foi construída para tentar garantir, através da SandBox, que um Applet hostil não provoque qualquer alteração no ambiente onde está sendo executado, pois foram impostos um conjunto de limitações e regras para a sua execução. Assim sendo, se um Applet for recebido através de uma rede, seja ela uma Intranet ou a Internet, ele não está habilitado a executar uma série de tarefas. Como exemplo pode-se especificar as seguintes: ler arquivos da máquina cliente; gravar arquivos na máquina cliente; apagar arquivos na máquina cliente usando o método da Linguagem Java File.delete(); apagar arquivos na máquina cliente chamando comandos do sistema operacional, tais como remove ou delete; etc.

Problemas na implementação da linguagem e situações não previstas na elaboração dos procedimentos de segurança da linguagem Java permitiram que Applets Java pudessem violar as regras impostas pela SandBox. Vários ataques utilizando Applets Java foram noticiados [MCG 96], [CA 96.05], [BIL 97], [LAD 97], [LAD 96a], [LAD 96b], [PRI 96], [DEA 96], [ROJ 96], fazendo com que os fabricantes da linguagem Java e os fabricantes dos produtos por ela suportados diponibilizassem novas versões nas quais as vulnerabilidades conhecidas estariam sanadas. Para manter-se sempre a salvo dos problemas de segurança já conhecidos e relatados, é conveniente que a ferramenta Java que está sendo utilizada, seja ela um Browser ou uma Plataforma de desenvolvimento, esteja sempre atualizada pelas versões mais recentes disponibilizadas pelos fabricantes. Entretanto, ninguém está livre de futuras possibilidades de ataques que ainda não foram descobertas.

Muitos dos problemas de segurança criados a partir da linguagem Javascript não podem ser explorados diretamente, isto é, necessitam da interação com o usuário. Como a maioria dos usuários não sabe dos perigos implícitos neste tipo de tecnologia, os ataques se tornam fáceis de serem executados, pois os usuários oferecem toda a ajuda possível. Por exemplo: muitos ataques requerem que os usuários apertem botões que aparecem em caixas de diálogos para que o código hostil seja ativado. Uma trapaça comum é construir uma caixa de diálogo para que o usuário pressione um botão, sendo que a mensagem mostrada na tela é a mais simples possível, como "Click OK para continuar". Na caixa de diálogo existe somente um botão chamado "OK". Usuários ingênuos apertam o botão ativando o ataque. Como exemplos de ataques pode-se citar:

• Javascript pode ser usado para rastrear todos os "sites" visitados por um usuário sem o seu conhecimento, reportando as informações para o atacante[RUB 97];

• O usuário pode ingenuamente enviar arquivos via correio eletrônico para o atacante apertando um botão de confirmação que aparece na tela do Browser WWW[RUB 97];

• JavaScript pode ser usado para montar ataques em sistemas que bloqueiam a entrada de Applets Java. Por exemplo: muitas Firewalls evitam a entrada de Applets Java removendo qualquer código existente entre os marcadores (Tags) <APPLET> e </APPLET> de um documento HTML. Entretanto, JavaScript pode ser usado para recriar um marcador <APPLET> no código fonte da página HTML que está sendo recebida. Outra maneira de realizar o mesmo ataque seria desenvolver uma página HTML com o seguinte marcador (Tag) </%41pplet>, sendo o código JavaScript usado para modificar o marcador para </Applet> logo após o recebimento da página[RUB 97].

Os conteúdos executáveis desenvolvidos pela plataforma ActiveX quando recebidos e aceitos para serem executados por um Browser WWW tem acesso a qualquer recurso da máquina. Na definição de utilização desta tecnologia está descrito que conteúdos executáveis ActiveX só deveriam ser aceitos se a pessoa que o disponibilizou na Internet fosse certificada, garantindo assim a sua origem. Isto não ocorre na prática, pois a maioria dos usuários de Browsers WWW habilitam o recebimento de qualquer conteúdos, certificado ou não. Certificar os conteúdos ActiveX não resolve o problema de segurança pois qualquer programador consegue comprar uma certificação (authenticode) por aproximadamente U$ 20.00[BRU 97]. "Se um programador mal intencionado comprar uma certificação e desenvolver um único controle ActiveX que muda a configuração dos Browsers WWW Internet Explorer para que qualquer outro controle ActiveX seja aceito, uma vez que estes Browsers estavam configurados para receber somente controles ActiveX certificados, nunca ficará evidente de onde veio o programa que desconfigurou os Browsers WWW. A partir deste momento os usuários destes Browsers estão vulneráveis aos outros controles ActiveX hostis da Internet"[GAR 96]. Um exemplo de ataque utilizando ActiveX foi noticiado por [BUR 97].

Como as animações ShockWave são conteúdos executáveis que são recebidos pelos Browsers WWW para serem executadas, alguns ataques já foram noticiados utilizando esta tecnologia, como mostram os exemplos abaixo relacionados.

• Um desenvolvedor de aplicações ShockWave pode acessar as pastas de correio eletrônico dos usuários do Browser Netscape. Isto é feito assumindo os nomes e caminhos padrões no sistema de arquivos locais do usuário. Por exemplo, Inbox, Outbox, Sent e Trash são nomes padrões que são configurados na instalação do Browser Netscape. O caminho padrão para estas pastas de correio eletrônico no Windows95/NT é sempre o mesmo: "C:/ProgramFiles/

Netscape/Navigator/Mail/Inbox", a não ser que o usuário configure um caminho diferente do padrão. O desenvolvedor de aplicações ShockWave pode programar um comando chamado "GETNETTEXT" para o Netscape enviar uma mensagem para um servidor qualquer na Internet. O conteúdo da mensagem será as informações de uma das pastas de correio eletrônico de quem recebeu a animação ShockWave [VIT 97];

• Dave Yang descobriu que o ShockWave versão 5 com o Browser Netscape possibilita que um desenvolvedor de aplicações ShockWave tenha total acesso ao sistema de arquivos locais da máquina onde está sendo executado [VIT 97];

• O uso do ShockWave por máquinas de uma Intranet as deixa potencialmente vulneráveis a ataques. Animações ShockWave maliciosas que são executadas em uma Intranet podem copiar informações da máquina para uma outra máquina na Internet [VIT 97].

A figura central de uma Intranet, quando se trata de conexões Internet, é muitas vezes um Proxy Server, pois será através dele que as máquinas da Intranet terão acesso à Internet, como mostra a figura 4.1.

Como o Proxy Server concentra todas as conexões enviadas e recebidas da Internet, será nele que os mecanismos que barram o recebimento de conteúdos executáveis estão desenvolvidos. Estes mecanismos barram o recebimento dos conteúdos executáveis descritos no capítulo 2, sendo eles: Applet Java, JavaScript, ActiveX, VBScript e ShockWave. Os mecanismos criados são baseados na premissa de que o recebimento de qualquer conteúdo executável das tecnologias acima descritas através da Internet é proibido, a não ser que seja explicitamente permitido. A partir desta premissa delimita-se que os conteúdos executáveis incorporados nos protocolos das aplicações só serão recebidos da Internet se o administrador da ferramenta previamente configurá-la para isto.

Fig. 4.1 Funcionamento de um Proxy Server

Para o bloqueio dos conteúdos executáveis os filtros estão implementados para impedir que os conteúdos executáveis descritos no capítulo 2 sejam recebidos da Internet. Os filtros implementados no Proxy Server procuram nos documentos HTML que foram solicitados pelas máquinas da Intranet os marcadores que identificam cada uma das tecnologias, como descrito na tabela 4.1. Quando o recebimento não autorizado de um conteúdo é detectado, o código HTML é modificado e substituído por uma explicação, como é detalhado adiante.

Tab 4.1 Métodos que são utilizados pelo filtros para barrar o recebimento de conteúdos executáveis.

(*) - Este mecanismo tem um inconveniente, pois a linguagem JavaScript pode ser usado para montar ataques em sistemas que bloqueiam a entrada de Applets Java, como foi visto no item 3.2, mas como esta ferramenta também barra o recebimento de JavaScript, o método se torna seguro.

As permissões de acesso serão inteiramente baseadas nos endereços IPs das máquinas servidoras que possuem conteúdos executáveis para serem acessados e recebidos. Estas permissões funcionam da seguinte maneira:

Pelo Endereço IP de uma máquina: Para que os conteúdos executáveis de um único servidor da Internet possam ser recebidos pelas máquinas da Intranet, o endereço IP do servidor deverá estar configurado na tabela de endereços IPs permitidos;

Pela Classe de Endereços IP: Para que os conteúdos executáveis dos servidores de uma rede de computadores da Internet possam ser recebidos pelas máquinas da Intranet, a classe de endereços Ip da respectiva rede deverá estar cadastrada na tabela de endereços IPs permitidos.

Como o número de tecnologias existentes para a construção de conteúdos executáveis é grande, será necessário que o administrador da ferramenta informe também quais serão as tecnologias aceitas. Assim, para cada endereço ou classe de endereços IP o administrador terá que informar quais serão as tecnologias aceitas.

Mesmo que os conteúdos executáveis sejam recebidos somente de máquinas conhecidas, pode-se tomar a precaução de barrar a entrada pelo seu nome. Através desta opção poderão ser barrados os conteúdos executáveis mais conhecidos na Internet e que já foram noticiado como causadores de ataques às máquinas dos usuários que os acessam, tais como os Applets Java, os ActiveX e os ShockWave.

Como esta ferramenta está se baseando nos conteúdos executáveis existentes no momento de sua implementação, possivelmente no futuro surgirão algumas outras tecnologias que adicionarão vulnerabilidades às máquinas dos usuários que as receberem através da Internet. Para tentar reduzir estes riscos será deixado um espaço reservado para serem colocadas regras adicionais para o recebimento de documentos, sendo necessário que o administrador desta ferramenta configure quais serão os marcadores (Tags) que deverão ser analisados e substituídos, pois como foi visto, substituindo os conteúdos executáveis que estão entre os marcadores (TAGS) que identificam a tecnologia evita-se que ataques possam ser praticados às máquinas dos usuários através dos conteúdos executáveis.

Como os conteúdos executáveis recebidos da Internet podem ser barrados na entrada da Intranet, como mecanismo de explicação para o não recebimento dos mesmos, para cada regra implementada pela ferramenta é deixado um espaço textual disponível para que os códigos recebidos sejam trocados, isto é, ao invés do usuário receber o conteúdo executável da Internet, ele receberá uma explicação do motivo pelo qual não foi possível o recebimento do conteúdo executável.

O ambiente no qual é gerada a Interface de configuração para as regras de funcionamento do mecanismo é um servidor WWW disponível na mesma máquina em que o Proxy Server está sendo executado. Através dos formulários HTML é criada uma interface na qual é possível configurar todas as funcionalidades da ferramenta proposta, não havendo a necessidade do administrador acessar diretamente os arquivos de configuração, possibilitando também uma administração remota.

Para a restrição de acesso às páginas de configuração da ferramenta proposta, faz-se necessário o controle através de chave e senha, no qual somente algumas pessoas autorizadas terão acesso. Este mecanismo de autenticação através de chave e senha para a configuração da ferramenta interage diretamente com o sistema de segurança da máquina Unix.

Por questões de segurança no acesso às informações, todas as páginas HTML que são mostradas pela ferramenta são armazenadas em outra área do disco, não fazendo parte da estrutura de diretório do servidor WWW. Estas páginas estão salvas sem a extensão padrão ".html ou.htm", para não serem identificadas. Como elas não possuem a extensão característica das páginas HTML nem fazem parte da estrutura padrão de diretório do servidor WWW, é impossível que elas sejam acessadas diretamente através de um Browser WWW, sendo o seu acesso possível somente através de um programa CGI que monta estas páginas sabendo em quais arquivos elas estão armazenadas e em quais diretórios da máquina Unix é possível encontrá-las. Existe uma exceção para esta regra, isto é, somente a primeira página é acessível diretamente através do servidor WWW, pois será através dela que todas as demais funções são acessadas. As demais páginas da ferramenta só serão acessadas se a chave e a senha do administrador forem informadas.

5. Conclusão

Por mais que existam ferramentas que consigam bloquear algumas das tecnologias mencionadas neste documento, como é o caso das Firewalls e de alguns anti-vírus, sempre aparecerá uma nova tecnologia ou a combinação delas que serão utilizadas para aplicar ataques aos usuários da Internet.

Para que os resultados destes ataques fossem minimizados, pois um controle efetivo sobre todos os Browsers WWW de uma Intranet é inviável, surgiu a solução exposta na seção 4 deste documento, que barra o recebimento de conteúdos executáveis na entrada da Intranet, deixando passar somente quando o local de origem do conteúdo executável é conhecido e foi configurado pelo administrador da ferramenta para que o seu recebimento fosse aceito.

Esta não é a melhor solução para o problema, uma vez que a melhoria da qualidade dos documentos que utilizam conteúdos executáveis é substancial, e a solução proposta na sessão 4 garante a segurança mas restringe o recebimento destas tecnologias somente de locais conhecidos. Por mais que um conteúdo executável seja confiável, se não fizer parte da relação de locais conhecidos e autorizados, seu recebimento é negado.

Existem alguns estudos que incluem assinaturas digitais nos conteúdos executáveis para que os mesmos possam identificar a origem, como é o caso dos controles ActiveX, mas mesmo assim isto não resolve os problemas de segurança gerados pela utilização destas tecnologias, pois por mais que um código tenha uma assinatura digital ninguém garante o resultado de sua execução.

Para resolver os problemas qualquer conteúdo executável que fosse recebido por um Browser WWW deveria passar por Modelos de Segurança padrão criado no Browser WWW para a execução dos mesmos, como é mostrado na figura 5.1. Este modelo de segurança é que iria permitir que um conteúdo executável pudesse ser processado, independe da tecnologia que foi utilizada para a criação do mesmo.

Para isto uma padronização no uso dos conteúdos executáveis é necessária, isto é, os conteúdos executáveis primeiramente seriam executados e analisados pelo Modelo de Segurança para depois sua execução ser aplicada ao Browser WWW.

Isto tira das linguagens que desenvolvem conteúdos executáveis a tarefa de criar mecanismos alternativos para resolver os problemas de segurança gerados por soluções mal projetadas e muitas vezes mal implementadas.

Referências Bibliográficas:

[BIL 97] BILTON, Jean-Paul. Important warning and apologies. Disponível na Internet. http://www.dyade.fr/actions/VIP/JS_pap2.html.

[BRU 97] BRUNNSTEIN, Klaus. Hostile ActiveX Control demonstrated. Disponível na Internet. http://www.cs.washington.edu/homes/

egs/activex/german.txt.

[CA 96.05] CA-9605. Java implementations can allow connections to an arbitrary host. FTP anônimo. ftp://info.cert.org no arquivo /pub/cert_advisories/CA-96.05.java_applet_security_mgr.

[DEA 96] DEAN, Drew; FELTEN, Edward W.; WALLACH, Dan S. Java security: from hotJava to Netscape and beyond. Disponível na Internet. http://www.cs.princeton.edu/

sip/pub/secure96.html.

[GAR 96] GARFINKEL, Simson. Risks of ActiveX. Disponível na Internet. http://catles.ncl.ac.uk/Risks/.

[LAD 96a] LADUE, Mark D. Java insecurity. Disponível na Internet. http://www.cyber.com/mirror/mladue/Java_insecurity.html.

[LAD 96b] LADUE, Mark D. Hostile applets on the horizon. Disponível na Internet. http://www.math.gatech.edu/~mladue/

HostileArticle.html.

[LAD 97] LADUE, Mark D. When Java was one: threats from hostile byte code and Java platform viruses. Disponível na Internet. http://www.cyber.com/mirror/mladue/java_was_1.html.

[MCG 96] MCGRAW, Gary; FELTEN, Edward. Java security: hostile applets, holes, and antidotes. New York : J. Wiley, 1996. 192 p.

[PRI 96] PRINCETON Secure Internet Programming Team. Java security: frequently asked questions. Disponível na Internet. http://www.cs.princeon.edu/

sip/java-faq.html.

[ROJ 96] RAJAGOPALAN, Sivaramakrishnan; MARTIN, David M.;RUBIN, Aviel D. Blocking Java applets at the firewall. Disponível na Internet. http://www.cs.bu.edu/

techreports/96-026-java-Firewalls.ps.Z

[RUB 97] RUBIN, Aviel D.; GEER, Daniel; RANUM, Marcus J. WEB security sourcebook. New York : J. Wiley, 1997. 342 p.

[VIT 97] VITRY, David de. ShockWave security alert. Disponível na Internet. http://www.webcomics.com/shockwave/