Uma cadeia de consulta HTTPS é segura?

Estou criando uma API segura baseada na web que usa HTTPS; no entanto, se eu permitir que os usuários configurem (inclua 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. Mas usar o GET para dados confidenciais é uma má ideia por vários motivos:

    • Principalmente o vazamento do 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 em navegadores

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

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

    De um ponto de vista “farejar o pacote de rede”, uma solicitação GET é segura, pois o navegador primeiro estabelecerá a conexão segura e enviará a solicitação contendo os parâmetros GET. Mas o url do GET será armazenado no histórico / preenchimento automático do navegador do usuário, que não é um bom local para armazenamento, por exemplo, dados de senha. É claro que isso só se aplica se você usar a definição “Webservice” mais ampla que pode acessar o serviço de um navegador. se você acessá-lo apenas a partir do seu aplicativo personalizado, isso não deve ser um problema.

    Então, usando post pelo menos para checkboxs de diálogo de senha deve ser preferido. Também como apontado no link littlegeek postou um URL GET é mais provável que seja gravado em seus logs do servidor.

    Sim. Todo o texto de uma session HTTPS é protegido por SSL. Isso inclui a consulta e os headers. A esse respeito, um POST e um GET seriam exatamente os mesmos.

    Quanto à segurança do seu método, não há maneira real de dizer sem a devida inspeção.

    Sim , suas strings de consulta serão criptografadas.

    A razão por trás disso é que as strings de consulta fazem parte do protocolo HTTP , que é um protocolo da camada de aplicação, 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 chamará as etapas a seguir em ordem. Suponha que você esteja tentando fazer login em um site chamado example.com e queira enviar suas credenciais usando parâmetros de consulta. Seu URL completo pode se parecer com o seguinte.

     (eg 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.com) para um endereço IP (124.21.12.31) usando uma solicitação de DNS . Ao consultar essa informação, apenas informações específicas do domínio são usadas. ou seja: somente example.com será usado.
    2. Agora, seu cliente tentará se conectar ao servidor com o endereço IP 124.21.12.31 e tentará se conectar à porta 443 (a porta de serviço SSL não é a porta http padrão 80 ).
    3. Agora, o servidor em example.com enviará seus certificados ao seu cliente.
    4. Seu cliente verificará os certificados e começará a trocar uma chave secreta compartilhada por sua session.
    5. Depois de estabelecer com sucesso uma conexão segura, somente os seus parâmetros de consulta serão enviados através da conexão segura.

    Portanto, você não exporá dados confidenciais. No entanto, enviar suas credenciais por uma session https usando esse método não é o melhor caminho. Você deve ir para uma abordagem diferente.

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

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

    É possível configurar um proxy para atuar como um “homem no meio”. Basicamente, o navegador envia a solicitação para se conectar 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 access ao proxy, ele poderá ver todos os dados que passam por ele em texto não criptografado.

    Suas solicitações também estarão visíveis no histórico do navegador. Os usuários podem ficar tentados a marcar o site. Alguns usuários têm ferramentas de synchronization de favoritos instaladas, portanto, a senha pode acabar em deli.ci.us ou em outro lugar.

    Por fim, alguém pode ter hackeado seu computador e instalado um registrador de teclado ou um scraper de canvas (e muitos vírus do tipo cavalo de Tróia fazem). Como a senha é visível diretamente na canvas (em oposição a “*” em uma checkbox de diálogo de senha), essa é outra brecha de segurança.

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

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

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

    O HTTP 1.1 RFC declara explicitamente :

    Os clientes NÃO DEVEM include um campo de header Referer em uma solicitação HTTP (não segura) se a página referente foi transferida com um protocolo seguro.

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

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

    Você pode enviar a senha como MD5 hash param com algum sal adicionado. Compare-o no lado do servidor para auth.