¿Es segura una cadena de consulta HTTPS?

Estoy creando una API segura basada en web que usa HTTPS; Sin embargo, si permito a los usuarios configurarlo (incluir el envío de la contraseña) usando una cadena de consulta, ¿esto también será seguro o debería forzarlo a hacerlo a través de un POST?

Sí lo es. Pero usar GET para datos confidenciales es una mala idea por varias razones:

  • En su mayoría, fuga de referencia HTTP (una imagen externa en la página de destino puede perder la contraseña [1])
  • La contraseña se almacenará en los registros del servidor (que obviamente es malo)
  • Cachés de historial en navegadores

Por lo tanto, aunque Querystring está protegido, no se recomienda transferir datos confidenciales a través de la cadena de consulta.

[1] Aunque debo tener en cuenta que RFC establece que el navegador no debe enviar referencias de HTTPS a HTTP. Pero eso no significa que una mala barra de herramientas del navegador de terceros o una imagen / flash externo de un sitio HTTPS no lo filtre.

Desde el punto de vista de “olfatear el paquete de red”, una solicitud GET es segura, ya que el navegador establecerá primero la conexión segura y luego enviará la solicitud que contiene los parámetros GET. Pero las URL de GET se almacenarán en el historial / autocompletar del navegador de los usuarios, que no es un buen lugar para almacenar, por ejemplo, datos de contraseñas. Por supuesto, esto solo se aplica si toma la definición más amplia de “servicio web” que podría acceder al servicio desde un navegador. si accede solo desde su aplicación personalizada, esto no debería ser un problema.

Por lo tanto, se debe preferir publicar al menos para los cuadros de diálogo de contraseña. También como se señala en el enlace que Littlegeek publicó, es más probable que se escriba una URL GET en los registros de su servidor.

Sí. El texto completo de una sesión HTTPS está protegido por SSL. Eso incluye la consulta y los encabezados. En ese sentido, un POST y un GET serían exactamente lo mismo.

En cuanto a la seguridad de su método, no hay una manera real de decirlo sin una inspección adecuada.

, sus cadenas de consulta estarán encriptadas.

La razón detrás es que las cadenas de consulta son parte del protocolo HTTP que es un protocolo de capa de aplicación, mientras que la parte de seguridad (SSL/TLS) proviene de la capa de transporte. La conexión SSL se establece primero y luego los parámetros de consulta (que pertenecen al protocolo http) se envían al servidor.

Al establecer una conexión SSL , su cliente llamará a los siguientes pasos en orden. Supongamos que está intentando iniciar sesión en un sitio llamado example.com y desea enviar sus credenciales mediante parámetros de consulta. Su URL completa puede verse como la siguiente.

 (eg https://example.com/login?username=alice&password=12345) 
  1. Su cliente (por ejemplo: navegador / aplicación móvil) primero resolverá su nombre de dominio (example.com) a una dirección IP (124.21.12.31) utilizando una solicitud de DNS . Al consultar esa información, solo se utiliza información específica del dominio. es decir: solo se usará example.com .
  2. Ahora, su cliente intentará conectarse al servidor con la dirección IP 124.21.12.31 e intentará conectarse al puerto 443 (puerto de servicio SSL no el puerto http predeterminado 80 ).
  3. Ahora, el servidor en example.com enviará sus certificados a su cliente.
  4. Su cliente verificará los certificados y comenzará a intercambiar una clave secreta compartida para su sesión.
  5. Después de establecer con éxito una conexión segura, solo sus parámetros de consulta se enviarán a través de la conexión segura.

Por lo tanto, no expondrá datos confidenciales. Sin embargo, enviar sus credenciales a través de una sesión https utilizando este método no es la mejor manera. Deberías ir por un enfoque diferente.

SSL primero se conecta al host, por lo que el nombre de host y el número de puerto se transfieren como texto sin cifrar. Cuando el host responde y el desafío tiene éxito, el cliente cifrará la solicitud HTTP con la URL real (es decir, cualquier cosa después de la tercera barra) y la enviará al servidor.

Hay varias formas de romper esta seguridad.

Es posible configurar un proxy para actuar como un “hombre en el medio”. Básicamente, el navegador envía la solicitud para conectarse al servidor real al proxy. Si el proxy está configurado de esta manera, se conectará mediante SSL al servidor real, pero el navegador seguirá hablando con el proxy. Entonces, si un atacante puede obtener acceso al proxy, puede ver todos los datos que fluyen a través de él en texto claro.

Sus solicitudes también serán visibles en el historial del navegador. Los usuarios pueden tener la tentación de marcar el sitio. Algunos usuarios tienen instaladas herramientas de sincronización de marcadores, por lo que la contraseña podría terminar en deli.ci.us u otro lugar.

Por último, alguien podría haber pirateado su computadora e instalado un registrador de teclado o un raspador de pantalla (y muchos virus tipo Caballo de Troya). Dado que la contraseña es visible directamente en la pantalla (en lugar de “*” en un diálogo de contraseña), este es otro agujero de seguridad.

Conclusión: cuando se trata de seguridad, siempre confíe en el camino trillado. Hay demasiado que no sabes, que no pensarás y que te romperá el cuello.

Sí, siempre y cuando nadie mire por encima del hombro al monitor.

No estoy de acuerdo con la statement sobre […] fuga de referencia HTTP (una imagen externa en la página de destino podría perder la contraseña) en la respuesta de Slough .

El HTTP 1.1 RFC establece explícitamente :

Los clientes NO DEBEN incluir un campo de cabecera Referer en una solicitud HTTP (no segura) si la página de referencia se transfirió con un protocolo seguro.

De todos modos, los registros del servidor y el historial del navegador son razones más que suficientes para no colocar datos confidenciales en la cadena de consulta.

Sí, desde el momento en que establece una conexión HTTPS, todo está seguro. La cadena de consulta (GET) como la POST se envía a través de SSL.

Puede enviar la contraseña como MD5 hash param con algo de sal añadida. Compárelo en el servidor para auth.