Boas.
Vamos ver, rapidamente, como é possível burlar captchas.
Vale lembrar que não vai funcionar com qualquer website. Porém, a maioria.
Ocorre que há dois principais meios de guardar informações sobre um determinado usuário. São elas: "cookies" e "sessions". A principal diferença entre os dois é apenas o local onde são armazenados: cookies são guardados no computador do usuário. Sessions são guardadas no servidor.
Você pode já saber que, ao efetuar login em algum website, por exemplo, para que o login permaneça até que você saia, tornando possível navegar por entre as páǵinas da área protegida sem que se faça necessário um login por request, é bem provável que haja cookies ou sessions trabalhando.
Sessions são, na teoria, mais seguras, e, na prática, mais fáceis de usar e confiar. Por isso, são mais utilizadas que cookies.
Geralmente, para se prevenir ataques à força-bruta, registra-se a quantidade de login em um desses meios temporários de gravação (vamos chamá-los de "resources", "recursos"). A cada tentativa, essa variável é incrementada, até que, ao se atingir o limite de tentativas, o sistema vai exibir o captcha.
Ah, acho que já entendi. Mas precisamos dar a sorte de estarmos atacando um website que utilize cookies ao invés de sessions, né?
Não. Está certo que sessões ficam no servidor, e não podemos alterá-las livremente, mas... como o servidor faz para diferenciar de qual usuário é tal session?
IP.
Não, ou quando você estivesse em uma rede com proxy, os logins seriam "compartilhados", já que o IP de todos os computadores ligados ao proxy é o mesmo.
Então, o quê?
O interpretador da linguagem server-side do servidor (como por exemplo, o PHP) precisa guardar alguma coisa no computador do usuário para diferenciá-lo. No caso do PHP, ele utiliza uma variável chamada PHPSESSID. Ela pode ser um cookie ou, caso haja uma configuração no php.ini, uma variável GET/Query String na URL (?PHPSESSID= na URL). Vale ressaltar que também é possível mudar o nome dessa variável. Logo, utilize sua capacidade de estipular que todo hacker tem (ou deveria ter).
Chega de (tanta) enrolação, e vamos ver um exemplo na prática.
Veja que, após uma tentativa frustrada de login, é pedido um captcha. Não seria problema... caso o script que gerasse o captcha estivesse com problemas.
Estou utilizando o Google Chrome. Pressione Ctrl + Shift + J, clique na guia Resources, e, em seguida, clique em Cookies. Veja que encontramos o nosso PHPSESSID. Vamos excluí-lo...
Não atualize a página, ou a tentativa frustrada de login será refeita. Volte para a página de login (neste caso, só precisei clicar na barra de endereços e pressionar Enter) e veja que o captcha sumiu.
Até a próxima!
Dicas (ataque):
Dicas (defesa):
Vamos ver, rapidamente, como é possível burlar captchas.
Vale lembrar que não vai funcionar com qualquer website. Porém, a maioria.
Ocorre que há dois principais meios de guardar informações sobre um determinado usuário. São elas: "cookies" e "sessions". A principal diferença entre os dois é apenas o local onde são armazenados: cookies são guardados no computador do usuário. Sessions são guardadas no servidor.
Você pode já saber que, ao efetuar login em algum website, por exemplo, para que o login permaneça até que você saia, tornando possível navegar por entre as páǵinas da área protegida sem que se faça necessário um login por request, é bem provável que haja cookies ou sessions trabalhando.
Sessions são, na teoria, mais seguras, e, na prática, mais fáceis de usar e confiar. Por isso, são mais utilizadas que cookies.
Geralmente, para se prevenir ataques à força-bruta, registra-se a quantidade de login em um desses meios temporários de gravação (vamos chamá-los de "resources", "recursos"). A cada tentativa, essa variável é incrementada, até que, ao se atingir o limite de tentativas, o sistema vai exibir o captcha.
Ah, acho que já entendi. Mas precisamos dar a sorte de estarmos atacando um website que utilize cookies ao invés de sessions, né?
Não. Está certo que sessões ficam no servidor, e não podemos alterá-las livremente, mas... como o servidor faz para diferenciar de qual usuário é tal session?
IP.
Não, ou quando você estivesse em uma rede com proxy, os logins seriam "compartilhados", já que o IP de todos os computadores ligados ao proxy é o mesmo.
Então, o quê?
O interpretador da linguagem server-side do servidor (como por exemplo, o PHP) precisa guardar alguma coisa no computador do usuário para diferenciá-lo. No caso do PHP, ele utiliza uma variável chamada PHPSESSID. Ela pode ser um cookie ou, caso haja uma configuração no php.ini, uma variável GET/Query String na URL (?PHPSESSID= na URL). Vale ressaltar que também é possível mudar o nome dessa variável. Logo, utilize sua capacidade de estipular que todo hacker tem (ou deveria ter).
Chega de (tanta) enrolação, e vamos ver um exemplo na prática.
Veja que, após uma tentativa frustrada de login, é pedido um captcha. Não seria problema... caso o script que gerasse o captcha estivesse com problemas.
Estou utilizando o Google Chrome. Pressione Ctrl + Shift + J, clique na guia Resources, e, em seguida, clique em Cookies. Veja que encontramos o nosso PHPSESSID. Vamos excluí-lo...
Não atualize a página, ou a tentativa frustrada de login será refeita. Volte para a página de login (neste caso, só precisei clicar na barra de endereços e pressionar Enter) e veja que o captcha sumiu.
Até a próxima!
Dicas (ataque):
- Ao criar bots, recuse cookies o quanto possível.
- Pode haver proteção baseada em endereço IP. Neste caso, utilize algum dos famoso scripts que modificam seu endereço IP, ou utilize uma cadeia de proxies ao criar o bot.
Dicas (defesa):
- Para melhor se proteger, utilize todas as formas possíveis: cookie, session e IP no banco de dados. Quando for verificar se é necessário exibir o captcha, verifique se as 3 fontes dizem a mesma coisa. Caso os resultados sejam diferentes, exiba o captcha de qualquer forma.
Comment