Formas de invasão, ideias de como invadir um site

Invadir um site atualmente, com tantas linguagens de programação e profissionais desqualificados selecionados pelos processos seletivos, onde são bem avaliados em questão psicológica mas péssimos profissionais no quesito experiência, recebendo salários baixos, e, desmotivados, a fragilidade de qualquer site, sistema, pode ser um item aferido.

Outro item importante a ser ressaltado, é que projetos grandes, deve haver um fluxo, um controle por alguém especializado, que no mínimo já trabalhou com programação, e que sabe das táticas de invasão, algumas apresentadas aqui, gratuitamente.

Continue lendo para ter maiores detalhes destas ideias, e de como imediatamente blindar seu site contra ataques de todos os mais diversos atualmente.

1. Ataque superficial

Os ataques superficiais, ou que afetam apenas o front-end, são diversos, e, estes ataques podem aferir o comportamento da página, trazendo conteúdo de outros lugares na internet, alterando o comportamento da página atual. Isto também é conhecido como ataque de XSS, ou mais conhecido como Cross Site Scripting.

Vamos buscar no site, alguns campos de comentários, e faremos alguns comentários do tipo:

Olá pessoal, tudo bem?<script type="text/javascript">alert("Olá, seja bem vindo ao site!");</script>

Se após você comentar, você entrar no site e visualizar um pop-up "Olá, seja bem vindo ao site!", você acabou de "invadir" o site. Porém, este ataque, é apenas superficial, não atinge nenhum arquivo no servidor, nem dados, nem qualquer outro tipo de ação pode ser realizada, pois geralmente o conteúdo de campos de texto, ficam salvos em banco de dados, e só serão reproduzidos em formato HTML ao ser exibido novamente.

Acontece que se você possui um código HTML sendo interpretado, ele pode muito bem ser reescrito, e re-executado por um terceiro, sem que o proprietário do site autorize.

Isto permite injetar um script de qualquer outro lugar na internet, e ter um "controle remoto" do site atacado no momento em que desejar, trocando o comportamento, alterando a página, pois JavaScript permite realizar qualquer ação no front-end da página no cliente.

Muitos sites brasileiros, de governos, são realizados desta forma.

2. CORS, o que é isto? "Invadindo" um site com iframe.

Já pensou seu site sendo aberto por outro domínio que não é de sua propriedade e ser indexado no Google com maior relevância que seu próprio site? Como assim? Vou te explicar.

Você tem um site, XPTO.com.br (isto é um exemplo), mas alguém colocou o seu site completo, igual, em um iframe para XPTOX.com.br, porém, este domínio, não é seu, é de um terceiro.

Usando táticas de aumentar o Pagerank do site no Google (divulgando a URL falsa mais do que a original), o site terceiro começa a ter uma entrada de usuários maior que o domínio original, pois irá aparecer acima nos resultados de busca.

Agora já pensou seu site em um domínio de terceiro, o que ele pode fazer do dia para a noite? Se colocar algo difamando sua empresa? Criar um site dizendo "Você foi hackeado", qual é a imagem dos clientes para sua empresa? Boa não é, certo?

E o pior, se este site XPTOX.com.br, estiver enchendo de cliques no site usando scripts que rodam na página mãe (XPTO.com.br está dendo de um iframe), podem fazer seu servidor trabalhar muito mais do que o normal.

Para isto existe o CORS, que é uma tática para impedir que qualquer outro site coloque seu site como um iframe, então, seu site rodará apenas no seu domínio de raiz.

Basta colocar o cabeçalho HTTP:

Access-Control-Allow-Origin: http://xpto.com.br, http://www.xpto.com.br

E pronto, ninguém mais poderá colocar seu site como iframe, em nenhum lugar mais, pelo menos não em navegadores novos, pois os mesmos rejeitarão qualquer iframe que tenha esta configuração habilitada, e o domínio de origem, não estiver especificado neste cabeçalho.

3. Ataque de negação de serviço sobre query SQL

Vamos procurar no site, algo que leve alguns segundos para ser processado, como por exemplo, na área de notícias, se há alguns filtros para o usuário selecionar, ou no catálogo de produtos da loja virtual.

O ideal é procurar um filtro que faça o site demorar para responder, pelo menos, mais que 2 segundos pensando sem ainda começar a trazer dados.

Isto significa, que o site leva consideravelmente um tempo razoável para trazer informações do banco de dados.

Mas agora, vamos supor a seguinte equação:

Se apenas 1 acesso leva 2 segundos, então 10 acessos, levaria 20 segundos de processamento. Não exatamente. Bancos de dados geralmente trabalham com cache nas últimas consultas, mas, ainda assim, levará pelo menos algum tempo, vamos supor que mesmo com cache, 10 acessos leve 10 segundos, ou seja, 1 segundo de processamento por acesso.

