Conteúdos executáveis são códigos(dados) que são transportados através da rede para rodar em máquinas remotas. Embora seja uma idéia muito interessante e poderosa, é um convite a problemas de segurança.

A essência do problema é que programas rodando em um computador geralmente têm acesso a certos recursos da máquina hospedeira. No caso de conteúdos executáveis, o programa que está rodando pode não ser confiável. Se um web browser que baixa e roda um conteúdo executável não é cuidadoso para restringir o acesso que o programa "não confiável" tem, ele pode tornar à tona um programa malicioso com a mesma habilidade de destruir tal como hacker se ganhasse acesso a uma máquina hospedeira. Porém, a solução não é tão simples como restringir completamente o acesso a recursos dos programas que são baixados. Se alguém deseja ter um conteúdo executável realmente útil e seguro, o acesso a recursos da máquina precisa ser controlado.

Torna-se necessário identificar os recursos e providenciar certos tipos de acesso limitado a estes recursos, de acordo com os ataques que esses recursos podem sofrer.

Os principais tipos de ataque, causados por conteúdos executáveis são:

• ataques de integridade: danificação ou modificação de dados.

• ataques de disponibilidade: negativas de serviço de ataques faz com que recursos fiquem indisponíveis para o uso ao qual eles foram propostos.

• ataques de revelação: revelação de informações sobre o usuário ou sobre a máquina hospedeira

• ataques de aborrecimento:

2. Segurança em Java

 

Uma das principais características de Java é a sua portabilidade.

Pequenos programas, applets, podem ser dinamicamente carregados através da rede e serem executados localmente através de um web browser.

A forma como Java oferece conteúdo executável é através de um Web browser com um interpretador Java e uma biblioteca dinâmica embutidos. O web browser baixa o programa Java e o interpretador o executa. Com esse modelo existem três níveis de segurança que devem ser estudados: a linguagem, as bibliotecas e o próprio web browser.

 

1. A Linguagem

 

As principais características da linguagem do ponto de vista de segurança são: controle de acesso para variáveis e métodos dos objetos, segurança do sistema de tipos, não uso de ponteiros como tipo de dados da linguagem, garbage collection e uso de pacotes com espaço de nomes distintos.

O controle de acesso para variáveis e métodos dos objetos previne que objetos sejam usados por códigos "não confiáveis" com a garantia de que eles não serão utilizados inapropriadamente. Por exemplo, a biblioteca Java contém a definição para um objeto File. Um objeto File tem um método público para leitura e um método privado de baixo nível também para leitura. O método de leitura público primeiro realiza a checagem de segurança e então chama o método privado. A linguagem garante que códigos não confiáveis possam manipular um objeto File apenas de forma segura, providenciando acesso somente para os métodos públicos. Assim, as facilidades do controle de acesso permitem que os programadores escrevam suas bibliotecas que são garantidas pela linguagem que serão seguras desde que seus controles de acesso sejam especificados corretamente.

Uma segunda facilidade oferecida pelo controle de acesso é a habilidade de declarar classes e métodos como final. Isto previne que um programador malicioso faça uma subclasse de uma classe crítica da biblioteca ou sobrescreva os métodos da classe. Isto garante que certas partes do comportamento de um objeto não sejam modificadas.

A checagem de tipos em tempo de compilação e em tempo de execução de variáveis são garantidas de serem compatíveis. Isto garante que conversões são checadas tanto em tempo de compilação quanto de execução para se ter certeza de que são válidas. Isto previne que objetos sejam forjados para se ter controle de acesso. Exemplo: previne que um código malicioso, que realiza uma conversão de um objeto File para um tipo malicioso, MyFile, que tem a mesma forma do tipo File, mas com todos os métodos públicos.

A eliminação de ponteiros como tipo de dados previne tanto o mau uso acidental de ponteiros quanto o uso malicioso. Exemplo: previne que um código malicioso acesse diretamente um método privado da classe File usando aritmética de ponteiro a partir do ponteiro de um objeto File.

 

