A4.1 Descrição
As vulnerabilidades Cross-site scripting (por vezes chamado de XSS)
ocorrem quando um invasor usa uma aplicação web para enviar código
malicioso, geralmente na forma de um script, para um outro usuário
final. Estas vulnerabilidades estão muito difundidas e ocorrem sempre
que uma aplicação web utiliza a entrada do usuário na saída que
aplicação gera sem validá-la.
Um invasor pode usar o cross site scriting para enviar scripts
malicioso para um usuário inocente. O navegador web do usuário final
não tem como saber se aquele script deve ser ou não confiável e
executará o script. Devido ao navegador supor que o script vem de uma
fonte confiavel, o script malicioso pode ter acesso a qualquer cookie,
tokens de sessão ou outra informação sensível retida em seu navegador
web e usada naquele site. Estes scripts podem até mesmo rescrever o
conteúdo da página HTML.
Ataques XSS podem geralmente ser classificados em duas categorias:
armazenamento e reflexão. Ataques de armazenamento são aqueles onde o
código injetado fica permanentemente armazenado nos servidores alvo,
como em um banco de dados, em mensagem de fórum, log de visitantes,
campos de comentário, etc. A vítima então recupera o script malicioso
do servidor quando requisita a informação armazenada. Ataques de
reflexão são aqueles onde o código injetado é refletido pelo servidor
web, por meio de uma mensagem de erro, resultado de procura ou
qualquer outra resposta que inclua alguma ou toda entrada enviada para
o servidor como parte da requisição. Ataques de reflexão são enviados
para as vítimas através de outra rota, com por meio de mensagem de
correio eletrônico ou algum outro servidor web. Quando um usuário é
ludibriado a clicar em um link malicioso ou submeter um formulário
especialmente manipulado, o código injetado viaja para o servidor web
vulnerável, que reflete o ataque de volta para o usuário do navegador.
O navegador então executa o código pois ele vem de um servidor
confiável.
A consequência de um ataque de XSS é a mesma não importando se é de
armazenamento ou de reflexão. A diferença está em como a carga chega
no servidor. Não se engane ao pensar que um site de leitura apenas ou
um site "brochureware" não é vulnerável a sérios ataques XSS de
reflexão. XSS pode causar uma variedade de problemas para o usuário
final com uma extensão de severidades desde de aborrecimento até o
comprometimento completo da conta. A maioria dos ataques severos de
XSS envolve a exposição do cookie de seção do usuário, permitindo ao
invasor sequestrar a sessão do usuário e se apoderar da conta. Outros
ataques danosos incluem a exposição de arquivos do usuário, um invasor
modificar um press release ou uma notícia que pode afetar as ações de
uma companhia ou diminuir a confiança do consumidor. Uma
vulnerabilidade de XSS em site farmacêutico pode permitir ao invasor
modificar a informação de dosagem resultando em uma overdose.
Os invasores frequentemente usam uma variedade de métodos para
codificar a parte maliciosa de uma tag, como usar Unicode, com isso, a
requisição é menos suspeita ao olhar do usuário. Existem centenas de
variantes para estes ataques, incluindo versões que não requisitam
qualquer símbolo "<" e ">". Por esta razão, tentativas para filtrar
estes scripts normalmente não são bem sucedidas. Ao invés disso, nós
recomendamos validar a entrada contra uma rigorosa identificação
positiva do que é esperado. Ataques XSS normalmente vem em forma de
javascript. Contudo, qualquer conteúdo ativo embutido é uma fonte
potencial de perigo, incluindo: ActiveX (OLE), VBscript, Shockwave,
Flash e outros.
Os problemas com XSS também podem estar presentes em servidores web
básicos bem como servidores de aplicação. A maioria dos servidores web
e de aplicação gera páginas web simples para mostar em caso de vários
erros, como a 404 'página não encontrada' ou a 500 'erro interno no
servidor'. Se estas páginas refletirem de volta qualquer informação
das requisições dos usuários, como a URL que eles tentaram acessar,
eles podem ser vulneráveis as ataques XSS de reflexão.
A probabilidade que um site contenha um vulnerabilidade XSS é
extremamente alta. Existem uma grande variedade de caminhos para
ludibriar a aplicação web enviando scripts maliciosos. Ao
desenvolvedores que tentam filtrar as partes maliciosas destas
requisições muito provavelmente não se aperceberam de possíveis
ataques e codificações. Achar estas falhas não é uma grande
dificuldade para os invasores, tudo que eles precisam é um navegador e
algum tempo. Existem numerosas ferramentas gratuitas disponíveis que
ajudam hacker a encontrar estas vulnerabilidades bem como
cuidadosamente manipular e injetar ataques XSS no site alvo.
[editar]A4.2 Ambientes afetados
Todos os servidores web, servidores de aplicação e aplicações web são
sucetíveis a cross site scripting.
[editar]A4.3 Exemplos e referências
The Cross Site Scripting FAQ: http://www.cgisecurity.com/articles/xss-faq.shtml
CERT Advisory on Malicious HTML Tags: http://www.cert.org/advisories/CA-2000-02.html
CERT "Understanding Malicious Content Mitigation"
http://www.cert.org/tech_tips/malicious_code_mitigation.html
Cross-Site Scripting Security Exposure Executive Summary:
http://www.microsoft.com/technet/treeview/default.asp?url=/technet/se...
Understanding the cause and effect of CSS Vulnerabilities:
http://www.technicalinfo.net/papers/CSS.html
Guia OWASP de Construção de Aplicações Web Seguras, capítulo 8:
Validação de Dados http://www.owasp.org/documentation/guide.html
Como construir um sistema de validação de requisições HTTP (Validação
J2EE com o Stinger) http://www.owasp.org/columns/jeffwilliams/jeffwilliams2
Have Your Cake and Eat it Too (Validação para .NET)
http://www.owasp.org/columns/jpoteet/jpoteet2
[editar]A4.4 Como determinar se você está vulnerável
Vulnerabilidades de XSS pode ser difíceis para identificar e remover
de uma aplicação web. A melhor maneira de encontrar falhas é realizar
revisões de segurança no código e procurar por todos os lugares onde a
entrada de uma requisição HTTP pode seguir possivelmente para um saída
HTML. Note que uma variedade de diferentes tags HTML podem ser usadas
para transmitir um javascript malicioso. Nessus, Nikto, e algumas
outras ferramentas disponíveis podem ajudar a varrer um website atrás
destas falhas, mas podem apenas arranhar a superfície. Se uma parte da
página web é vulnerável, existe uma grande probabilidade que existam
outros problemas similares.
[editar]A4.5 Como se proteger
A melhor maneira de proteger uma aplicação web de ataques XSS é
garantir que sua aplicação realize validação de todos os cabeçalhos,
cookies, strings de consulta, campos de formulário e campos escondidos
(i.e., todos os parametros) contra uma rigorosa especificação do que
pode ser permitido. A validação não deve tentar identificar o conteúdo
ativo e removê-lo, filtrá-lo ou higienizá-lo. Existem muitos tipos de
conteúdo ativo e muitas maneiras de codificá-los para contornar os
filtros com tal conteúdo. Nós recomendamos fortemente a política de
segurança 'positiva' que especifica que é permitido. 'Negativa' ou
política de segurança baseada em assinaturas são difíceis de manter e
possivelmente incompletas.
Codificar a saída fornecida pelo usuário pode ajudar a derrotar as
vulnerabilidades XSS previnindo scripts inseridos de serem
transmitidos para usuários em formato executável. Aplicações podem ter
ganhos significativos de proteção contra ataques baseados em
javascript pela conversão dos seguintes caracteres em todos as
entradas geradas para o código HTML apropriado:
De Para
< <
> >
( (
) )
# #
& &
O projeto de Filtros OWASP está produzindo componentes reutilizáveis
em várias linguagens para ajudar a prevenir muitas formas de adulterar
parametros, incluindo a injeção de ataques XSS. OWASP também tem
lançado o CodeSeeker, um firewall de nível de aplicação.
Adicionalmente, o programa de treinamento OWASP WebGoat tem lições
sobre Cross Site Scripting e codificação de dados.
Meus Bookmarks
Postagens
