Cross-site Scripting (XSS)

Geral

Ataques Cross-Site Scripting são um tipo de problema de injeção, em que scripts

maliciosos são injetados nos sites de outra forma benigna e confiável. Ataques de
cross-site scripting (XSS) ocorre quando um invasor usa uma aplicação web para
enviar código malicioso, geralmente na forma de um script do lado do browser, para
um usuário final diferente. Falhas que permitem que esses ataques para ter sucesso
são bastante generalizada e ocorrer em qualquer lugar de uma aplicação web usa a
entrada de um usuário na saída ele gera sem validar ou codificá-lo.
Um atacante pode usar XSS para enviar um script malicioso para um usuário
desavisado. O navegador do usuário final não tem como saber que o script não deve
ser confiável, e executará o script. Porque ele acha que o roteiro veio de uma
fonte confiável, o script malicioso pode acessar os cookies, tokens de sessão, ou
outras informações confidenciais retidos pelo navegador e usado com esse site.
Esses scripts podem até mesmo reescrever o conteúdo da página HTML.

Descrição

Ataques Cross-Site Scripting (XSS) ocorrem quando:

1 - Dados entram em uma aplicação Web através de uma fonte não confiável, mais
freqüentemente um pedido web.
2 - Os dados são incluídos no conteúdo dinâmico, que é enviado para um usuário da
web, sem ser validado por um código malicioso.
O conteúdo malicioso enviado para o navegador da web, muitas vezes toma a forma de
um segmento de JavaScript, mas também pode incluir código HTML, Flash ou qualquer
outro tipo de código que o navegador pode executar. A variedade de ataques baseados
em XSS é quase ilimitada, mas eles geralmente incluem transmissão de dados
privados, como biscoitos ou outras informações de sessão para o atacante,
redirecionando a vítima para conteúdo web controlado pelo atacante, ou realizar
outras operações maliciosos na máquina do usuário sob o guise do site vulnerável.

Armazenados e refletidos ataques XSS ~

Ataques XSS podem geralmente ser classificados em duas categorias: armazenados e
refletida. Há um terceiro tipo muito menos conhecido de um ataque XSS chamada XSS
baseado em DOM.

Ataques XSS armazenados ~

Ataques armazenados são aqueles onde o código injetado é permanentemente armazenado
nos servidores de destino, como em um banco de dados, em um fórum de mensagens,
registro de visitantes, campo de comentários, etc. A vítima, em seguida, recupera o
script malicioso do servidor quando ele solicita o armazenados informação.

Ataques XSS refletidos ~

Ataques de reflexão são aqueles onde o código injetado é refletido para fora do
servidor web, como em uma mensagem de erro, resultado de pesquisa, ou qualquer
outra resposta que inclui alguns ou todos a entrada enviados para o servidor como
parte do pedido. Ataques de reflexão são entregues às vítimas através de outra
rota, como em uma mensagem de e-mail, ou em algum outro servidor web. Quando um
usuário é levado a clicar em um link malicioso ou submeter um formulário
especialmente criado, o código injetado viaja para o servidor web vulnerável, o que
reflete o ataque de volta para o navegador do usuário. O navegador, em seguida,
executa o código porque veio de um servidor "confiável".

Consequências ataque XSS ~

A conseqüência de um ataque XSS é o mesmo, independentemente de se ele é armazenado
ou refletido (ou DOM Based). A diferença está na forma como a carga chega ao
servidor. Não se iluda pensando que um "somente leitura" ou "brochureware" site não
é vulnerável a sérios ataques XSS refletido. XSS pode causar uma variedade de
problemas para o usuário final, que variam em gravidade de um aborrecimento para um
compromisso relato completo. Os ataques XSS mais graves envolvem a divulgação de
cookie de sessão do usuário, permitindo ao invasor sequestrar a sessão do usuário
(hijacking) e assumir a conta. Outros ataques danosos incluem a divulgação de
arquivos do usuário final, a instalação de cavalos de Tróia, redirecionar o usuário
para outra página ou site, ou modificar a apresentação de conteúdo. Uma
vulnerabilidade de XSS permite que um atacante possa modificar um comunicado de
imprensa ou notícia, o que poderia afetar o preço das ações de uma empresa ou
diminuir a confiança do consumidor. Uma vulnerabilidade XSS em um site farmacêutico
poderia permitir que um invasor modificar informação sobre a dosagem, resultando em
uma overdose.

