[Cascavel-pm] HTTP_REFERER - variável de ambiente não funciona no protocolo https

[fernandolouis em terra.com.br]

É isso aí Silvio... falou bem, bonito... Não precisou nem chamar o 
LombardÊÊÊ
descontraindo++;

Bom, pessoal, agradeço ajuda e os esclarecimentos. No meu caso, continuarei 
ficando com
a solução do referer, pelo seguinte fato:

Para conseguir acesso, o "cara" tem que fazer as alterações no seu próprio 
browser,
então, só quem entende do assunto vai conseguir. E na verdade o público-alvo
desse site não tem essa "noção", obrigando à acessar o "site-original".

Continuarei nessa solução alternativa até que, quem sabe um dia não haver
possibilidades de alterações nas variáves de ambiente.

[]s,
Fernando

----- Original Message ----- 
From: "Silvio Almeida" <scvalmei em graaph.arq.br>
To: "Cascavel Perl Mongers" <cascavel-pm em pm.org>
Sent: Thursday, May 15, 2008 4:44 PM
Subject: Re: [Cascavel-pm] HTTP_REFERER - variável de ambiente não funciona 
no protocolo https


Éden,

Claro, você tem toda razão, percebi meu erro logo em seguida, o
Http-Referer trata de sequencia de URL acessadas, e não do ponto de
origem dos acessos.

Na verdade não vai ter jeito, porque se a página https://xyz/index.html
supostamente gera conteúdo (links no caso) em função de um header que
além de não ser confiável pode nem sequer existir, então o problema não
tem solução.

A alternativa de webservice que você mencionou, ou o esquema de token
que o Nilson descreveu, são bastante parecidos na medida em que os sites
"licenciados" devem aderir a um esquema particular de comunicação com o
servidor https://xyz, ou seja, um "protocolo" ou "contrato particular de
referenciação". Este "protocolo" (não sei se devia botar aspas) pode
implementar qualquer grau de segurança, basta querer e podemos ter
chaves triplas DSA-RGB 10024 bits por pixel.

A característica mais interessante aqui é que tanto em um caso (Éden)
como em outro (Nilson) a implementação necessariamente acontece nos dois
extremos da linha, isto é, cada página "licenciada" precisa implementar
sua parte do protocolo para poder falar com https://xyz.

O que não acontece na solução que depende apenas do Http-Referer, onde
somente https://xyz cuidaria de manter a lista de sites "licenciados".
De certa forma, o navegador implementa a sua metade de um esquema
simplório: ele envia a URL atual no próximo request sob o header
Http-Referer. O que, em termos de segurança, não serve para nada.

-Silvio


Eden Cardim wrote:
> 2008/5/15 Silvio Almeida <scvalmei em graaph.arq.br>:
>
>> Acessando $ENV{REMOTE_ADDRESS} a partir do CGI você obtém o IP que fez o
>> request. Esta informação é totalmente confiável pois não vem de um
>> header HTTP (forjável por natureza), mas de uma camada Ozzy inferior. Aí
>> no CGI você poderia testar o REMOTE_ADDRESS para determinados ranges
>> para liberar ou não acesso. Isto não funcionaria?
>>
>
> Ele quer bloquear a navegação a partir de links contidos em outros
> websites, não o usuário do user agent
_______________________________________________
Cascavel-pm mailing list
Cascavel-pm em pm.org
http://mail.pm.org/mailman/listinfo/cascavel-pm