Se esta mesma pessoa fizer um software simples, que pulse de 1 em 1 segundo a URL com filtros, alterando alguns parâmetros por consulta, para evitar o cache, poderemos ter uma boa indisponibilidade do site no processamento das consultas reais.

Há também, algo que pode acontecer (e muito), e que pode deixar instável qualquer aplicação, é quando há uma query sendo executada, e na programação do site, há alguma sub-query sendo executada dentro da query principal, onde o programador não otimizou a query principal para obter resultados da sub-query dentro da própria query.

Nestes casos, paginação de catálogos, onde trazem vários produtos, e preços, detalhes, geralmente estão em outra tabela, ou imagens, principalmente se há várias imagens (relação 1 para N), então não há outra forma senão realizar esta sub-query.

Se conseguir encontrar um filtro que ao invés de trazer 10 produtos por página, consiga trazer 1000 produtos ou 10.000 produtos, isto também poderá derrubar o site, principalmente, se a subquery estiver sendo produzida somente pelo server-side (html vem pronto no view-source), ao invés de jquery, que pode ter lazy load e carregar só o que está na viewport (mas, geralmente ninguém faz isto, pois é muito mais trabalhoso).

Esta URL que pede os 10.000 produtos, pode levar 1 a 2 minutos para ser processada dependendo do servidor, e, quanto mais tempo levar, mais fácil será derrubar o servidor (através do banco de dados).

Se cada acesso levar 1 minuto, e se fizer pulsar de 1 em 1 segundo, o servidor irá começar a operar cada vez mais lento, pois não terá habilidade suficiente para conseguir atender a demanda da fila em execução, e o IIS ou Apache, pode chegar a esgotar a fila de processamento de pedidos (queue) no pool do processo, até que o mesmo seja encerrado por falhas, e o site de fato seja derrubado.

Se não há nenhum log habilitado, ou monitoria neste servidor, rotinas de monitoria nos processos, o site pode levar horas para ser restabelecido, por mais que a ação de retomar seja apenas realizar um simples restart no processo, porém, a causa principal, foi uma elaboração errada de uma query.

4. SQL Injection

Tente utilizar em campos de formulário os códigos:

' or 1=1 or 1 = '
' or 1=1--
' or 65445=65445 or 'a' = '
' or true --

Se o site se comportar de forma estranha, ele pode estar vulnerável a ataques de SQL Injection, e todo o seu banco de dados pode estar comprometido.

Lembre-se, o dígito "--" sempre é, quase sempre, esquecido pelos programadores, pois geralmente desconhecem de sua existência, mas isto significa que é comentário tudo que houver depois, igual ao "//" no JavaScript.

Isto porque no SQL Server, a forma de comentar é por padrão, deste modo:

/* comentário */

Mas ninguém imagina que exista também o comentário para apenas uma linha:

SELECT * FROM PRODUTOS WHERE NOME LIKE '%Amora%'  -- PRODUTO

E isto é válido para ser executado, como se fosse "//" no PHP ou JavaScript.

5. Injeção de Server Side

A ação aqui é tentar enviar um arquivo por meio de upload, seja em comentários, ou em qualquer lugar que seja, e fazer o script ser executado no servidor.

Este script, pode ser em ASP ou PHP, e basta não haver nenhuma proteção para upload para arquivos com extensões deste tipo.

Geralmente, arquivos de upload em "Trabalhe Conosco", ou em outras áreas do site, tem o nome do arquivo renomeado para outro nome, para evitar duplicatas, e, também, quem fez o upload, não sabe qual a URL chamar o arquivo.

Por isto, dentro deste arquivo, deve conter um código de programação para disparar e-mail assim que for executado, entregando qual a URL onde está sendo executado. Sendo assim, é possível até mesmo gerar um currículo falso ao usuário deste sistema, que ao tentar "ler o currículo", na realidade passará a executar o script PHP, e então, o mesmo passará ao atacante as informações por e-mail, e, emitirá um currículo falso.

Com o script rodando, e funcional, e a URL conhecida, pode ser feito muitas outras coisas. Se o arquivo injetado for um tipo "gerenciador web de arquivos", passará a ter acesso a todos os arquivos, gravação, leitura de todos os dados, senhas, etc.

Por isto é importante que o site evite ao máximo o upload de arquivos, e, se for fazer, não salvar no mesmo servidor de Web, mas salvar em um servidor separado, como um S3 da Amazon, onde nenhum código é executado, somente é servido arquivos estáticos.

Se precisa salvar estes arquivos no servidor, ao menos, garanta que a pasta tenha suas permissões devidamente configuradas para não permitir a execução de arquivos, e somente trabalhar com arquivos estáticos.

Finalização

Estas foram algumas ideias baseadas em alguns tipos de ataques que podem acontecer e que são, em suma, fáceis de serem evitados, mas, que nem sempre os programadores levam em consideração ao realizar ajustes ou desenvolver sistemas.