Hace poco me dijeron que una cookie es "más segura" que un antiguo encabezado HTTP normal, que es más seguro que un parámetro de URL, especialmente cuando se transmiten tokens de acceso. ¿Cuál es el razonamiento detrás de que una cookie sea más segura que un encabezado HTTP?
Además, estoy bastante seguro de que entiendo por qué un parámetro de URL no es seguro: porque está visible todo el tiempo y se puede capturar fácilmente. ¿Es eso correcto?
Las cookies son encabezados HTTP. El encabezado se llama Cookie: y contiene su cookie.
Pero las cookies son de hecho más seguras que los parámetros de URL porque las cookies nunca se envían a otros dominios. Los parámetros de URL, por otro lado, terminarán en el encabezado Referer: de cualquier sitio que visite directamente desde el que tiene el parámetro de URL.
Hay tres formas estándar de pasar datos desde el navegador: GET , POST y cookies (que se envían para las solicitudes GET y POST ). Aquí hay una solicitud de ejemplo que se envía a un servidor si solicitó www.example.org/spec.html?secret=foo:
GET /spec.html?secret=foo HTTP/1.1
Host: www.example.org
Cookie: name=value; name2=value2
Accept: */*
Poner la información de la sesión en la URL hace que sea propenso a ser copiado por el usuario del navegador. Desde un punto de vista de visibilidad en el cable, sin embargo, no hace ninguna diferencia. Es por esta razón que los datos confidenciales a menudo son POST ed. De cualquier forma que realice una solicitud, tenga en cuenta que probablemente debería estar protegido contra CSRF .
En cuanto a las cookies, proporcionan una manera de almacenar datos que duran toda la sesión o en las pestañas del navegador.
Las cookies son parte de la encabezado HTTP , por lo que no pueden ser más seguras que ellas. Las cookies tienen marcas de seguridad integradas en su especificación: HTTPOnly y Secure, the este último impide la transmisión a través de conexiones no SSL.
Los parámetros como parte de la URL son propensos a ser registrados por los servicios web que está ejecutando como parte de las estadísticas o, de lo contrario, los deja abiertos para su lectura en texto sin formato para cualquier persona que pueda obtener acceso.
Si está pasando el token de autorización a través de los encabezados http, debe tener una lógica del lado del cliente para pasar esto al servidor cada vez que realice una solicitud. Un skimmer puede buscar esto en el código del lado de su cliente y puede secuestrar su sesión de usuario con un script Java.
Pero si la misma información se pasa a través de cookies, es responsabilidad del navegador pasar la cookie cada vez que se realiza una solicitud (se le libera de escribir la lógica del lado del cliente). Así que es un poco difícil (pero no imposible) identificar el mecanismo por el cual se pasa el token.
Si la cookie está configurada para ser httponly, el secuestro de la sesión se vuelve casi imposible a través de JavaScript (he leído que algunos navegadores dan esta información a JavaScript pero el soporte está aumentando). Y las cookies tienen una misma política de origen. Pero aún utilizando herramientas como el violinista, un pirata informático determinado podrá acceder a esta información.
Pero el hacker debería poder rastrear la red para obtener esta información.
En conclusión, una cookie es definitivamente más segura.
Si está tan preocupado por la seguridad, vaya a los certificados SSL que casi eliminan la amenaza de que la red detecte una actividad inútil.
Los parámetros de URL se envían en el encabezado Referer a otros sitios, por lo que son la peor manera de pasar datos confidenciales.
El (obsoleto) Cookie2 header se cifra utilizando un nonce proporcionado por el sitio en su% encabezado de respuesta Set-Cookie2 . Por lo tanto, esto es lo menos malo, pero no está bien soportado.
Otros encabezados de solicitud (incluido Cookie ) están en algún punto intermedio.
Ninguna de estas opciones es "segura".
La opción segura only es HTTPS (es decir, SSL) usando una autoridad de certificación de confianza mutua.
Supongo que tanto las cookies como los encabezados tienen puntos fuertes y débiles. Ya que algunas respuestas apuntan a los puntos fuertes de las cookies, mencionaré el punto fuerte de los encabezados. Los encabezados deben ser transmitidos programáticamente por la aplicación js; nunca son transmitidos automáticamente por el navegador al acceder a una URL en el dominio respectivo. Esto hace que otras aplicaciones o fragmentos de código js no puedan enviar el encabezado automáticamente, eliminando así una amplia gama de ataques en el CSRF o en áreas de scripts entre sitios. Por supuesto, en ambos casos es necesario usar solo HTTPS sobre TLS y desactivar la degradación a HTTP.