O uso de garbage collection recupera memória não utilizada ao invés de deixar essa tarefa explicitamente a cargo do usuário. Isso elimina tanto uma grande classe de erros de programação como também potenciais riscos de segurança. Por exemplo, se a desalocação fosse manual, poderia ocorrer uma outra forma de conversão ilegal. Primeiro, o código malicioso cria um objeto do tipo MyFile e, então, desaloca a memória usada pelo objeto, guardando o ponteiro. Então, ele imediatamente cria um objeto File que tem o mesmo tamanho. Se isto é feito cuidadosamente (conhecendo-se como a alocação e desalocação de memória funciona), o novo ponteiro do objeto File é o mesmo que o ponteiro do primeiro objeto MyFile. O código malicioso pode agora acessar os métodos privados do objeto MyFile.

Java usa pacotes para providenciar encapsulamento de espaço de nomes. Do ponto de vista de segurança, pacotes são úteis porque permitem que códigos baixados sejam facilmente diferenciados dos códigos locais. Isso previne que uma biblioteca de sistema com código malicioso que foi baixada seja executada. A linguagem garante que quando uma classe é referenciada, o sistema primeiro procura no espaço de nomes local, para depois procurar no espaço de nomes da classe referenciada. Isto também garante que uma classe local não possa acidentalmente referenciar uma classe baixada.

 

2. As Bibliotecas

 

O ambiente de execução de Java vem com uma variedade de bibliotecas úteis, que provêm acesso ao sistema de arquivos, ferramentas de manipulação de janelas e uma variedade de outras ferramentas. A correta especificação dessas janelas é de suma importância. A própria linguagem pode oferecer facilidades para se criar bibliotecas seguras, mas se o código da biblioteca não é especificado e escrito corretamente o sistema não é seguro. Uma vez que as bibliotecas são parte do ambiente de execução de Java que oferece acesso aos recursos do sistema, é de fundamental importância a implementação correta dessas bibliotecas.

As restrições de acessos dessas bibliotecas são baseadas em três mecanismos. O primeiro é o mecanismo da linguagem de oferecer restrições de acesso aos métodos e variáveis dos objetos. O segundo é o uso de ClassLoaders especializados em carregar código importado. O último é o uso de chamadas explícitas ao SecurityManager global para checar a validade de certas operações.

4. Web Browsers

 

O próprio web browser tem um papel fundamental na segurança do sistema, pois define e implementa a política de segurança para rodar o código Java baixado. Um web browser deve conter um interpretador Java, uma biblioteca de classes com um SecurityManager implementado e vários ClassLoaders. Do ponto de vista de segurança, a implementação do SecurityManager é mais importante do que a implementação dos ClassLoaders.

O SecurityManager controla o acesso aos recursos críticos do sistema. Ele permite ao desenvolvedor do web browser implementar uma política de segurança específica criando uma subclasse de SecurityManager e sobrescrevendo certos métodos, e instalar a nova versão do SecurityManager. Se o web browser não instala um SecurityManager, um applet poderá ter o mesmo tipo de acesso de uma aplicação Java local.

5. Problemas de Segurança em Java

 

O SecurityManager não tem um método para controlar a criação de janelas ou controlar o que pode ser mostrado ou tocado. Não há um mecanismo para controlar o acesso do applet aos dispositivos de entrada. Existem certas situações onde seria preferível ter uma política de segurança mais específica em relação aos vários dispositivos de entrada. Um applet pode alocar uma quantidade de memória arbitrária, criando novos objetos. Esse problema não é tão sério, visto que o browser pode limitar a quantidade de memória disponível para o applet. O browser poderia prover um método para matar o applet e recuperar a memória.

 

A conclusão que tiramos é que Java foi proposta inicialmente para providenciar maior poder e flexibilidade às aplicações. Porém, há um inevitável efeito colateral entre esse aumento de poder e o risco de segurança de um sistema que usa Java. Deve-se encontrar os limites de segurança necessários para balancear os dois lados da melhor maneira possível. Muitos sistemas não estão conectados à Internet porque é um risco de segurança que ultrapassa os benefícios do uso da Internet. Qualquer um que esteja considerando usar Java precisa entender que há um aumento nos riscos de segurança, mas ela prover um mecanismo de segurança de certa forma razoável para aplicações da Internet.

