¿Están las URL secretas seguras a través de HTTPS? [duplicar]

16

Imagine un servicio que hace que la información confidencial esté disponible bajo una URL secreta a través de HTTPS solamente, sin requerir ninguna otra autenticación. De hecho, estos ya están muy extendidos.

¿Qué nivel de seguridad ofrece esta oferta, en comparación con, por ejemplo, un formulario de inicio de sesión HTTPS tradicional que utiliza un nombre de usuario / contraseña que está guardado en el navegador?

¿Los navegadores filtran la URL de HTTPS (salvo las vulnerabilidades no descubiertas, por supuesto) o es, teóricamente, tan seguro como los archivos locales en la máquina que ejecuta el navegador?

Ejemplo vectores de filtración: Firefox reportero de bloqueo; Chrome encontrar como usted escribe; Servicio de protección de malware de IE. Todos estos pueden potencialmente filtrar la URL a un tercero. ¿Están las URL de HTTPS seguras de esto?

    
pregunta RomanSt 04.04.2013 - 16:17
fuente

3 respuestas

15

En HTTPS , la URL real se envía solo después de que se haya realizado el protocolo SSL. Lo que pueden observar los forasteros es:

  • El nombre del servidor (que se proporciona claramente en el certificado del servidor).
  • La longitud de la solicitud desde su navegador, desde la cual la longitud de la URL generalmente se puede inferir en cierta medida.

Un problema potencial con la "URL secreta" es que pueden ser marcados o copiados por el usuario (por ejemplo, enviados por correo electrónico), y también se muestran en la pantalla del usuario (en la barra de URL), por lo tanto potencialmente vulnerables a surfistas de hombro . Para las contraseñas y también para cookies seguras (cookies enviadas por servidores con el indicador "seguro"), se supone que las aplicaciones involucradas (es decir, los navegadores) son un poco más cautelosas que con URL. Los usuarios humanos también son un poco menos cuidadosos con la URL que con las contraseñas. En general, las URL secretas son un mecanismo de seguridad válido, pero debes estar al tanto de los detalles.

    
respondido por el Thomas Pornin 04.04.2013 - 16:22
fuente
7
  

¿Qué nivel de seguridad ofrece esta oferta, en comparación con, por ejemplo, un formulario de inicio de sesión HTTPS tradicional que utiliza un nombre de usuario / contraseña que está guardado en el navegador?

Como se ha reunido de otras respuestas, HTTPS oculta la solicitud real en sí. La URL completa no se envía cuando se conecta al servidor; la parte del documento de la url se configura como una solicitud que se parece a esto:

GET /login/reallysecure/thisismypassword

o más tradicionalmente:

POST /login

con los parámetros POST enviados más adelante en la solicitud HTTP, ya sea en forma simple o como parte de un cuerpo de mime multiparte.

Una consideración que probablemente no haya pensado es que los servidores web suelen registran , lo que significa que en cualquier momento tendrá que decir 3 días (ajuste la política de retención de registros) el valor del nombre de usuario inicia sesión a un grep de los administradores de sistemas. Si bien esto es indiscutiblemente irrelevante, ya que una modificación de la aplicación en sí misma podría eliminar las credenciales de inicio de sesión normales sin mucha dificultad, ahora hay un factor de protección adicional: ¿hace una copia de seguridad de sus registros? ¿Qué pasa si estos son robados?

Peor aún, ¿qué sucede si hay una manera de manipular su servidor para devolver los registros a un cliente externo? Esto es una violación masiva de la seguridad, pero a diferencia de devolver una base de datos de contraseñas que, con suerte, utilizan una buena técnica de hashing para mitigar (y es mucho más que mitigar) el impacto de esto, una URL no tiene la misma protección, es simplemente instantánea Acceso a la cuenta en cuestión.

Este es el extremo del lado del servidor del riesgo del lado del cliente que Thomas ya ha resaltado.

    
respondido por el user2213 04.04.2013 - 17:31
fuente
2

Es probable que la URL de texto sin formato se almacene en el historial del navegador y en los archivos de caché, pero las URL mismas no se transmitirán de forma clara a través de la red, ya que la sesión SSL comienza antes de que se envíe el tráfico HTTP.

Otro canal lateral es que cualquier contenido que no sea HTTPS en la página HTTPS puede causar que la URL de la página principal se filtre a través del encabezado de referencia. Resulta que la anterior es falso. El remitente no se envía de las páginas HTTPS a las páginas HTTP.

    
respondido por el Polynomial 04.04.2013 - 16:22
fuente

Lea otras preguntas en las etiquetas