XSS - Cross Site Scripting

Ataques XSS estão se tornando um grande problema e piorarão ainda mais se as pessoas não tomarem conhecimento desse tipo de ataque e suas vulnerabilidades.

[ Hits: 82.948 ]

Por: Luiz Vieira em 02/04/2009 | Blog: http://hackproofing.blogspot.com/


Introdução



Ataques XSS estão se tornando um grande problema e piorarão ainda mais se as pessoas não tomarem conhecimento desse tipo de ataque e suas vulnerabilidades.

Vulnerabilidades XSS tem sido encontradas em todos os tipos de site, até mesmo no fbi.gov, Yahoo.com, ebay.com e muitos outros sites populares e importantes.

Muitos administradores de sites falham em não atentar-se para ataques XSS porque, ou eles não sabem muita coisa sobre esse tipo de ataque, ou não os vêem como um problema.

Uma vulnerabilidade XSS quando explorada por um atacante hábil, ou mesmo um iniciante, pode ser um ataque poderoso.

Este texto, procura detalhar um ataque XSS e conscientizá-lo sobre o que esses ataques são, como os atacantes usam-nos e como pode prevenir-se deles.

O que é XSS

XSS, também conhecido como CSS (Cross Site Scripting, facilmente confundido com Cascading Style Sheets), é uma vulnerabilidade muito comum encontrada em aplicativos web. XSS permite ao atacante inserir códigos maliciosos nessas páginas para que sejam executados no momento em que tais páginas forem acessadas.

O ataque permite que conteúdos (scripts) em uma zona sem privilégio seja executado com permissão de uma zona privilegiada - i.e. escalação de privilégios no cliente (web browser) executando o script.

A vulnerabilidade poderia ser:
  • Um bug do browser que sob determinadas condições permite conteúdos (scripts) de determinado nível ser executado com permissões de níveis mais altos;
  • Um erro na configuração do browser, sites não-seguros listados em zonas privilegiadas;
  • Vulnerabilidade de cross-site scripting em uma zona privilegiada.

Um cenário comum de ataque envolve dois passos:

O primeiro passo é utilizar uma vulnerabilidade Cross Site Scripting para executar scripts em zonas privilegiadas. Para completar o ataque, realizar ações maliciosas no computador utilizando controles ActiveX não-seguros.

Esse tipo de vulnerabilidade tem sido explorada para instalar silenciosamente vários malware (tais como spyware, softwares de controle remoto, worms e coisas semelhantes) em computadores enquanto navegam em páginas web maliciosas.

Há muitos tipos de ataques XSS, mencionaremos 3 dos mais utilizados.

O primeiro tipo de ataque é de "XSS URL", que significa que o XSS não está na página, e apenas será executado se colocar o código malicioso na URL e enviar a URL. Falaremos mais sobre esse tipo mais à frente e sobre como usá-lo para nossa vantagem.

O segundo tipo é em campos de texto (ou senhas), onde podemos entrar com dados, que muito comumente são vulneráveis a XSS. Por exemplo, digamos que encontramos um site com opção de busca. Agora entramos com a palavra "hacker" na caixa de busca e pressionamos enter. Quando a página carrega, se retorna alguma informação dizendo "Found 100 Results For hacker", você poderá ver que serão exibidos dados na página. Mas o que aconteceria se você pudesse executar um código? Não é possível executar código PHP nesse tipo de ataque, mas certamente é possível códigos HTML, javascript.

No terceiro tipo, é possível inserir dados (códigos) e eles serão armazenados no site.

Que tipo de danos isso pode causar?

Bem, se um atacante cria um link manipulado e envia-o a uma vítima e essa vítima clica em tal link, um código javascript pode ser executado para enviar os cookies da vítima para um script CGI. Obviamente que um ataque desse tipo poderia causar um dano maior. Quando um atacante cria um link malicioso, ele normalmente codifica o código javascript em HEX ou algum tipo de codificação para ocultar o código malicioso.