Como determinar se você está vulnerável ~

Falhas de XSS podem ser difíceis de identificar e remover de um aplicativo web. A
melhor maneira de encontrar falhas é realizar uma revisão do código e procurar por
todos os lugares onde a entrada de um pedido HTTP poderia fazer o seu caminho para
a saída HTML segurança. Note-se que uma variedade de diferentes etiquetas de HTML
pode ser utilizada para transmitir um JavaScript nocivo. Nessus, Nikto, e algumas
outras ferramentas disponíveis podem ajudar a digitalizar um site para essas
falhas, mas só pode arranhar a superfície. Se uma parte de um site é vulnerável,
existe uma alta probabilidade de que existem outros problemas também.

Como se proteger ~
Além disso, é fundamental que você desative o suporte a HTTP TRACE em todos os
servidores web. Um atacante pode roubar dados de cookies via JavaScript mesmo
quando o document.cookie está desabilitado ou não é suportado no cliente. Este
ataque é montado quando um usuário posta um script malicioso para um fórum para
quando outro usuário clica no link, um assíncrono rastreamento de chamada HTTP é
acionado, que recolhe informações do cookie do usuário do servidor e, em seguida,
envia-o para outro servidor malicioso que coleta as informações do cookie para que
o atacante pode montar uma sessão de seqüestrar ataque. Isso é facilmente mitigado
através da remoção de suporte para HTTP TRACE em todos os servidores web.

Sintaxe XSS alternativa

XSS usando Script em Atributos ~

Ataques XSS podem ser realizados sem o uso de <script> </ script> tags. Outras
marcas vão fazer exatamente a mesma coisa, por exemplo:

<body onload=alert('test1')>

ou outros atributos como: onmouseover, onerror.

onmouseover

<b onmouseover=alert('Wufff!')>click me!</b>

onerror

<img src="http://url.to.file.which/not.exist" onerror=alert(document.cookie);>

XSS usando Script Via Esquemas de URL codificada ~
Se precisar se esconder contra filtros de aplicações web que podem tentar codificar
caracteres de corda, por exemplo: a = A (UTF-8) e usá-lo em IMG tag:

<IMG SRC=j&#X41vascript:alert('test2')>

Há muitos tipos diferentes de notações UTF-8 que nos dão mais possibilidades.

XSS usando codificação de código ~

Podemos codificar nosso script em base64 e colocá-lo na tag META. Desta forma, se
livrar do alert () totalmente. Mais informações sobre este método podem ser
encontrados no RFC 2397

<META HTTP-EQUIV="refresh"
CONTENT="0;url=data:text/html;base64,PHNjcmlwdD5hbGVydCgndGVzdDMnKTwvc2NyaXB0Pg">

Estes (um pouco modificado por mim) e outros exemplos podem ser encontrados em
http://ha.ckers.org/xss.html, que é uma verdadeira enciclopédia do ataque XSS
sintaxe alternativo.

EXEMPLOS

Ataques de cross-site scripting podem ocorrer em qualquer lugar que os usuários

possivelmente mal-intencionados estão autorizados a publicar material regulamentada
para um site confiável para o consumo de outros usuários válidos.
O exemplo mais comum pode ser encontrado em sites de fóruns que fornecem
funcionalidade list-style de discussão baseado na web.

Exemplo 1 ~
O seguinte segmento de código JSP lê uma identificação do funcionário, eid, a
partir de uma solicitação HTTP a exibe para o usuário.

<% String eid = request.getParameter("eid"); %>

...
Employee ID: <%= eid %>

O código neste exemplo funciona corretamente se o eid contém texto alfanumérico

único padrão. Se o eid tem um valor que inclui meta-caracteres ou código-fonte, o
código será executado pelo navegador da web, uma vez que exibe a resposta HTTP.
Inicialmente, isso pode não parecer muito de uma vulnerabilidade. Afinal, por que
alguém iria entrar um URL que faz com que o código malicioso seja executado no seu
próprio computador? O perigo real é que um atacante irá criar a URL malicioso,
então use e-mail ou truques de engenharia social para atrair as vítimas a visitar
um link para o URL. Quando as vítimas clicarem no link, elas involuntariamente
refletirão o conteúdo malicioso através da aplicação web vulnerável de volta para
seus próprios computadores. Este mecanismo de exploração de aplicações web
vulneráveis é conhecida como XSS refletido.

