SSL con GET y POST

Navega tus respuestas
52

Soy bastante nuevo en seguridad, así que perdone mi pregunta básica, pero ¿SSL encripta las solicitudes POST pero no las solicitudes GET?

Por ejemplo, si tengo dos solicitudes

GET: www.mycoolsite.com/index?id=1&type=xyz

POST

sitio: www.mycoolsite.com/index { Parámetros: id = 1 & type = xyz }

¿Es seguro asumir que alguien puede interceptar la solicitud GET completa (ID de lectura y tipo), pero si interceptan el POST podrán ver la ruta del sitio, pero debido a que está pasando por SSL, ¿No puedes ver los parámetros de id y tipo?

    
pregunta TomJ 08.03.2012 - 20:17
fuente

6 respuestas

51

Ahora, la pregunta es, ¿sabes qué aspecto tiene una solicitud HTTP ?

Bueno, suponiendo que no, aquí hay un ejemplo de uno: 

GET /test?param1=hello&param2=world HTTP/1.1
Host: subdomain.test.com
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20100101 Firefox/10.0.1
Accept: image/png,image/*;q=0.8,*/*;q=0.5
Accept-Language: en-gb,en;q=0.5
Accept-Encoding: gzip, deflate
DNT: 1
Connection: keep-alive

Toda de esta información se encuentra encapsulada dentro del transporte SSL, como dice el comentario de su respuesta. Esto significa:

  • Los parámetros de obtención están cifrados.
  • El cuerpo HTTP (parámetros de publicación) están cifrados.

Lo que no es necesariamente seguro:

  • El anfitrión que estás pidiendo. En la actualidad, la mayoría de los servidores web son compatibles con los parámetros Host: something , de modo que un solo servidor web puede manejar múltiples dominios en una interfaz y dirección IP. Claramente, este encabezado está cifrado, sin embargo, si ejecuta tráfico no https al sitio, debe estar claro a qué hosts puede conectarse. Incluso si ese no es el caso, el DNS inverso le dirá lo que está alojado en esa IP y probablemente pueda hacer una estimación razonable desde allí.
  • La información de su navegador / cliente. Desafortunadamente, cada cliente https es diferente y su proceso de negociación podría revelar la plataforma en la que se ejecuta o el navegador. Este no es el fin del mundo de ninguna manera, es solo un hecho para entender.

Las solicitudes POST son similares a las solicitudes de obtención, excepto que contienen un cuerpo. Esto puede verse así: 

POST /testpost HTTP/1.1
Host: subdomain.test.com
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20100101 Firefox/10.0.1
Accept: image/png,image/*;q=0.8,*/*;q=0.5
Accept-Language: en-gb,en;q=0.5
Accept-Encoding: gzip, deflate
DNT: 1
Connection: keep-alive

param1=hello&param2=hello

Hay algunas variantes más complicadas, por supuesto, pero esencialmente todo está encriptado de todos modos.

    
respondido por el user2213 08.03.2012 - 20:45
fuente
32

