há problema em usar URLs aleatórios em vez de senhas? [fechadas]


12

É considerado "seguro" usar URL construído a partir de caracteres aleatórios como este?

http://example.com/EU3uc654/Photos

Eu gostaria de colocar alguns arquivos / galerias de imagens em um servidor da web que devem ser acessados ​​apenas por um pequeno grupo de usuários. Minha principal preocupação é que os arquivos não sejam apanhados por mecanismos de pesquisa ou curiosos usuários avançados que vasculham meu site.

Eu configurei um arquivo .htaccess, apenas para perceber que clicar em http://user:pass@url/links não funciona bem com alguns navegadores / clientes de email, solicitando diálogos e mensagens de aviso que confundem meus usuários que não são muito conhecedores de computadores.


Não. Você pode usar isso, mas não como o único ou principal mecanismo de autenticação.
Andrew Smith

1
Eu tentei isso como um experimento várias vezes e sempre que os links acabam nos mecanismos de pesquisa. Não sei como, mas sei que acontece.
David Schwartz

Você pode querer configurar o SSL para interromper os avisos, obter certificados gratuitos do site startsl.com e o SSL não é mais intensivo em termos computacionais (desde que esteja configurado corretamente).
Hubert Kario

Esta pergunta é um exemplo clássico de "não construtivo". Não sabemos o quanto você valoriza a segurança de suas fotos. A única maneira de comunicar a importância da segurança é pela metodologia de autorização que você implementa para proteger o acesso a essas imagens. O que você obteve são "argumentos de debate" na forma de "Respostas". Mas nenhum deles é um levantamento completo das implicações técnicas e de segurança modernas. Você deve ler os métodos de segurança fornecidos por sua plataforma e avaliar o valor de cada um para sua situação; se você tiver mais perguntas depois de fazer isso, pergunte novamente.
Chris S

Respostas:


17

Se está "ok" ou não, depende da sensibilidade das imagens.

Se você não estiver usando SSL, os URLs, HTML e as próprias imagens serão armazenadas em cache nos computadores do usuário. Isso pode vazar, mas eu consideraria improvável.

As barras de ferramentas do navegador, especialmente as criadas por empresas que executam rastreadores, como Alexa e Netcraft, podem reportar URLs visitados de volta aos sites pai, prontos para o bot entrar e rastrear mais tarde.

A autenticação adequada, como autenticação HTTP ou uma variável POST, não deve ser armazenada em cache dessa maneira ou reportada a qualquer site pai.

Outra técnica é usar URLs únicos e de curta duração. Dessa forma, mesmo que vazem, não importa muito. Obviamente, você deve atualizar seus usuários legítimos dos novos URLs.


+1 por mencionar as barras de ferramentas do navegador.
Hubert Kario

23

Não, na verdade, isso é apenas segurança através da obscuridade, que não é absolutamente nenhuma segurança. Qualquer coisa que seja diretamente acessível pela Internet sem alguma forma de proteção real será encontrada, indexada e armazenada em cache.


10
Todas as senhas não são apenas segurança através da obscuridade?
Winston Ewert

4
@WinstonEwert: As próprias senhas não têm nada a ver com segurança através da obscuridade, relacionada ao sigilo do design / implementação. No caso de, por exemplo, autenticação básica do Apache, seu design / implementação é totalmente aberto para todos verem.
#

10
absurdo - tudo é segurança através da obscuridade. O ponto principal é que, para chegar lá, você precisa de uma informação que é suficientemente improvável de ser adivinhada. A frase "Segurança através da obscuridade" é excessivamente abusada. Uma parte aleatória do URL é exatamente equivalente a colocar uma "senha" no URL. A única questão é - quem pode ver isso, e a resposta que eu coloquei no meu comentário é "proxies intermediários, além disso, é http assim qualquer um que pode bisbilhotar"
Bron Gondwana

1
Um erro (ou retorne à configuração padrão) na configuração do apache e seus diretórios mostram índices com todos os arquivos e diretórios na palma da sua mão, não tanto com senhas.
Hubert Kario

4
Você diz que a segurança através da obscuridade "está relacionada ao sigilo do design / implementação". Mas, claramente, URLS aleatórios não relacionam o sigilo do design / implementação. Portanto, URLs aleatórios, quaisquer que sejam suas falhas, não podem ser classificados como segurança pela obscuridade.
Winston Ewert

6

Eles serão registrados em todos os proxy ao longo do caminho. Você estará protegido contra usuários avançados e mecanismos de pesquisa curiosos, a menos que alguém realmente publique o link.

E atente para a aleatoriedade do seu gerador, é claro.

Suponho que você não esteja procurando uma segurança super alta aqui.


