A4 Vulnerabilidades de Cross-Site Scripting (XSS)
Origem: OWASP Chapter Brasil, a enciclopédia livre.
Conteúdo |
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.
A4.2 Ambientes afetados
Todos os servidores web, servidores de aplicação e aplicações web são sucetíveis a cross site scripting.
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/security/topics/ExSumCS.asp
- 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
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.
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.