Sites que são vulneráveis à ataques XSS rodam algum tipo de conteúdo dinâmico, que é o tipo de conteúdo que altera-se com a interação do usuário ou informação armazenada no banco de dados, tais como fóruns, email on-line e locais onde informações são enviadas.

Você pode perguntar por que um ataque XSS não pode ocorrer enquanto o usuário não está acessando determinado domínio. Isso ocorre porque quando a vítima está em um determinado site, o código malicioso é executado sob a mesma permissão de aplicações web de domínio ou endereço IP.

    Próxima página

Páginas do artigo
   1. Introdução
   2. Encontrando vulnerabilidade XSS
   3. Básico do XSS
   4. Exemplos de exploits e vulnerabilidades XSS
   5. Como posso proteger-me contra ataques XSS
Outros artigos deste autor

Segurança da Informação: Necessidades e mudanças de paradigma com o avanço da civilização

Linux no Pendrive

Boot Linux - o que acontece quando ligamos o computador

Virtualização: VMware ou VirtualBox no Ubuntu 9.04 com kernel 2.6.29-11?

ARP Poisoning: compreenda os princípios e defenda-se

Leitura recomendada

Web sites dinâmicos com Ajax + JSP + MySQL

MathML - Mathematical Markup Language

jQuery - Criando um simples jogo da velha

Jakarta JMeter - Testando o desempenho de seus sites

Novo tipo de vírus pode afetar tanto Windows quanto Linux

  
Comentários
[1] Comentário enviado por demoncyber em 02/04/2009 - 11:26h

Excelente artigo!

Muito interessante a abordagem aprofundada do assunto não aquilo que habitualmente se encontra na net de um a três paragrafos falando o que é e nem explicando como funcinoa..

Parabéns


[2] Comentário enviado por M.Bittencourt em 02/04/2009 - 11:46h

Parabéns pelo artigo.

[3] Comentário enviado por dastyler em 02/04/2009 - 14:30h

artigo muito bom.
A ultima vez que li a respeito de documentação sobre XSS foi um artigo na Linux Magazine.
Parabens!

[]´s

[4] Comentário enviado por Douglas_Martins em 02/04/2009 - 17:56h

Muito bom mesmo.

Parabéns pelo artigo. Muito bem explicado e de forma direta no assunto.

[]'s

[5] Comentário enviado por gersonraymond em 03/04/2009 - 07:15h

Parabéns !!!

Artigo muito bem explicado, show de bola !!!

Um abraço.

[6] Comentário enviado por cassimirinho em 04/04/2009 - 13:24h

Bom, muito bom.

[7] Comentário enviado por psychokill3r em 06/04/2009 - 23:52h

concordo que é muito bom esse artigo ,até o coloquei nos favoritos (me deve 100 pontos) to brincando.

mais não vi soluções para administradores de sites , ou seja não usar php nuke ou Invision Power Board esta fora de questão.

se alguem quiser brincar um pouco com xss baixe a extensão para firefox "xss me" que faz vários testes no site q você quiser .

e para não se dar mal em algum site que já foi injetado códigos você deve ter a extensão "script block".
mandar o firefox limpar cokkies e histórico ao sair sem perguntar também é uma boa ideia.

valeuw
obrigado ao autor e espero mais artigos do tipo.

xss-me
sql inject-me
access-me

exemplo de ataque dessa vez ao twitter
http://pcmag.uol.com.br/conteudo.php?id=1355

[8] Comentário enviado por wagner.elias em 22/04/2009 - 11:53h

Parabéns por compartilhar conteúdo, mas permita-me esclarecer alguns pontos onde você se equivocou.

1 - No início você trata XSS (Cross Site Scripting) como CSRF (Cross Site Request Forgery). Uma coisa é um XSS que irá executar código javascript no cliente (XSS é um ataque client-side), outra coisa é o CSRF que tem o XSS como vetor e consiste em executar ações baseado nas credenciais do usuário que está sendo explorado;

2 - Outro equívoco grande foi referente aos tipos de XSS, existem 3 tipos de XSS:

