Segurança do Browser

Os browsers quando foram lançados exibiam apenas textos (ASCII e HTML) e imagens (GIF e JPEG). Devido às limitações da linguagem HTML (Hyper-Text Markup Language), logo surgiram alternativas para ampliar a capacidade do browser para torná-lo mais dinâmico e interativo. Uma das primeiras iniciativas neste sentido foi a adoção dos helpers (aplicativos auxiliares) que evoluiram para os atuais plug-ins.

Os plug-ins são programas executáveis que permitem ao browser executar arquivos em formatos diferentes de HTML, como áudio, animações e acesso a banco de dados. Dois exemplos de plug-in bastante populares são o Abode Acrobat Reader e Macromidia Shockwave.

O grande problema dos plug-ins é que sua segurança está baseada na confiança em quem desenvolveu o aplicativo. Como o plug-in tem acesso irrestrito ao seu sistema, é possível ter acesso a informações no disco local, abrir conexões de rede ou introduzuir um Cavalo de Tróia. Neste caso, não só a estação poderá fircar comprometida, mas também sua rede interna.

Com a introdução de linguagens/tecnologias como Java, JavaScript, VBscript e ActiveX, o browser passou a receber código ativo pela rede, ou seja, o simples fato de se visitar um site na Internet já é o suficiente para receber um código malicioso que possa ter acesso a qualquer parte do seu sistema (processador, memória, discos e rede) e, até mesmo, desligar sua estação.

Os browsers, como Internet Explorer (IE) e Netscape Navigator (NN), possuem parâmetros de configuração que impedem que códigos deste tipo sejam executados, mas, por default, os browsers são configurados para permitir que qualquer código seja carregado e executado.

A seguir apresentamos os problemas de segurança em quatro tecnologias que permitem a implementação de código ativo: JavaScript, Java e ActiveX.

JavaScript

JavaScript, apesar do nome, não tem relação com a liguagem Java. A linguagem JavaScript é semelhante a C/C++ e foi desenvolvida pela Netscape, incorporada ao Navigator e, posteriormente, ao IE. JavaScript é uma linguagem interpretada, ou seja, o código é incluído dentro do próprio arquivo HTML, interpretado pelo browser e depois executado.

JavaScript possui limitações que garantem alguma segurança, como não permitir acesso a arquivos no disco da estação e impedir abrir conexões de rede com outros sistemas. Apesar destas limitações, JavaScript pode ser utilizada para ataques do tipo engenharia social e Denial of Service (DoS). A seguir, apresentamos alguns exemplos bastante simples de ataques utilizando JavaScript:

Applets Java

Java, desenvolvida pela Sun Microsystems, é uma linguagem poderosa, orientada a objetos e similar ao C++. Um programa escrito em Java deve ser compilado para gerar um código intermediário, independente de plataforma, conhecido como bytecode. De forma simplificada, quando uma applet Java chega ao seu browser, deve existir uma máquina virtual Java (Java Virtual Machine - JVM) que interprete o bytecode e traduza-o para o ambiente onde o browser está sendo executado. Tando o IE quanto o NN oferecem suporte a Java.

A preocupação com a segurança em Java começa pela própria linguagem que foi desenvolvida para reduzir as chances de erros por parte dos desenvolvedores, comuns em programas em C e C++. Mecanismos de alocação/desalocação de memória, manipulação de ponteiros e arrays foram implementados de forma a reduzir a chances de bugs nos programas desenvolvidos.

Para garantir a segurança do ambiente onde a applet é carregada, Java cria uma sandbox (caixa de areia), onde o código é executado de forma a ter acesso restrito e controlado aos recursos do ambiente onde está sendo processado. Além da sandbox, a segurança do Java envolve mais três componentes: Java Class Loader, Bytecode Verifier e Java Security Manager.

Em geral, applets Java não têm permissão de ler, gravar, alterar ou eliminar qualquer arquivo no disco da estação onde o código está sendo executado. Além disto, applets não podem abrir conexões de rede, ter acesso direto ao hardware ou iniciar outros aplicativos no cliente.

Apesar do mecanismo de sandbox, uma applet Java pode causar diferentes ataques do tipo Denial of Service (DoS) no browser, como loop infinito, alocação de grandes áreas de memória, problemas no arquivo de paginação e/ou swap, criação de inúmeras janelas levando o sistema a problemas de pilha etc. O maior problema na segurança do Java surge da complexidade da implementação da sandbox. Inúmeros bugs já foram encontrados e documentados, como podemos observar no site "A Collection of Increasingly Hostile Applets".

ActiveX

Componentes ActiveX são programas executáveis, desenvolvidos em uma linguagem de programação qualquer, como C, C++ ou Visual Basic, e encapsulados em um arquivo OCX. Um componente ActiveX, depois de carregado pelo browser, tem acesso irrestrito a qualquer recurso do seu sistema operacional e, até mesmo, ao hardware. Um controle ActiveX hostil pode infectar sua estação com um vírus, eliminar seus arquivos e desligar seu computador. A seguir apresentamos alguns exemplos de vulnerabilidades oferecidas pelo ActiveX:

O grande problema de segurança do ActiveX é seu mecanismo de autenticação, baseado no Autenticode. Qualquer desenvolvedor pode criar um componente ActiveX e solicitar uma assinatura digital para seu código. A assinatura é uma garantia dada por uma autoridade de certificação (Verisign por exemplo), que o código foi escrito realmente por seu autor e que não foi alterado. A assinatura garante a autencidade e a integridade do código, mas não garante segurança. Um código pode ser autêntico e íntegro e mesmo assim conter um vírus ou desligar sua máquina.

Quando o ActiveX é carregado, o browser verifica a assinatura do código e abre uma janela informando o nome de seu autor. Depois disto existem duas opções: aceitar o programa ou recusá-lo. A segurança do ActiveX está baseada inteiramente na decisão correta do usuário em aceitar  ou não código. Se a escolha for errada, é possível que sua estação e toda a rede privada fiquem comprometidas.

Como reduzir os riscos?

Este artigo foi escrito por Luiz Paulo Maia e pode ser contatado pelo email: lpmaia@training.com.br

Referências:

Exploder
http://www.halcyon.com/mclain/ActiveX/

Password Theft Using ActiveX Control
http://www2.axent.com/swat/swat/1attacks/win95/craigs/passgrab.htm

The ActiveX Hard Disk Explorer
http://www.iseran.com/ActiveX/filesearch.html

A Comparison between Java and ActiveX Security
http://www.users.zetnet.co.uk/hopwood/papers/compsec97.html

Java Security FAQ
http://www.cs.princeton.edu/sip/faq/java-faq.php3

FAQ about Applet Security
http://java.sun.com/sfaq/

A Collection of Increasingly Hostile Applets
http://www.rstcorp.com/hostile-applets/index.html

CERT, FAQ About Malicilous Web Scripts Redirected by Web Sites
http://www.cert.org/tech_tips/malicious_code_FAQ.html

CERT Advisory CA-2000-02, Malicius HTML Tags Embedded in Client Web Requests
http://www.cert.org/advisories/CA-2000-02.html

CERT Understanding Malicious Content Mitigation for Web Developers
http://www.cert.org/tech_tips/malicious_code_mitigation.html

Security Tradeoffs: Java vs. ActiveX
http://www.cs.princeton.edu/sip/faq/java-vs-activex.html

A Comparison between Java and ActiveX Security
http://www.users.zetnet.co.uk/hopwood/papers/compsec97.html