No vi esto mencionado en las otras respuestas, pero en general no debería poner información secreta (contraseñas) en las solicitudes GET, incluso con SSL, sino usar POST. ¿Por qué? La URL con la información confidencial generalmente se registrará en ambos extremos; por ejemplo, en la lista de historial de su navegador (https://www.example.com?user=me&password=MyPassword), así como los registros en el servidor. La información POST (especialmente con contraseñas) generalmente no se escribe en los registros del servidor web, aunque obviamente se puede configurar para que se registre, por lo que es mejor no reutilizar (o usar contraseñas similares) en diferentes sitios.

    
respondido por el dr jimbob 08.03.2012 - 21:08
fuente
15

SSL encripta y asegura la autenticidad de toda la conexión, incluido el método solicitado y la URL. Un GET está tan bien protegido como un POST.

Cuando SSL funciona según lo previsto, un intruso solo puede ver qué dirección IP se está conectando a qué dirección IP (y en qué puerto, pero generalmente es 443), a qué hora y cuánto. Si hay varios hosts virtuales en la misma máquina, el atacante no puede saber con cuál está contactando (sin embargo, el intruso puede ver sus solicitudes de DNS justo antes de la solicitud de HTTPS y hacer una conjetura plausible). Toda esta información también está autenticada: un atacante activo no puede reproducir man-in-the-middle y Modificar los datos en tránsito.

Las cosas que pueden hacer que SSL no funcione según lo previsto:

  • Uso incorrecto de la aplicación, donde algunos datos se envían accidentalmente a través de HTTP simple.
  • Una de las raras vulnerabilidades en el protocolo SSL, como la reciente vulnerabilidad de BEAST .
  • Manipulación incorrecta del certificado, que permite al atacante pasar por el servidor, ya sea porque el certificado del servidor se ha filtrado, una autoridad de certificación ha entregado incorrectamente un certificado al atacante o porque el cliente no verifica el certificado del servidor correctamente. .
    • En esta nota, recuerde que SSL, como se usa la mayor parte del tiempo, autentica el servidor pero no el cliente. El servidor no puede asumir nada sobre el cliente.
  • Un ataque de canal lateral puede revelar cierta información al intruso. Por ejemplo, el momento exacto en el que los participantes envían datos puede revelar algo sobre cómo se calculan los datos y, por lo tanto, sobre la naturaleza de los datos. El atacante también conoce el tamaño de cada paquete. El hecho de revelar esto puede depender de si los participantes toman precauciones y de la naturaleza de la información. Una conversación en tiempo real es mucho más propensa a este tipo de análisis de tráfico que la descarga de un archivo.

Vea también ¿Cómo es posible que las personas que observan que se está estableciendo una conexión HTTPS no sabrían cómo descifrarla? para algunos antecedentes.

    
respondido por el Gilles 08.03.2012 - 20:48
fuente
5

Solo para agregar un pequeño detalle más, en cuanto a cómo se logra esto a través de HTTP.
Probablemente se esté preguntando (o debería estarlo, si sabe que está familiarizado con el protocolo de enlace SSL ), cómo ¿Se crea el canal SSL, sin que la solicitud GET se envíe sin cifrar? ¿Qué pasa si mi solicitud tiene que pasar por un proxy? ¿Cómo es eso posible?

HTTP v1.1 introdujo un CONNECT Método HTTP, que básicamente envía una solicitud simplificada a el servidor a través de un proxy, que contiene solo la URL del host más simple (sin ningún parámetro, encabezado o cuerpo adicional). Sobre la base de esta solicitud, se construye un túnel SSL y luego se envía la solicitud GET (o POST) original a través de él.

    
respondido por el AviD 15.03.2012 - 12:16
fuente
4
  

Fuente: Respuesta en desbordamiento de pila

El método GET está destinado solo para la recuperación de datos y no debe tener ningún efecto secundario . Pero POST está diseñado para ese propósito específico: modificar los datos en el lado del servidor.

Las solicitudes GET se pueden evitar fácilmente (consulte falsificación de solicitudes entre sitios ) con solo colocar una imagen en una página mientras falsifica solicitudes POST no es tan fácil (esta es también una razón por la que solo debe permitir solicitudes POST autorizadas).

    
respondido por el random65537 15.03.2012 - 16:18
fuente
3

Otro punto que no se menciona es que si usa GET y tiene contenido de terceros incrustado o vinculado (por ejemplo, anuncios de sitios), ese sitio de terceros obtendrá la URL completa (con datos de parámetros confidenciales) en el encabezado del Referer.

Eso expone los datos a terceros que no deberían tenerlos.

    
respondido por el Rodney 16.01.2014 - 16:34
fuente

Lea otras preguntas en las etiquetas

Virus codificado en video ¿Cómo se encuentran los cero días?