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?¿Es segura una cadena de consulta HTTPS?
Sí, lo es.Pero el uso de GET de datos sensibles es una mala idea por varias razones:
Por lo tanto, a pesar de que Querystring se asegura que no es recomendable para la transferencia de 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 mala barra de herramientas del navegador de terceros o una imagen/flash externo de un sitio HTTPS no lo filtre.
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 manera real de decirlo sin una inspección adecuada.
Hay más en la seguridad que solo la comunicación entre el navegador y el servidor – JoeBloggs
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.
Desde un punto de vista "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 las URL de GET se almacenarán en el historial/autocompletar del navegador de los usuarios, que no es un buen lugar para almacenar, p. 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 la publicación de 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.
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.
Existen 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 los caminos trillados. Hay demasiado que no sabes, que no pensarás y que te romperá el cuello.
"el navegador seguirá hablando con el proxy" no del todo cierto, tendrá que presentar el navegador con un certificado válido que el proxy solo puede generar si tiene control sobre una CA en la que el navegador confía. – Pieter
No estoy de acuerdo con la afirmación acerca [...] fugas de referencia HTTP (una imagen externa en la página de destino pueda filtrarse la contraseña) en Slough's response.
El HTTP 1.1 RFC explicitly states:
Los clientes no deben incluir un campo de cabecera Referer en una petición HTTP (no seguro) si la página de referencia fue transferido 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.
Hay esa palabra 'debería' de nuevo. ¿Confiarías en cada versión de cada navegador con tu contraseña? – JoeBloggs
¿Cómo se relaciona esto exactamente con GET vs POST? ¿Sería seguro "cada versión de cada navegador" si está utilizando POST sobre HTTPS? – Arnout
Además, la página web HTTPS podría recuperar una imagen externa * a través de HTTPS *, en cuyo caso, el navegador DEBERÍA incluir el encabezado del referer y, por lo tanto, exponer su contraseña ... – AviD
Sí, siempre y cuando nadie esté mirando por encima del hombro al monitor.
y su navegador no guarda el historial :) –
Puede enviar la contraseña como MD5 hash param con un poco de sal añadida. Compárelo en el servidor para auth.
MD5 no es una función hash adecuada para las contraseñas. – slawek
Pero esto parece una buena idea. –
Ya sea con hash o en texto sin formato, es una mala práctica enviar contraseñas dentro de los parámetros GET. Por favor, consulte la respuesta más votados para obtener explicaciones. Aaaand ... MD5 ya no debería usarse en ninguna parte ... – Thomas
Sí, sus cadenas de consulta serán encriptadas.
La razón subyacente 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 Ejemplo y desea enviar sus credenciales mediante parámetros de consulta. Su completo URL puede verse como el siguiente.
(e.g http://example.com/login?username=alice&password=12345)
(example.com)IP dirección (124.21.12.31) usando una solicitud DNS. Al consultar esa información, solo se utiliza información específica del dominio. es decir: solo se usará example.com.124.21.12.31IP e intentará conectarse al puerto 443 (SSL puerto de servicio no es el puerto por defecto http80).example.com enviará sus certificados a su cliente.Por lo tanto, no expondrá los 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.
Pero vea la respuesta por @dr. mal, la cadena de la cantera puede terminar en archivos de registro y cachés por lo que es posible que no esté segura en el servidor. – zaph
Hola zaph, en términos de seguridad HTTPS, el objetivo es enviar datos de forma segura al servidor sin que nadie en el medio pueda husmear los datos. Si bien eso es posible, y responde la pregunta, es realmente difícil controlar lo que el servidor hace después. Es por eso que también he mencionado que esta no es la forma correcta. Además, nunca debes enviar tu contraseña al cliente. Siempre debe hash it en el dispositivo y enviar el valor de hash al servidor. –
Desde el punto de vista de la seguridad, el envío de información confidencial en la cadena de la cantera no es seguro, es mejor enviarlo en POST.Además, la contraseña suele ser hash en el servidor, no por el cliente. La afirmación "nunca debe enviar su contraseña del cliente" está en conflicto con la respuesta: '(por ejemplo, http://example.com/login?username=alice&password=12345)'. – zaph
¿Qué hay de * https a https * referrers? Si obtengo una imagen de un sitio de terceros usando https? ¿El navegador enviará toda la cadena de consulta desde mi solicitud anterior al servidor de terceros? – Jus12
@ Jus12 sí, sí, no tiene sentido, pero así es como está diseñado. –
Entonces, ¿por qué no se recomienda que la especificación OAuth2 envíe datos confidenciales en los parámetros de consulta (en la URL)? Aunque se recomienda usar TLS (HTTPS) siempre. Consulte el último punto en http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-16#section-4.3 CC @volka – gihanchanuka