4. Segurança em ActiveX

 

1. Introdução – O que é a Tecnologia ActiveX?

 

Java não esta só no mercado de aplicações iterativas na Web. Na Internet Professional Developer’s Conference (PDC), a Microsoft anuncia a tecnologia ActiveX, promovendo altas vantagens em alguns aspectos comparado `as tecnologias existentes no mercado.

Três componentes fazem parte da tecnologia apresentada pela Microsoft: ActiveX Controls, ActiveX Scripting e ActiveX Documents .

ActiveX Controls – Funcionam como "OLE Controls" (OCX). Podem residir na maquina cliente e podem ser encontradas e baixadas na Internet. Um ActiveX Control pode manipular iterações com os clientes. Como exemplo, podemos citar um simples botão, ou ferramentas complexas de relatório.

ActiveX Scripting – São usados para coordenar as atividades de um ActiveX Control nas paginas Web. Algumas das linguagens usadas nesta tecnologia são Java Script e VB Script e usam OLE AUTOMATION para comunicação com o ActiveX Control. Este, levanta eventos OLE que podem ser manipulados no código do ActiveX em resposta a iterações com os usuários, como exemplo um click num botão.

ActiveX Documents – Estes podem ser vistos como paginas Web. Permite-se ao usuário navegação e edição de documentos.

Desta forma, a Microsoft define a Tecnologia ActiveX como um conjunto integrado de tecnologia que habilita a iteração entre softwares em um ambiente de rede. Por sua vez, de outro ponto de vista, esta nova tecnologia pode ser encarada, como uma adaptação da tecnologia OLE para o ambiente Web. Assim, a comunicação entre aplicativos está garantida, promovendo boa funcionalidade e deixando um pouco a desejar com relação a segurança no ambiente da Internet.

2. Vantagem de um ActiveX

ActiveX, através de sua excelente funcionalidade, permite a produção de ambientes mais amigáveis, mais iterativos, possibilitando uma maior aproximação com o usuário final.

Em termos de desempenho, quando visita-se um Site que possui um ActiveX Control, de acordo com as opções de segurança de seu navegador, ele será instalado na maquina cliente. A partir daí, se uma nova visita for feita ao mesmo Site, só será baixado novamente se a versão do Control estiver desatualizada. Enquanto que, com o Java Applet, cada vez que visitarmos um Site ele será baixado novamente, pois não há um processo de instalação na máquina cliente. Além disto, Java não pode iniciar uma outra aplicação na maquina cliente, coisa que o ActiveX faz muito bem.

Desta forma, uma vez instalado, um ActiveX Control tem bom desempenho pois entende a linguagem do Windows 95 ou NT.

3. Desvantagem de um ActiveX

 

A Microsoft investiu em funcionalidade e eficiência. Para isto teve que abdicar de certos requisitos de segurança.

Ao mesmo tempo em que a instalação de um ActiveX Control na maquina cliente mostra-se vantajoso, ele deixa a desejar no aspecto de segurança. Dependendo do nível de segurança de seu navegador, no caso o Internet Explorer (IE), um malicioso ActiveX Control pode ser instalado e provocar sérios danos. Também, esta nova tecnologia só e suportada pôr versões mais modernas que o IE 3.0 e do Netscape 3.0 para Windows 95 ou NT e que tenha o active plug-in.

 

4. Segurança na Web, até que ponto?

 

ActiveX são programas nativos e então podem fazer tudo que um programa nativo a plataforma Windows faz. Pode ler e escrever arquivos, fazer administração de rede, determinar as capacidades do sistema no qual estão rodando e outras coisas mais. Isto promove maior poder e funcionalidade, comparado a um Java Applet, pôr outro lado, compromete todo o sistema de segurança. Pode se instalar vírus, excluir arquivos e tudo mais que os Hackers imaginarem. Pôr sua vez, um Java Applet é menos funcional. Não está habilitado a escrever no sistema de arquivo do cliente e muito menos a se comunicar com programas não-Java na maquina cliente, coisa que o ActiveX faz muito bem. Mas pôr rodar em uma maquina virtual (Java Virtual Machine - JVM), oferece maior grau de segurança.

O modelo encontrado pela Sun MicroSystem foi limitar o poder funcional de um Applet e fazê-lo rodar em uma máquina virtual. No entanto, a Microsoft está trabalhando em sistemas de Authenticode, o qual valida um ActiveX vindo de desenvolvedores aprovados com uma assinatura digital. Esta, contém informações a respeito dos autor e companhia que desenvolveram o ActiveX Control. Corresponde, então, a apenas uma questão de confiança.

Com relação ao IE, existem três níveis de segurança ao ActiveX: alto, médio e baixo. O nível alto não permite que algum controle não assinado ou desatualizado (out of date) seja instalado, nível default, recomendado a todos os usuários. O nível médio, avisa quando controles não assinados digitalmente estão para serem instalados e a decisão de aceitar a instalação ou não fica a cargo do usuário. O ultimo nível de segurança permite a instalação de qualquer controle, assinados ou não, sem que haja algum aviso, configuração não recomendada a algum tipo de usuário.

Apesar do Java Applet apresentar uma maior segurança que o ActiveX Control, e uma tecnologia bastante limitada. Foram encontrados diversos bugs no JVM, tornando possível aos Hackers danificar as maquinas dos clientes que usavam Java Applet. Então, como fica a segurança na Internet ? De fato, não existe algo realmente seguro e apesar de ser limitada, a solução da Microsoft para o ActiveX (AuthentiCode), alguns especialistas acreditam e apostam nesta tendência.

Não há um modelo de segurança: o que existe é um ato de fé. Em nível de Intranet, o ActiveX é um excelente produto, mas para a Internet é bastante arriscado confiar na boa fé dos desenvolvedores de um ActiveX.

Independentemente da disputa entre as diversas tecnologias, muitas companhias utilizam FireWalls para proteger sua rede de ActiveX ou Java Applet. No entanto, esta solução bloqueia o código executável sem fazer algum tipo de inspeção de sua validade.

No intuito de minimizar este fato, algumas corporações apostam nos chamados Firewalls Inteligentes, os quais são uma tecnologia de armazenamento de estado. Estes Firewalls baseiam seu controle de decisão no estado da comunicação, derivadas de comunicações passadas e do estado da aplicação em si. Basicamente, checagem com armazenamento de estado – Stateful Inspection – permite ao Firewall aprender com tentativas de comunicações passadas para melhor avaliar tentativas presentes e futuras. Porém, quando um código executável de origem desconhecida é encontrado, o controle da decisão e reduzido a adivinhação.

Chegamos ao mesmo ponto: não existe um total controle sobre a segurança e há sempre um risco inerente ao se baixar algo na Internet. Toda a sociedade sofre com esta situação. Uma grande corporação pode ter todo seu sistema de informação danificado pôr um Controle malicioso. Não é dever do usuário final saber o que é um ActiveX ou um Java Applet, pôr exemplo, para determinar ou não sua aceitação quando se depararem com um pela Internet. O ambiente da Internet tem que ser seguro, independente das tecnologias que rodem nela.

6. Segurança em JavaScript

 

1. Breve Histórico

 

Apesar da semelhança no nome JavaScript foi desenvolvido pela Netscape Corporation e Java pela Sun Microsystems.

 

JavaScript é suportado no Navigator (2.x, 3.x e 4.x) e no Internet Explorer (3.x e 4.0) onde é chamado de "JScript". Originalmente chamada de LiveScript, o código JavaScript é colocado diretamente no texto de um documento HTML ( ao invés de ser referenciado, como uma imagem ou um Java Applet). Para browsers que não entendem JavaScript , o código JavaScript simplesmente é visto como um comentário no código HTML. Já para browsers que o interpretam ele pode prover uma funcionalidade adicional para página Web, algo que não seria conseguido com simples cláusulas HTML. Enquanto JavaScript prover uma funcionalidade incremental, ela é sintaticamente simples e menos poderosa que Java.

 

2. "Brechas" conhecidas na segurança de JavaScript

 

JavaScript também tem uma história de problemas com segurança. Não como as "brechas" de Java, que potencialmente podem trocar dados no disco do usuário, as "brechas" de JavaScript geralmente envolvem a privacidade do usuário. Apesar de alguns bugs terem sidos resolvidos outros explodem a cada dia. O mais recente foi relatado em 16 de outubro de 1997.

A seguir analisamos algumas brechas na segurança de JavaScript e a data em que estas "brechas" foram relatadas.

 

1. Interceptação de arquivos na Máquina do Usuário Local(16 de Outubro, 1997)

 

O Microsoft Internet Explorer 4.0 está vulnerável a páginas que permitem um operador de um Web Site remoto espionar o conteúdo de algum texto imagem ou arquivo HTML localizado na sua máquina ou um arquivo localizado em um servidor de arquivo montado. Firewalls não podem nos proteger contra este ataque e os browsers estão vulneráveis mesmo quando rodam no modo de "Alta Segurança". Na versão para Macintosh do IE 4.0 aparentemente não são afetadas.

Este bug foi descoberto pelo consultor alemão Ralf Hueskes e é conhecido como "Freiburg attack" consistem no truque de usar JavaScript para criar um frame invisível de 1x1 pixel. Enquanto o browser abre o site remoto, o programa JavaScript, rodando no frame invisível, varre todos os arquivos da máquina do usuário local em busca de arquivos de nomes bem conhecidos e podem então ser enviados para algum site na Internet. Este bug não permite que JavaScript modifique ou prejudique os arquivos.

 

 

2. Habilidade de Monitorar a Sessão de Usuário ( 29 de Agosto, 1997)

Um grupo de bugs relatados permitem páginas com JavaScript monitorar todas as páginas visitadas pelo usuário durante a sessão, capturando as UR:s dos documentos vistos e transmitindo-as para um Host em algum lugar na Internet. Algumas variações deste bug permitem uma página maliciosa capturar conteúdo de formulários, cookies e informações sobre outros elementos na página. Informações sempre podem ser roubadas mesmo se o usuário estiver visualizando páginas "seguras" encriptadas com SSL e usuários trabalhando atrás de sistemas de Friewalls corporativos estão tão vulneráveis quanto aqueles que estão conectados diretamente na Internet. O único risco é a privacidade do usuário, dados e softwares localizados na máquina do usuário não podem ser modificados.

Os seguintes browsers são vulneráveis a este bug:

• Microsoft Internet Explorer 3.x e 4.0
• Netscape Navigator 3.x
• Netscape Comunicator 4.x

1. Observação de Informações através de Frames (10 de Julho,1997)

Um tipo de bug relatado envolve observação de informação através dos frames do browser. Para entender porque isto é um problema, considerando dois diferentes sites compartilhando a mesma janela, um em cada frame. Seria obviamente indesejável se um programa JavaScript baixado de um site não confiável espionasse o conteúdo de um frame de outro site, particularmente se que frame contendo informações confidenciais.

JavaScript fechou algumas destas "brechas" mas deixou outras. Um JavaScript não pode recuperar a URL de um documento baixado de um outro site, mas ele pode roubar os seguintes itens do respectivo documento:

• URLs de todas imagens no documento
• Outras informações das imagens, como largura e comprimento
• URLs de todos os Applets
• URLs de todos os ActiveX Controls

2. "Brecha" de Enviar Arquivo ( 25 de Junho, 1997)

Embora não estritamente relacionado a JavaScript, um bug no modo em que formulários são tratados pelo Navigator permite que programas JavaScript enganando o browser enviando algum arquivo do HD do usuário local. O Usuário não terá conhecimento que o envio tem sido substituído a não ser que ele tenha checado a opção "Avisar antes de submeter um Formulário Inseguro" na dialog box Opções de Segurança. Apesar desta opção ser selecionada, o Navigator falhará em produzir um aviso se o servidor remoto por acaso utilizar SSL para estabelecer uma conexão "segura".

1. Conclusão

JavaScript contém "brechas" na segurança. Muitas delas tem sido diagnosticadas, mas novas vem aparecendo numa taxa constante. Indubitavelmente ainda existem bugs desconhecidos. As pessoas que se preocupam com a falta de privacidade das informações são encorajadas a desabilitar JavaScript completamente.

2. Bibliografia