ssl - puerto - https significado

¿Es segura una cadena de consulta HTTPS? (9)

Estoy creando una API segura basada en web que utiliza HTTPS; sin embargo, si permito que los usuarios lo configuren (incluido el envío de la contraseña) mediante una cadena de consulta, ¿esto también será seguro o debo forzar que se haga a través de un POST?

Sí , sus cadenas de consulta serán encriptadas.

El motivo es que las cadenas de consulta forman 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á los siguientes pasos en orden. Supongamos que está intentando iniciar sesión en un sitio llamado example.com y desea enviar sus credenciales utilizando parámetros de consulta. Su URL completa puede verse como la siguiente.

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

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) usando una solicitud de DNS . Al consultar esa información, solo se utiliza información específica del dominio. es decir: solo se utilizará example.com .
Ahora, su cliente intentará conectarse al servidor con la dirección IP 124.21.12.31 e intentará conectarse al puerto 443 (el puerto de servicio SSL no es el puerto http predeterminado 80 ).
Ahora, el servidor en example.com enviará sus certificados a su cliente.
Su cliente verificará los certificados y comenzará a intercambiar una clave secreta compartida para su sesión.
Después de establecer con éxito una conexión segura, solo se enviarán los parámetros de consulta 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.

Desde el punto de vista de "sniff the network packet", 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 GET url se almacenará en el historial / autocompletado del navegador de los usuarios, que no es un buen lugar para almacenar, por ejemplo, datos de contraseña. Por supuesto, esto solo se aplica si se toma la definición más amplia de "Servicio web" que puede 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 debería preferir el uso de publicaciones al menos para diálogos de contraseña. También como se señala en el enlace littlegeek publicado una GET URL es más probable que se escriba en los registros de su servidor.

No estoy de acuerdo con la afirmación sobre la fuga de [...] referencias HTTP (una imagen externa en la página de destino podría filtrar la contraseña) en la respuesta de Slough .

El HTTP 1.1 RFC establece explícitamente :

Los clientes NO DEBEN incluir un campo de encabezado de referencia 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.

Puede enviar la contraseña como parámetro hash MD5 con un poco de sal agregado. Compárelo en el lado del servidor para autenticación.

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

La mayoría de las fugas de referencia de 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 (lo que obviamente es malo)
Historial de cachés en los navegadores.

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

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

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

Sí, siempre y cuando nadie esté mirando por encima del hombro al monitor.

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 decir sin una inspección adecuada.

SSL se conecta primero al host, por lo que el nombre del 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 que actúe 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á a través de 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 como favorito. Algunos usuarios tienen instaladas herramientas de sincronización de marcadores, por lo que la contraseña podría terminar en deli.ci.us o en algún 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 de tipo troyano). Dado que la contraseña es visible directamente en la pantalla (a diferencia 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 demasiadas cosas que no sabes, que no pensarás y que te romperán el cuello.