Bloquear o acesso do usuário aos internos de um site usando HTTP_REFERER

votos
4

Eu tenho controle sobre o httpserver mas não sobre o ApplicationServer ou os aplicativos Java sentado lá, mas eu preciso bloquear o acesso direto a determinadas páginas sobre esses pedidos. Precisamente, eu não quero que os usuários automatizar o acesso a formas emissão de solicitações HTTP GET / POST directas para o servlet apropriado.

Então, eu decidi bloquear usuários com base no valor de HTTP_REFERER. Afinal, se o usuário está navegando dentro do site, ele terá uma apropriada HTTP_REFERER. Bem, isso era o que eu pensava.

Eu implementei uma regra de reescrita no arquivo .htaccess que diz:

RewriteEngine on 

# Options +FollowSymlinks
RewriteCond %{HTTP_REFERER} !^http://mywebaddress(.cl)?/.* [NC]
RewriteRule (servlet1|servlet2)/.+\?.+ - [F]

Eu esperava para proibir o acesso a usuários que não navegar no site, mas emitem solicitações GET directas para o servlet1 ou servlets servlet2 usando querystrings. Mas as minhas expectativas terminou abruptamente, porque a expressão regular (servlet1|servlet2)/.+\?.+não funcionou em tudo.

Eu fiquei muito decepcionada quando eu mudei essa expressão para (servlet1|servlet2)/.+e funcionou tão bem que meus usuários foram bloqueados não importa se eles navegado o site ou não.

Então, minha pergunta é: Como é que eu posso realizar essa coisa de não permitir que robôs com acesso direto a determinadas páginas, se eu não tenho acesso / privilégios / hora para modificar o aplicativo?

Publicado 06/08/2008 em 15:44
fonte usuário
Em outras línguas...                            


9 respostas

votos
2

Eu não tenho certeza se eu posso resolver isso de uma só vez, mas podemos ir e voltar, se necessário.

Em primeiro lugar, quero repetir o que eu acho que você está dizendo e ter certeza que eu sou claro. Você quer proibir solicitações de servlet1 e servlet2 é o pedido não tem o referer adequada e que faz ter uma seqüência de consulta? Eu não tenho certeza se entendi (servlet1 | servlet2) /.+\?.+ porque parece que você está exigindo um arquivo sob servlet1 e 2. Eu acho que talvez você está combinando PATH_INFO (antes do "?") Com um GET string de consulta (depois do "?"). Parece que a parte PATH_INFO vai funcionar, mas o teste de consulta GET não vai. Eu fiz um teste rápido no meu servidor usando script1.cgi e script2.cgi e as seguintes regras trabalhou para realizar o que você está pedindo. Eles são, obviamente editado um pouco para coincidir com o meu ambiente:

RewriteCond %{HTTP_REFERER} !^http://(www.)?example.(com|org) [NC]
RewriteCond %{QUERY_STRING} ^.+$
RewriteRule ^(script1|script2)\.cgi - [F]

O acima pego todos os pedidos errado-referer para script1.cgi e script2.cgi que tentou enviar dados usando uma string de consulta. No entanto, você também pode enviar dados usando um PATH_INFO e postando dados. Eu usei esta forma de proteger contra qualquer um dos três métodos utilizados com referer incorreta:

RewriteCond %{HTTP_REFERER} !^http://(www.)?example.(com|org) [NC]
RewriteCond %{QUERY_STRING} ^.+$ [OR]
RewriteCond %{REQUEST_METHOD} ^POST$ [OR]
RewriteCond %{PATH_INFO} ^.+$
RewriteRule ^(script1|script2)\.cgi - [F]

Com base no exemplo que você estava tentando começar a trabalhar, eu acho que isso é o que você quer:

RewriteCond %{HTTP_REFERER} !^http://mywebaddress(.cl)?/.* [NC]
RewriteCond %{QUERY_STRING} ^.+$ [OR]
RewriteCond %{REQUEST_METHOD} ^POST$ [OR]
RewriteCond %{PATH_INFO} ^.+$
RewriteRule (servlet1|servlet2)\b - [F]

Esperemos que este, pelo menos, fica mais perto de seu objetivo. Por favor, deixe-nos saber como ele funciona, eu estou interessado em seu problema.

(BTW, eu concordo que referer bloqueio é falta de segurança, mas também entendo que as soluções forças relaity imperfeitos e parciais, por vezes, o que parece que você já reconhecem.)

Respondeu 06/08/2008 em 19:41
fonte usuário

