Respuestas:
Sí lo es. Pero usar GET para datos confidenciales es una mala idea por varias razones:
Por lo tanto, a pesar de que 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 desde HTTPS a HTTP. Pero eso no significa que una barra de herramientas del navegador de terceros o una imagen / flash externo de un sitio HTTPS no lo filtre.
History caches in browserso agregar alguna referencia para ir?
Desde el punto de vista de "olfatear el paquete de red", una solicitud GET es segura, ya que el navegador primero establecerá 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 / autocompletado del navegador del usuario, que no es un buen lugar para almacenar, por ejemplo, datos de contraseña. 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 usar la publicación al menos para los diálogos de contraseña. Además, como se señaló en el enlace que littlegeek publicó, es más probable que se escriba una URL GET en los registros de su servidor.
Sí , sus cadenas de consulta será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 realizará los siguientes pasos en orden. Suponga 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 tener el siguiente aspecto:
https://example.com/login?username=alice&password=12345)
example.coma una dirección IP (124.21.12.31)mediante una solicitud de DNS. Al consultar esa información, solo se usa información específica del dominio, es decir, solo example.comse usará.124.21.12.31e intentará conectarse al puerto 443 (el puerto de servicio SSL no es el puerto HTTP predeterminado 80).example.comenviará sus certificados a su cliente.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 optar por un enfoque diferente.
(e.g http://example.com/login?username=alice&password=12345).
Si. 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 forma real de decirlo 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 oblicua) 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 se configura 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 verse tentados a 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 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 del tipo Trojan Horse lo hacen). 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.
Sí, siempre y cuando nadie mire por encima del hombro el monitor.
No estoy de acuerdo con la afirmación sobre [...] la fuga del referente 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 declara explícitamente :
Los clientes NO DEBEN incluir un campo de encabezado 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 poner datos confidenciales en la cadena de consulta.
Puede enviar la contraseña como MD5 hash param con un poco de sal agregada. Compárelo en el lado del servidor para la autenticación.