Uma string de consulta HTTPS é segura?

Estou criando uma API segura baseada na Web que usa HTTPS; no entanto, se eu permitir que os usuários o configurem (incluindo o envio de senha) usando uma string de consulta, isso também será seguro ou devo forçá-lo a ser feito por meio de um POST?

Sim, ele é. Mas usar GET para dados confidenciais é uma má ideia por vários motivos:

• Principalmente vazamento de referenciador HTTP (uma imagem externa na página de destino pode vazar a senha [1])
• A senha será armazenada nos logs do servidor (o que é obviamente ruim)
• Caches de histórico nos navegadores

Portanto, mesmo que o Querystring esteja protegido, não é recomendável transferir dados confidenciais sobre o querystring.

[1] Embora eu precise observar que o RFC afirma que o navegador não deve enviar referenciadores de HTTPS para HTTP. Mas isso não significa que uma barra de ferramentas de navegador de terceiros ruim ou uma imagem / flash externo de um site HTTPS não a vazem.

Do ponto de vista "cheirar o pacote de rede", uma solicitação GET é segura, pois o navegador primeiro estabelece a conexão segura e envia a solicitação contendo os parâmetros GET. Porém, os URLs GET serão armazenados no histórico / preenchimento automático do navegador dos usuários, o que não é um bom local para armazenar, por exemplo, dados de senha. É claro que isso só se aplica se você seguir a definição mais ampla de "Serviço da Web" que pode acessar o serviço a partir de um navegador, se você acessá-lo apenas do seu aplicativo personalizado, isso não deve ser um problema.

Portanto, deve-se usar o post pelo menos para caixas de diálogo com senha. Além disso, como apontado no link que a littlegeek postou, um URL GET provavelmente será gravado nos logs do servidor.

Sim , suas cadeias de consulta serão criptografadas.

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

Ao estabelecer uma conexão SSL, seu cliente executará as seguintes etapas em ordem. Suponha que você esteja tentando fazer login em um site chamado example.com e deseje enviar suas credenciais usando parâmetros de consulta. Seu URL completo pode se parecer com o seguinte:

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

1. Seu cliente (por exemplo, navegador / aplicativo móvel) primeiro resolverá seu nome de domínio example.compara um endereço IP (124.21.12.31)usando uma solicitação DNS. Ao consultar essas informações, apenas informações específicas do domínio são usadas, ou seja, somente example.comserão usadas.
2. Agora, seu cliente tentará se conectar ao servidor com o endereço IP 124.21.12.31e tentará se conectar à porta 443 (porta de serviço SSL, não a porta HTTP padrão 80).
3. Agora, o servidor em example.comenviará seus certificados para o seu cliente.
4. Seu cliente verificará os certificados e começará a trocar uma chave secreta compartilhada pela sua sessão.
5. Após estabelecer com êxito uma conexão segura, somente então seus parâmetros de consulta serão enviados por meio da conexão segura.

Portanto, você não expõe dados confidenciais. No entanto, enviar suas credenciais por uma sessão HTTPS usando esse método não é a melhor maneira. Você deve optar por uma abordagem diferente.

Sim. O texto inteiro de uma sessão HTTPS é protegido por SSL. Isso inclui a consulta e os cabeçalhos. Nesse aspecto, um POST e um GET seriam exatamente os mesmos.

Quanto à segurança do seu método, não há como dizer sem uma inspeção adequada.

O SSL primeiro se conecta ao host, para que o nome do host e o número da porta sejam transferidos como texto não criptografado. Quando o host responde e o desafio é bem-sucedido, o cliente criptografa a solicitação HTTP com a URL real (ou seja, qualquer coisa após a terceira barra) e a envia ao servidor.

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

É possível configurar um proxy para atuar como um "homem do meio". Basicamente, o navegador envia a solicitação para conectar-se ao servidor real ao proxy. Se o proxy estiver configurado dessa maneira, ele se conectará via SSL ao servidor real, mas o navegador ainda conversará com o proxy. Portanto, se um invasor puder obter acesso ao proxy, poderá ver todos os dados que fluem por ele em texto não criptografado.

Seus pedidos também serão visíveis no histórico do navegador. Os usuários podem ficar tentados a marcar o site como favorito. Alguns usuários têm ferramentas de sincronização de favoritos instaladas, portanto, a senha pode acabar em deli.ci.us ou em outro local.

Por fim, alguém pode ter hackeado o seu computador e instalado um registrador de teclado ou um raspador de tela (e muitos vírus do tipo Trojan Horse o fazem). Como a senha é visível diretamente na tela (ao contrário de "*" em um diálogo de senha), isso é outra falha de segurança.

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

Sim, desde que ninguém esteja olhando por cima do ombro para o monitor.

Não concordo com a declaração sobre o vazamento [...] do referenciador HTTP (uma imagem externa na página de destino pode vazar a senha) na resposta de Slough .

O HTTP 1.1 RFC afirma explicitamente :

Os clientes não devem incluir um campo de cabeçalho de referência em uma solicitação HTTP (não segura) se a página de referência foi transferida com um protocolo seguro.

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

Sim, a partir do momento em que você estabelece uma conexão HTTPS, tudo é seguro. A string de consulta (GET) como o POST é enviada por SSL.

Você pode enviar a senha como parâmetro de hash MD5 com um pouco de sal adicionado. Compare-o no lado do servidor para autenticação.