É uma cadeia de HTTPS consulta seguro?

Question

Estou criando uma API baseada na Web segura que utiliza HTTPS; no entanto, se eu permitir que os usuários para configurá-lo (incluem o envio de senha) usando uma seqüência de consulta será esta também ser seguro ou devo forçá-lo a ser feito através de um POST?

Answer 1

Sim, é. Mas usando GET para os dados sensíveis é uma má idéia por vários motivos:

• Na maior parte HTTP de referência de fuga (uma imagem externa na página de destino pode vazar a senha [1])
• Senha serão armazenados em logs do servidor (que é obviamente ruim)
• Histórico armazena em cache em navegadores

Portanto, mesmo que QueryString é garantido que não é recomendado para transferir dados sensíveis sobre querystring.

[1] Embora eu preciso notar que RFC afirma que o navegador não deve enviar referências de HTTPS para HTTP. Mas isso não significa um mau 3ª barra de ferramentas do navegador partido ou uma imagem externa / flash de um site HTTPS não vai vazar isso.

Answer 2

A partir de um "cheirar o pacote de rede" ponto de vista de um pedido GET é seguro, como o navegador irá primeiro estabelecer a conexão segura e, em seguida, enviar o pedido que contém os parâmetros GET. Mas GET url do serão armazenados no usuários do navegador história / autocomplete, que não é um bom lugar para armazenar por exemplo dados de senha em. Claro que isso só se aplica se você tomar a definição mais ampla "Webservice" que possam acessar o serviço a partir de um navegador, se você acessá-lo apenas a partir de seu aplicativo personalizado isso não deve ser um problema.

Então, usando pós pelo menos para diálogos de senha deve ser preferido. Também como apontado na ligação littlegeek colocaram um URL GET é mais provável de ser escrito para seus registros do servidor.

Answer 3

Sim , as seqüências de consulta serão criptografados.

O atrás razão é que as cadeias de consulta são parte do protocolo HTTP que é um protocolo da camada de aplicação, enquanto que a parte de segurança (SSL / TLS) vem da camada de transporte. A conexão SSL é estabelecida em primeiro lugar e, em seguida, os parâmetros de consulta (que pertencem ao protocolo HTTP) são enviados para o servidor.

Ao estabelecer uma conexão SSL, seu cliente irá executar as seguintes etapas em ordem. Suponha que você está tentando fazer login para um site chamado example.com e deseja enviar suas credenciais usando parâmetros de consulta. Seu URL completa pode ser parecido com o seguinte:

https://example.com/login?username=alice&password=12345)

1. O seu cliente (por exemplo, o navegador / aplicativo móvel) vai primeiro resolver o nome de domínio example.com a um (124.21.12.31) endereço IP usando uma solicitação DNS. Ao consultar essa informação, apenas as informações específicas de domínio é utilizado, ou seja, apenas a example.com será usado.
2. Agora, o cliente tentará se conectar ao servidor com o 124.21.12.31 endereço de IP e tentará conectar à porta 443 (porta de serviço SSL não a porta HTTP padrão 80).
3. Agora, o servidor em example.com enviará seus certificados para o seu cliente.
4. O seu cliente irá verificar os certificados e começar a trocar uma chave secreta compartilhada para sua sessão.
5. Depois de estabelecer com sucesso uma conexão segura, só então os parâmetros de consulta ser enviados através da conexão segura.

Por isso, você não vai expor dados sensíveis. No entanto, o envio de suas credenciais através de uma sessão HTTPS usando este método não é o melhor caminho. Você deve ir para uma abordagem diferente.

Answer 4

Sim. todo o texto de uma sessão HTTPS é protegido por SSL. Que inclui a consulta e os cabeçalhos. A esse respeito, um poste e um GET seria exatamente o mesmo.

Como para a segurança do seu método, não há nenhuma maneira real para dizer, sem controlo adequado.

Answer 5

SSL primeiros se conecta ao host, de modo que o nome do host eo número da porta são transferidos como texto simples. Quando as responde de acolhimento e o desafio bem-sucedido, o cliente irá criptografar a solicitação HTTP com o URL real (qualquer coisa ou seja, após a terceira barra) e e enviá-lo para o servidor.

Existem várias maneiras de quebrar essa segurança.

É possível configurar um proxy para agir como um "homem no meio". Basicamente, o navegador envia a solicitação para se conectar ao servidor real para o proxy. Se o proxy é configurado dessa forma, ele irá se conectar via SSL para o servidor real, mas o navegador ainda vai falar com o proxy. Então, se um atacante pode obter acesso do proxy, ele pode ver todos os dados que flui através dele, em texto claro.

Seus pedidos também será visível no histórico do navegador. Os usuários podem ser tentados a marcar o local. Alguns usuários têm ferramentas de marcador de sincronização instalado, para que a senha pode acabar em deli.ci.us ou algum outro lugar.

Por fim, alguém pode ter hackeado seu computador e instalado um registrador de teclado ou um raspador de tela (e um monte de vírus do tipo Cavalo de Tróia fazer). Desde a senha é visível diretamente na tela (em oposição a "*" em um diálogo de senha), esta é uma outra falha de segurança.

Conclusão: Quando se trata de segurança, sempre confiar no caminho batido. Há muita coisa que você não sabe, não vai pensar e que irá quebrar seu pescoço.

Answer 6

Eu não concordo com a afirmação sobre [...] HTTP de referência de fuga (uma imagem externa na página de destino pode vazar a senha) em Slough's resposta .

O HTTP 1.1 RFC afirma explicitamente :

Os clientes não devem incluir um Referer campo de cabeçalho num (não protegido) HTTP pedido, se a página de referência foi transferido com um protocolo seguro.

De qualquer forma, os logs do servidor e histórico do navegador são razões mais do que suficientes para não colocar dados sensíveis na cadeia de consulta.

Answer 7

Sim, contanto que ninguém está olhando por cima do ombro para o monitor.

Answer 8

Sim, a partir do momento em que você estabelecer uma conexão HTTPS everyting é seguro. A string de consulta (GET) como o POST é enviado através de SSL.

Answer 9

Você pode enviar senha como hash MD5 param com um pouco de sal adicionado. Compará-lo no lado do servidor para autenticação.