Se alguém publicasse a URL, nada o impediria de publicar uma senha. A autenticação pelo conhecimento como um fator sempre pode ser "enganada" assim.
Manuel Faux

@ManuelFaux: Claro, se for intencional. Mas também pode ser acidental. Por exemplo, ele pode usar uma ferramenta que verifica os URLs que ele visita para ver se foram denunciados como maliciosos. As ferramentas sabem que as senhas devem ser mantidas em segredo. Eles sabem que os parâmetros nos URLs podem ser sensíveis. Mas eles não sabem o que os caminhos nos URLs sabem. (Por exemplo, referenciador http ).
David Schwartz

5

Um URL enigmático é útil para downloads de uso único, mas não oferece proteção real. Você precisa estar ciente de que nem todos os bots respeitam o arquivo robots.txt; portanto, se houver algum link em qualquer lugar do seu site que leve à pasta disfarçada, ele será indexado por alguns mecanismos de pesquisa e, uma vez iniciado, não haverá retorno.

Eu sugiro usar um sistema de autenticação baseado em .htaccess simples, ou em adição ao que você está propondo.


5

Gostaria de adicionar outra perspectiva, talvez mais assustadora, de URLs ofuscadas como este exemplo. Mesmo que seu URL não seja compartilhado acidentalmente, ele pode ser enviado aos mecanismos de pesquisa por:

  • ISP de um visitante. As visitas HTTP estão sendo coletadas, datamined e às vezes até vendidas diretamente a terceiros pelos ISPs.
  • O armazenamento em nuvem de um visitante. Existem vários serviços que armazenam favoritos e histórico gratuitamente para sincronizar nas instalações do navegador. A menos que eles pré-criptografem os dados, como o Mozilla faz, as mesmas práticas de mineração de dados podem ser implícitas.

YMMV.


oh sim - ou apenas por um navegador plug-in que procura por sites relacionados ou permite aos usuários compartilhar anotações sobre uma página
Bron Gondwana

2

No passado, usei um método semelhante para permitir aos usuários criar espaços de compartilhamento em um sistema de gerenciamento de documentos. O conteúdo compartilhado não era extremamente secreto, portanto o sistema não precisava ser ultra seguro.

Acabei de fazer com que o URL de cada usuário contenha um carimbo de data e hora de expiração e um MD5 do email.

Assim, o URL parecia:

http://my-url.com/1343689677-cba1f2d695a5ca39ee6f343297a761a4/

com o exposto acima, se o usuário digitar o e-mail user@gmail.com antes de 30 de julho, é recomendável começar.

Não era exatamente segurança de nível militar, mas fazia o trabalho.


0

Isso compartilha a mesma vulnerabilidade que o armazenamento de sessionID na URL. Alguém pode copiar e colar acidentalmente o link para outros, esquecer de censurá-lo em uma captura de tela ou deixar alguém procurar, pois não é marcado com asterisco como senhas.

Além disso, se algum conteúdo estiver protegido por senha, faça o login. Você sabe que é um segredo. Se você receber um link, poderá facilmente esquecê-lo.

Outra coisa é remover privilégios de usuário. Você pode excluir um usuário, para que ele não possa mais fazer login, mas com os links Você precisaria alterar todos eles e enviar a todos (exceto o usuário excluído) novos URLs.

Eu acho que não é ruim se estas são apenas imagens. Mas se estas são algumas imagens que você realmente não gostaria de compartilhar;), então sugiro que você use palavras aleatórias mais longas, mais parecidas com as que foram apresentadas.

EDIT: adicione? DO_NOT_SHARE_THIS_LINK ao URL: http://example.com/DO_NOT_SHARE_THIS_LINK/EU3uc654-this-should-be-longer/Photos?DO_NOT_SHARE_THIS_LINK

É o que, por exemplo, o Kongregate faz ao incorporar jogos hospedados em outros lugares (coloca credenciais de autenticação no URL do quadro). Aliás, o Kongregate também usa links de acesso de convidados para jogos não publicados, da maneira que você deseja usar.


Na verdade, é muito pior que os IDs de sessão, porque as sessões expiram após algum tempo. Os mecanismos de busca que buscam uma identificação de sessão conectada geralmente acabam apresentando um link inoperante / uma sessão não conectada nos resultados. Ou, se o servidor não se importar, ele poderá sincronizar a sessão de muitos usuários e, quando um deles se conectar, todos eles o farão. De qualquer forma, não é tão ruim como registrado permanentemente na URL :-)
Korkman

Claro que é pior, e você também pode se lembrar do IP na sessão, pois precisa fazer o login primeiro para obter o sessid no URL e, em seguida, você pode destruir a sessão se o IP for alterado.
Markus von Broady
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.