a) Refletido - Quando o XSS é executado, explorado quando o usuário abre uma URL, página que contém um script injetado;
b) Armazenado - Quando o atacante consegue inserir um XSS na aplicação e ele irá ser armazenado na base dados, quando o usuário chamar a página;
c) DOM Based - É o XSS que explora objetos DOM (Document Object Model).

Quanto o tratamento, basicamente o XSS explora inputs que não são adequadamente validados, portanto para mitigar é necessário tratar os dados que você recebe em cada input. Mais detalhes podem ser vistos aqui: http://www.owasp.org/index.php/Cross_site_scripting

Quem quiser trocar informação sobre o tema segurança em aplicações web, estou a disposição. Uma excelente fonte de informação é o site da OWASP (Open Web Application Security Project - http://www.owasp.org), quem quiser conhecer o capítulo brasileiro, só entrar em contato e/ou assinar a lista de discussão: http://www.owasp.org/index.php/Brazilian

Abs.

[9] Comentário enviado por luizvieira em 22/04/2009 - 12:44h

Olá Wagner, preferi não abordar o CSRF, apenas coloquei algumas funcionalidades que o XSS possui semelhantes ao CSRF (apesar do CSRF ser mais amplo e permitir uma gama maior de execuções maliciosas além de outras possibilidades ).

Quanto as classificações, realmente equivoquei-me ao explicá-las. Expliquei o primeiro tipo, "refletido", porém sem utilizar a terminologia que vc utiliza, assim como o segundo tipo. Quanto ao terceiro tipo, é justo aí que o equívoco encontra-se, obrigado por esclarecer esse aspecto :-)

Utilizo a metodologia OWASP quando faço análise de vulnrabildiades em aplicações WEB, pois considero-a de todas as metodologias, a mais eficiente e bem organizada. Para um pen testing, na parte WEB é justamente essa que utilizo. Obrigado pelo convite à todos, para participar da lista de discussão!

[ ]'s

[10] Comentário enviado por fabio1049 em 17/06/2009 - 15:39h

Muito bom artigo, parabéns.
Eu ainda fiquei na dúvida sobre procedimentos para evitar o ataque no servidor remoto. Sou administrador de um site que vem sofrendo esse tipo de ataque. De uma hora para outra o arquivo index é alterado, é colocado um javascript malicioso ou um iframe com um link desconhecido. Eu não consigo identificar onde está a vulnerabilidade, já que essa pagina é um html com apenas um swf no conteúdo.

[11] Comentário enviado por luizvieira em 22/06/2009 - 16:01h

Olá Fábio,
O ideal é levantar algumas questões acerca do site que administra e o servidor onde stá hospedado:
- O site é html puro ou baseado em alguma linguagem dinâmica? Se é a segunda opção, utiliza algum CMS? Se sim, há vulnerabilidades que ainda não corrigiu com atualizações?
- Se baseado em linguagem dinâmica e BD no servidor, há um tratamento adequado contra SQL injection? Muitas vezes javascripts maliciosos entram nos conteúdos via SQL Injection...
- Há algum script ou arquivo estranho no seu servidor ftp? Muitas vezes alguém implanta um script que dá acesso ao servidor FTP (muita gente ainda salva o arquivo com o nome de C99.algumacoisa, mas isso não é regra). Faça uma limpeza no seu FTp pra ver se tem algo estranho, que vc não tenha criado, ou simplesmente não vá mais utilizar e remova.
- Qual o nível de segurança e a preocupação com o assunto do servidor onde seu site está hospedado? Alguns não ligam muito pra isso, mas depois do ataque isso faz uma difereeeeeennnnnnça....rs.

Essas já são algumas questões que precisa responder pra diminuir os riscos de ataques. Há outras, obviamente, mas essas já são o início.
[ ]'s

[12] Comentário enviado por ricardolongatto em 10/01/2012 - 23:53h

execelente
abraço luiz


Contribuir com comentário




Patrocínio

Site hospedado pelo provedor RedeHost.
Linux banner

Destaques

Artigos

Dicas

Tópicos

Top 10 do mês

Scripts