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: 83.427 ]
Por: Luiz Vieira em 02/04/2009 | Blog: http://hackproofing.blogspot.com/
Encontrando vulnerabilidade XSS
Para encontrar vulnerabilidades XSS, devemos iniciar procurando em blogs, fóruns, caixas de texto para mensagens, comentários, busca etc. Há muitas possibilidades onde podemos encontrar esse tipo de campo, no qual podemos entrar com dados.
Podemos utilizar o Google para facilitar nossa busca. Por exemplo, se digitarmos no campo de busca do Google a linha inurl:"search.php?q=", teremos como retorno um número imenso de resultados encontrados, para encontrarmos alguns alvos para o ataque.
Se você é um desenvolvedor web, pode pensar o seguinte:
"Bem, meu site não armazena nenhuma informação importante (se esse é o caso), entretanto ele usa aplicações web, por que me preocuparia com ataques?"
Há uma razão simples para isso: há um meio muito fácil de encontrar e escolher um site, e "script kiddies" frequentemente usam esse método para descobrir aplicações web vulneráveis que possam ser exploradas. A razão pela qual eles procuram aplicações web é porque são extremamente fáceis de explorar e quando as pessoas não prestam atenção à vulnerabilidades como o XSS, elas ficam abertas aos ataques destes script kiddies.
Esses garotos usam uma ferramenta que usamos cotidianamente, e essa ferramenta é o Google. Alguns de nós já ouvimos falar de "Google Hacking", entretanto, nem todos sabem o quão fácil é encontrar sites vulneráveis utilizando o Google.
Se eu fosse um script kiddie, a primeira coisa que gostaria de fazer é encontrar algum código vulnerável à um ataque XSS e é claro, explorá-lo.
Após uma pequena busca no Google, fui capaz de descobrir que o Invision Power Board 1.3.1 Final é vulnerável à XSS, e é importante saber, se já não sabe disso, que o IPB é um programa de fórum web muito popular. Também consegui encontrar uma prova do Bugtraq Exploit:
O exploit simplesmente redireciona a vítima para um outro site. Entretanto, se alguém alterar esse exploit (o que não necessita de muita habilidade), ele poderia facilmente ser utilizado para roubar cookies.
Agora é momento em que procuraremos quantos alvos podemos encontrar na internet.
Simplesmente digitando "Powered By Invision Power Boards 1.3.1" no Google, encontramos vários sites. Este é o principal método utilizado por script kiddies para encontrar aplicações web vulneráveis, portanto, tome cuidado se seu website puder ser facilmente encontrado e atacado.
Podemos utilizar o Google para facilitar nossa busca. Por exemplo, se digitarmos no campo de busca do Google a linha inurl:"search.php?q=", teremos como retorno um número imenso de resultados encontrados, para encontrarmos alguns alvos para o ataque.
Se você é um desenvolvedor web, pode pensar o seguinte:
"Bem, meu site não armazena nenhuma informação importante (se esse é o caso), entretanto ele usa aplicações web, por que me preocuparia com ataques?"
Há uma razão simples para isso: há um meio muito fácil de encontrar e escolher um site, e "script kiddies" frequentemente usam esse método para descobrir aplicações web vulneráveis que possam ser exploradas. A razão pela qual eles procuram aplicações web é porque são extremamente fáceis de explorar e quando as pessoas não prestam atenção à vulnerabilidades como o XSS, elas ficam abertas aos ataques destes script kiddies.
Esses garotos usam uma ferramenta que usamos cotidianamente, e essa ferramenta é o Google. Alguns de nós já ouvimos falar de "Google Hacking", entretanto, nem todos sabem o quão fácil é encontrar sites vulneráveis utilizando o Google.
Se eu fosse um script kiddie, a primeira coisa que gostaria de fazer é encontrar algum código vulnerável à um ataque XSS e é claro, explorá-lo.
Após uma pequena busca no Google, fui capaz de descobrir que o Invision Power Board 1.3.1 Final é vulnerável à XSS, e é importante saber, se já não sabe disso, que o IPB é um programa de fórum web muito popular. Também consegui encontrar uma prova do Bugtraq Exploit:
[COLOR=[IMG]http://aaa.aa/=`aaa.jpg[/IMG]]`style=background:url("javascript:document.location.replace('http://hackerlounge.com');") [/color]
O exploit simplesmente redireciona a vítima para um outro site. Entretanto, se alguém alterar esse exploit (o que não necessita de muita habilidade), ele poderia facilmente ser utilizado para roubar cookies.
Agora é momento em que procuraremos quantos alvos podemos encontrar na internet.
Simplesmente digitando "Powered By Invision Power Boards 1.3.1" no Google, encontramos vários sites. Este é o principal método utilizado por script kiddies para encontrar aplicações web vulneráveis, portanto, tome cuidado se seu website puder ser facilmente encontrado e atacado.
Páginas do artigo
1. Introdução2. 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 no Brasil, qual é nossa realidade?
ARP Poisoning: compreenda os princípios e defenda-se
Virtualização: VMware ou VirtualBox no Ubuntu 9.04 com kernel 2.6.29-11?
Certificações em Segurança: para qual estudar?
Leitura recomendada
Como minimizar CSS e Javascript via linha de comando
jQuery - Criando um simples jogo da velha
Por que o Javascript é ruim em matemática?
ExtJS: Um excelente framework de JavaScript
Diferenças de sites Web Standards
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
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
[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
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
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.
Parabéns !!!
Artigo muito bem explicado, show de bola !!!
Um abraço.
[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
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.
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
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.
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
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
Patrocínio
Site hospedado pelo provedor RedeHost.
Destaques
Artigos
tux-gpt - Assistente de IA para o Terminal
Instalação e configuração do Chrony
Programa IRPF - Guia de Instalação e Resolução de alguns Problemas
Dicas
O Que Fazer Após Instalar Ubuntu 25.04
O Que Fazer Após Instalar Fedora 42
Debian 12 -- Errata - Correções de segurança
Instalando o Pi-Hole versão v5.18.4 depois do lançamento da versão v6.0
Tópicos
Alguém poderia me ajudar a escolher peças pra montar um desktop? (22)
Pra quem contribui com artigos e dicas (2)
Copiar Layout do Teclado para aplicar em outra Distribuição (2)
Top 10 do mês
Scripts
A maior comunidade GNU/Linux da América Latina! Artigos, dicas, tutoriais, fórum, scripts e muito mais. Ideal para quem busca auto-ajuda.
Site hospedado por:
