O site da Receita Federal é vulnerável a Cross-Site Scripting. É possível redirecionar o usuário, roubar cookies e dados de autenticação, bem como forjar a sessão por meio do cookie roubado. A variável Criterio do script BUSCAR.ASP pode ser utilizada para enganar os usuários, ou seja, todos nós.
URL para disparar o evento alert:
http://www.receita.fazenda.gov.br/Aplicacoes/ATBHE/Busca/BUSCAR.ASP?error=3002&Criterio=<script>alert(document.cookie)</script>
URL usando document.write:
http://www.receita.fazenda.gov.br/Aplicacoes/ATBHE/Busca/BUSCAR.ASP?error=3002&Criterio=<script>document.write(document.cookie)</script>
URL para carregar um iframe com o site do Google (poderia ser um site com vírus!):
http://www.receita.fazenda.gov.br/Aplicacoes/ATBHE/Busca/BUSCAR.ASP?error=3002&Criterio=<iframe src=http://www.google.com.br>
O site da Secretaria do Tesouro Nacional também tem um erro que demonstra que nada foi investido no aprendizado de programação segura e ainda por cima baseiam a segurança num produto e não numa análise, já que estão usando a capacidade do ambiente .NET de conseguir identificar certas falhas. Abaixo está a imagem da tentativa de inserir um XSS um subsite do Tesouro Nacional, o problema afeta mais precisamente o SIAFI (Sistema Integrado de Administração Financeira do Governo Federal).
Na linha 67 observamos a maneira como as variáveis são (pessimamente) declaradas na aplicação escrita em .NET:
Dim uf, nivel, retorno
Mas não se sabe o que as variáveis são! Não basta se firmar em supostas qualidades do ambiente .NET, lembrem-se programadores do Governo (qualquer governo): isto não é Python!
Poderia ser uma string:
Dim uf As String
Vocês também podem declarar variáveis legais do tipo:
Dim variavel As Short
Dim variavel As Integer
Mas cuidado se a variável for realmente longa vocês terão que colocar As Long. Ainda tem a possibilidade de usar Object e uma porção de coisas legais, basta aprender a usar da maneira correta. Estudem moças e rapazes do Governo (qualquer um deles)!
Mas vocês podem ficar aí no Governo (qualquer um deles) replicando e reclamando: .NET faz as “coisas” automaticamente com as variáveis. E eu replico daqui: boas práticas de programção são o que evitam furos como os de cima. Por ali um atacante já pode ter até o local da aplicação em D:\Websites e por aí vai (cada vez pior).
Boas práticas de programação também evitam que furos de XSS aparecem em serviços realmente importantes. É o nosso dinheiro, são as nossas informações e é a nossa segurança.
Até a próxima com mais um show de falhas do Governo (qualquer um)!


Cleber
setembro 7, 2010 at 2:50 am
É lamentável que esse tipo de erro aconteça em sites do governo. Hoje achei uma falha de XSS no site do IBGE:
http://cleber.net.br/site-do-ibge-possui-falha-de-seguranca
Espero que resolvam rápido esse problema. Coloquei um link para o seu post lá no meu post.
aaaaaaaa
outubro 8, 2010 at 5:58 pm
window.location.href=”http://antoniolost.justfree.com/index.html”
Mario Gomes
dezembro 13, 2011 at 12:06 pm
Não funciono aqui no FF 8. Mas, também em uma falha de DOM-Based XSS na pagina de erro
http://www.receita.fazenda.gov.br/Aplicacoes/ATBHE/Busca/ccccccccccccccccccccccccccccccccc?%3Ch1%3Eaa#<alert('Xssed‘);
Para reproduzir use IE,Opera ou Safari. Não funciona com o Firefox por que ele codifica a automaticamente STRING e no Chrome não funciona devido ao protetor XSS.