votos
1

Usando um referencial é muito confiável como método de verificação. Como outras pessoas mencionados, é facilmente falsificado. Sua melhor solução é modificar o aplicativo (se possível)

Você poderia usar um CAPTCHA, ou definir algum tipo de cookie ou cookie de sessão que controla a página que o usuário visitou pela última vez (a sessão seria mais difícil de falsificar) e manter o controle da história vista de página, e só permitir que os usuários que navegam a páginas necessário para chegar à página que você deseja bloquear.

Isto, obviamente, exige que você tenha acesso ao aplicativo em questão, no entanto, é a maneira mais infalível (não completamente, mas "suficientemente bom" na minha opinião.)

Respondeu 06/08/2008 em 16:08
fonte usuário

votos
1

Javascript é outra ferramenta útil para evitar (ou pelo menos delay) de tela raspagem. Mais ferramentas automatizadas raspagem não tem um intérprete de Javascript, para que possa fazer coisas como ajuste campos ocultos, etc.

Edit: Algo ao longo das linhas de este artigo Phil Haack .

Respondeu 06/08/2008 em 16:03
fonte usuário

votos
1

Você não pode distinguir usuários e scripts maliciosos por sua solicitação HTTP. Mas você pode analisar quais usuários estão solicitando muitas páginas em um tempo muito curto, e bloquear os seus endereços IP.

Respondeu 06/08/2008 em 16:02
fonte usuário

votos
1

Eu não tenho uma solução, mas eu estou apostando que contando com a referência nunca vai funcionar porque user-agents são livres para não enviá-lo em tudo ou falsificar-lo para algo que vai deixá-los entrar.

Respondeu 06/08/2008 em 15:49
fonte usuário

votos
0

Você pode ser capaz de usar um token anti-CSRF para conseguir o que você está depois.

Este artigo explica em mais detalhes: Pedido de Cross-Site Falsificações

Respondeu 20/08/2008 em 14:06
fonte usuário

votos
0

Para tornar as coisas um pouco mais claro:

  1. Sim, eu sei que usando HTTP_REFERER é completamente confiável e um pouco infantil, mas eu tenho certeza que as pessoas que aprenderam (de mim, talvez?) Para fazer automações com Excel VBA não vai saber como subverter o HTTP_REFERER dentro do intervalo de tempo para ter a solução final.

  2. Eu não tenho acesso / privilégio para modificar o código do aplicativo. Política. Você acredita nisso? Então, devo esperar até que o detentor dos direitos fazer as mudanças que eu solicitados.

  3. A partir de experiências anteriores, eu sei que as alterações solicitadas levará dois meses para entrar em produção. Não, jogando-as Metodologias Ágeis Livros em suas cabeças não melhorou nada.

  4. Este é um aplicativo intranet. Então eu não tenho um monte de jovens que tentam minar meu prestígio. Mas eu sou jovem o suficiente como para tentar minar o prestígio de "um muito extravagantes serviços de consultoria globais que vem da Índia", mas onde, curiosamente, não há um único indiano que trabalha lá.

Até agora, a melhor resposta vem de "Michel de Mare": bloquear usuários com base em seus IPs. Bem, isso eu fiz ontem. Hoje eu queria fazer algo mais genérico, porque eu tenho um monte de usuários canguru (saltando de um endereço IP para outro) porque eles usam VPN ou DHCP.

Respondeu 06/08/2008 em 16:58
fonte usuário

votos
0

Se você está tentando impedir que bots motor de busca de acessar determinadas páginas, verifique se você está usando um formatado corretamente robots.txt arquivo.

Usando HTTP_REFERER não é confiável porque é facilmente falsificado .

Outra opção é verificar a seqüência do agente do usuário para bots conhecidos (pode exigir a modificação de código).

Respondeu 06/08/2008 em 16:32
fonte usuário

votos
0

Eu estou supondo que você está tentando evitar a captura de tela?

Na minha opinião honesta é uma pergunta difícil de resolver e tentar corrigir, verificando o valor de HTTP_REFERER é apenas um esparadrapo. Alguém vai ter o trabalho de submissões automatizando vai ser experiente o suficiente para enviar o referer correta de seu 'autômato'.

Você poderia tentar limitação de taxa, mas sem modificar o aplicativo para forçar algum tipo de é-isso-a-humano de validação (um CAPTCHA) em algum momento, então você vai achar isto difícil de evitar.

Respondeu 06/08/2008 em 16:00
fonte usuário

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more