Exemplo 2 ~
O seguinte segmento de código JSP consulta um banco de dados para um empregado com
um determinado ID e imprime o nome do funcionário correspondente.

<%...
Statement stmt = conn.createStatement();
ResultSet rs = stmt.executeQuery("select * from emp where id="+eid);
if (rs != null) {
rs.next();
String name = rs.getString("name");
%>

Employee Name: <%= name %>

Como no exemplo 1, as funções deste código corretamente quando os valores de nome

são bem-comportado, mas ele não faz nada para evitar exploits se eles não são. Mais
uma vez, este código pode parecer menos perigoso, porque o valor do nome é lido a
partir de um banco de dados, cujo conteúdo é, aparentemente, gerenciado pelo
aplicativo. No entanto, se o valor do nome se origina a partir de dados fornecidos
pelo usuário, então o banco de dados pode ser um canal para conteúdo malicioso. Sem
validação de entrada apropriada em todos os dados armazenados no banco de dados, um
atacante pode executar comandos maliciosos no navegador do usuário. Este tipo de
exploração, conhecido como XSS armazenados, é particularmente insidiosa porque a
dissimulação causada pelo armazenamento de dados torna-se mais difícil a
identificação da ameaça e aumenta a possibilidade de que o ataque vai afectar
vários usuários. XSS tem o seu início nesta forma com sites que ofereciam um "livro
de visitas" para os visitantes. Atacantes incluiria JavaScript em suas entradas no
livro de visitas, e todos os visitantes posteriores à página guestbook iria
executar o código malicioso.

Como os exemplos mostram, vulnerabilidades XSS são causadas por um código que
inclui dados em unvalidated uma resposta HTTP. Existem três vectores, através da
qual um ataque XSS podem atingir uma vítima:

* Como no Exemplo 1, os dados são lidos diretamente do pedido HTTP e refletida de

volta na resposta HTTP. Exploits XSS refletidos ocorrem quando um atacante faz com
que um usuário forneça conteúdo perigoso para uma aplicação web vulnerável, que é
refletida de volta para o usuário e executado pelo navegador da web. O mecanismo
mais comum para entrega de conteúdo malicioso é incluí-lo como um parâmetro em uma
URL que é postado publicamente ou e-mail diretamente às vítimas. URLs construído
desta forma constituem o núcleo de muitos esquemas de phishing, em que um atacante
convence as vítimas a visitar uma URL que se refere a um site vulnerável. Depois
que o site reflete o conteúdo de volta do atacante para o usuário, o conteúdo é
executado e passa a transferir informações pessoais, tais como cookies que podem
incluir informações de sessão, da máquina do usuário para o atacante ou realizar
outras atividades nefastas.
* Como no Exemplo 2, o aplicativo armazena dados perigosas em um banco de dados ou
outro armazenamento de dados confiável. Os dados perigoso é posteriormente lidos de
volta para o aplicativo e incluídos no conteúdo dinâmico. Exploits XSS Stored
ocorrem quando um atacante injeta conteúdo perigoso em um armazenamento de dados
que depois são lidos e incluídos no conteúdo dinâmico. Do ponto de vista de um
atacante, o lugar ideal para injetar conteúdo malicioso está em uma área que é
exibida para tanto muitos usuários ou usuários particularmente interessantes.
Usuários interessantes normalmente têm privilégios elevados na aplicação ou
interagir com dados sensíveis que é valioso para o atacante. Se um desses usuários
executa conteúdo malicioso, o atacante pode ser capaz de executar operações
privilegiadas em nome do usuário ou o acesso a dados sigilosos pertencentes ao
usuário.
* Uma fonte de fora do aplicativo armazena dados perigosas em um banco de dados ou
outro armazenamento de dados, e os dados perigoso posteriormente é lido de volta
para o aplicativo como dados confiáveis e incluídos no conteúdo dinâmico.