introducción
Cookie, Sesión y Token son productos de diferentes etapas en el desarrollo de aplicaciones de red. Los tres tienen sus propias ventajas y desventajas, y no existe una relación antagónica obvia. Por el contrario, a menudo existen juntos, que también es la razón. para frecuentes confusiones. .
1. Problemas encontrados en la interacción de la red
1.1 Experiencia de interacción en red
Como internautas, usamos navegadores para visitar varios sitios web casi todos los días para satisfacer nuestras necesidades diarias de trabajo y vida. La experiencia de red actual sigue siendo muy fluida para nosotros, pero este no es el caso cuando visitamos el sitio web en los primeros días. Básicamente, cada operación que hacemos es un trato de una sola vez. ¿Por qué dices eso?
1.2 Protocolo HTTP sin estado
¿Qué es el protocolo HTTP sin estado?
El protocolo sin estado HTTP significa que el protocolo no tiene capacidad de memoria para el procesamiento comercial y no puede recordar lo que hizo antes. Cada solicitud es completamente independiente entre sí y no tiene ninguna información de contexto.
La falta de estado significa que si el procesamiento posterior necesita información previa, debe retransmitir información crítica, lo que puede conducir a un aumento en la cantidad de datos transferidos por conexión.
Si hemos estado usando este protocolo HTTP nativo sin estado, es posible que tengamos que iniciar sesión nuevamente cada vez que cambiamos una página, ¿entonces todavía tenemos que jugar con un martillo? ¡Los usuarios probablemente quieran regañar a sus madres!
Por lo tanto, es necesario resolver la apatridia del protocolo HTTP y mejorar la experiencia interactiva del sitio web, de lo contrario, la red de estrellas y mares no podrá funcionar.
2. Ideas de solución
En todo el proceso de interacción de solicitud de red, solo están el cliente y el servidor en ambos lados, por lo que es necesario comenzar con estas dos partes.
2.1 El cliente paga la factura
El cliente encapsula y envía su información necesaria al servidor cada vez que lo solicita, y el servidor puede consultarla y procesarla. Como se muestra abajo
2.2 El servidor paga
la factura Después de que el cliente hace la primera solicitud, el servidor comienza a hacer registros, y luego el cliente solo necesita enviar la información más básica y mínima en solicitudes posteriores, y no necesita demasiada información. Como se muestra abajo
3. Esquema de implementación técnica
3.1 Esquema de cookies
La cookie siempre se guarda en el cliente. Según la ubicación de almacenamiento en el cliente, se puede dividir en cookies de memoria y cookies de disco duro.
La cookie de memoria es mantenida por el navegador y almacenada en la memoria, y desaparece después de que se cierra el navegador, y su tiempo de existencia es corto. Las cookies de disco duro se almacenan en el disco duro y tienen un tiempo de caducidad. A menos que el usuario borre manualmente o se alcance el tiempo de caducidad, la cookie del disco duro no se eliminará y su tiempo de existencia es a largo plazo.
3.1.1 Definición y función de la cookie
La cookie HTTP (también denominada cookie web o cookie del navegador) es una pequeña porción de datos enviada por el servidor al navegador del usuario y almacenada localmente. Será transportado y enviado al servidor la próxima vez que el navegador haga una solicitud al mismo servidor.
Por lo general, las cookies se utilizan para decirle al servidor si dos solicitudes provienen del mismo navegador, como mantener el estado de inicio de sesión del usuario. Las cookies permiten registrar información de estado estable basada en el protocolo HTTP sin estado.
Las cookies se utilizan principalmente de las siguientes tres maneras:
Administración del estado de la sesión (como el estado de inicio de sesión del usuario, el carrito de compras y otra información que debe registrarse)
Configuración de personalización (como configuraciones definidas por el usuario, temas, etc.)
Seguimiento del comportamiento del navegador (como seguimiento y análisis del comportamiento del usuario, etc.) )
3.1.2 Creación de cookies del lado del servidor
Cuando el servidor recibe la solicitud HTTP, el servidor puede agregar una opción Set-Cookie en el encabezado de respuesta.
El navegador generalmente guarda la cookie después de recibir la respuesta y luego envía la información de la cookie al servidor a través del encabezado de solicitud de cookie en cada solicitud al servidor. Además, el tiempo de caducidad de la cookie, el dominio, la ruta, el período de validez y los sitios aplicables se pueden especificar según sea necesario.
3.1.3 Interacción de cookies bajo estructura B/S
El servidor utiliza el encabezado de respuesta Set-Cookie para enviar información de cookies al navegador del usuario. Establezca cierta información necesaria en el texto de la cookie, como el nombre de usuario, la contraseña y otra información relacionada.
Una operación simple de cookies del navegador es la siguiente
Set-Cookie:
RememberMe=deleteMe; Path=/yc-home; Max-Age=0; Expires=Thu, 20-Jul-2023 08:04:21 GMT
Cada vez que el cliente inicia una nueva solicitud al servidor, el navegador La información de la Cookie previamente guardada se enviará al servidor a través del encabezado de solicitud de Cookie.
Cookie:
Hm_lvt_085e0fa100dbc0e0e42931c16bf3e9e6=1687672868, 1687845814, 1688968992, 1689921934;
Veamos cómo es la información que se lleva en el encabezado del sitio web en nuestro proyecto
3.1.4 Problemas con las cookies
Las cookies se utilizan a menudo para marcar usuarios o sesiones autorizadas. Una vez que los navegadores las emiten, pueden ser secuestradas y utilizadas para actividades ilegales, lo que puede provocar ataques a las sesiones de los usuarios autorizados, por lo que existen problemas de seguridad. .
Otra situación es la falsificación de solicitud entre sitios CSRF. En pocas palabras, por ejemplo, cuando inicia sesión en el sitio web de un banco, inicia sesión en un sitio web de phishing. Cuando realiza ciertas operaciones en el sitio web de phishing, puede obtener información de cookies. relacionados con el sitio web del banco y enviarlo al sitio web del banco. Iniciar transferencias y otras actividades ilegales.
La falsificación de solicitudes en sitios cruzados (en inglés: Cross-site request forgery), también conocida como ataque con un clic o conducción de sesiones, generalmente abreviado como CSRF o XSRF, es un método que obliga a los usuarios a ejecutar involuntariamente el método de ataque de la operación. A diferencia del cross-site scripting (XSS), que explota la confianza del usuario en un sitio web determinado, CSRF explota la confianza del sitio web en el navegador web del usuario.
El ataque de solicitud entre sitios, en pocas palabras, es que el atacante utiliza algunos medios técnicos para engañar al navegador del usuario para que visite un sitio web que ha autenticado y realice algunas operaciones (como enviar correos electrónicos, enviar mensajes e incluso operaciones de propiedad como transferir dinero y la compra de bienes) ).
Dado que el navegador ha sido autenticado, el sitio web visitado se considerará como una operación y ejecución real del usuario. Esto aprovecha una laguna en la autenticación de usuarios en la Web: la autenticación simple solo puede garantizar que una solicitud provenga del navegador de un usuario, pero no que la solicitud en sí sea voluntaria.
Sin embargo, hay muchas soluciones a esta situación, especialmente para los sitios financieros como los bancos, cualquier operación confidencial de los usuarios debe confirmarse y las cookies con información confidencial solo pueden tener un ciclo de vida corto.
Al mismo tiempo, las cookies tienen una capacidad y cantidad limitadas, y se debe enviar mucha información cada vez, lo que genera un consumo de tráfico adicional y un comportamiento complejo. Las cookies no pueden cumplir con los requisitos.
Los problemas anteriores son solo problemas cuando la Cookie se usa para realizar un estado interactivo, pero no el problema de la Cookie en sí.
3.2 Esquema de sesión
3.2.1 Concepto de mecanismo de Sesión
Si la Cookie es el comportamiento del cliente, entonces la Sesión es el comportamiento del servidor.
Después de que el mecanismo de cookies interactúe inicialmente con el servidor, la información requerida para mantener el estado se almacenará en el archivo de cookies local del cliente y luego se leerá y enviará directamente al servidor para la interacción.
La sesión representa una sesión entre el servidor y el navegador, y está completamente controlada por el servidor para implementar funciones como la asignación de ID, el almacenamiento de información de la sesión y la recuperación de la sesión.
El mecanismo de sesión almacena toda la información de actividad del usuario, información de contexto, información de inicio de sesión, etc. en el servidor, y solo genera una identificación única para enviar al cliente. Las interacciones posteriores no tendrán una transmisión repetida de información del usuario y serán reemplazadas por una ID único Llamémoslo SessionID por ahora. Como se muestra abajo
3.2.2 Proceso de interacción de sesión
Cuando el cliente solicita el objeto de sesión por primera vez, el servidor creará una sesión para el cliente y calculará una ID de sesión a través de un algoritmo especial para identificar el objeto de sesión; cuando el navegador solicite otros recursos la próxima vez, el navegador
colocará el sessionID en el encabezado de la solicitud, y el servidor analizará el sessionID después de recibir la solicitud, y el servidor encontrará la sesión con el id para determinar la identidad del solicitante y alguna información de contexto.
3.2.3 Implementación de Sesión
En primer lugar, está claro que no existe una relación directa entre Sesión y Cookie. Se puede considerar que la cookie es solo una forma de implementar el mecanismo de sesión, y se pueden usar otros métodos sin la cookie.
La relación entre Session y Cookie es como la relación entre horas extras y pago de horas extras, parece que la relación es muy estrecha, pero en realidad no tiene nada que ver.
Hay dos formas principales de implementar Session: Cookie y reescritura de URL, y Cookie es la forma preferida. Debido a que varios navegadores modernos habilitan la función de cookies de forma predeterminada, pero cada navegador también tiene una configuración que permite invalidar las cookies, por lo que se necesita un neumático de respaldo para el mecanismo de sesión.
La técnica de agregar el número de identificación de la sesión como parámetro a la dirección URL del hipervínculo se denomina reescritura de URL.
como la URL original
http://localhost:9301/zbt/getInsureOrderInfo?outBizNo=1
URL después de reescribir
http://localhost:9301/zbt/getInsureOrderInfo?sessionid=A8A5647A2E2BOE169B5391D252EDA65C&outBizNo=1
3.2.4 Problemas con la sesión
Dado que la información de la sesión se almacena en el servidor, si hay una gran cantidad de usuarios, los recursos del servidor ocupados por la información de la sesión se reducirá No se puede ignorar.
Para sitios web grandes, debe ser una configuración de servidor agrupado y distribuido. Si la información de la sesión se almacena localmente, debido al equilibrio de carga, la solicitud original a la máquina A y la información de la sesión se almacenan, la siguiente solicitud puede llegar a la máquina B y no hay información de la sesión en la máquina B en este momento.
En este caso, la creación repetida en la máquina B causará desperdicio, o introducirá una solución de clúster de sesión de alta disponibilidad, introducirá un agente de sesión para compartir información o implementará hash personalizado en el clúster A, que en realidad es un poco complicado.
3.3 Esquema de token
3.3.1 Breve descripción de Token Token
significa token, que es generado por el servidor y emitido al cliente, y es un medio de verificación de identidad efectivo en el tiempo.
Token evita el problema de almacenamiento masivo de información causado por el mecanismo de Sesión, y también evita algunos problemas de seguridad del mecanismo de Cookie.Es ampliamente utilizado en escenarios modernos de Internet móvil, acceso entre dominios y otros escenarios.
3.3.2 Proceso de interacción simple de fichas
El cliente envía la cuenta y la contraseña del usuario al servidor;
el servidor la verifica y, si se pasa, genera un valor de token y lo devuelve al cliente como un token de identidad de interacción de solicitud posterior;
después de que el cliente recibe el valor del token devuelto por el servidor , puede guardarlo localmente y llevar el token cada vez que solicite el servidor en el futuro, y enviarlo al servidor para la verificación de identidad; después de
recibir la solicitud, el servidor analiza la información clave y luego genera de acuerdo con la misma algoritmo de cifrado, clave y parámetros de usuario El signo se compara con el signo del cliente, y si son consistentes, se pasa el servicio; de lo contrario, se rechaza el servicio; después de pasar la verificación, el servidor puede obtener la información de usuario correspondiente de
acuerdo al uid en el token y responder a la solicitud comercial.
3.3.3 Idea de diseño de Token
Tomando JSON Web Token (JWT) como ejemplo, Token consta principalmente de tres partes:
Información del encabezado del encabezado: registra la información del algoritmo de encriptación utilizada;
Información de la carga útil: registra la información del usuario y el tiempo de vencimiento, etc.;
Información de la firma de la firma: se genera de acuerdo con el algoritmo de encriptación en el encabezado, la información del usuario en la carga útil y la clave clave Una base importante para que el servidor verifique el servidor.
La información del encabezado y la carga útil no está encriptada, solo la codificación base64 general. Después de recibir el token, el servidor elimina el encabezado y la carga útil para obtener información como el algoritmo, el usuario y el tiempo de vencimiento, y luego genera una señal de acuerdo con su propia clave de cifrado y la compara con la señal enviada por el cliente para determinar la identidad del cliente legalidad.
De esta manera, el tiempo de cifrado y descifrado de la CPU se intercambia por espacio de almacenamiento. Al mismo tiempo, la importancia de la clave del servidor es obvia. Una vez que se filtre todo el mecanismo, colapsará. En este momento, se debe considerar HTTPS. .
3.3.4 Funciones de la solución de token
El token se puede compartir entre sitios para lograr un inicio de sesión único;
el mecanismo del token no requiere mucho espacio de almacenamiento. El token contiene información del usuario y solo necesita almacenar información de estado en el lado del cliente, que es muy escalable para el servidor; la
seguridad del mecanismo del token depende de la seguridad del algoritmo y la clave de cifrado del lado del servidor;
el mecanismo del token no es una panacea
En resumen,
Cookie, Sesión y Token son productos de diferentes etapas en el desarrollo de aplicaciones de red. Los tres tienen sus propias ventajas y desventajas, y no existe una relación antagónica obvia. Por el contrario, a menudo coexisten, lo que A menudo se confunde la razón.
Las cookies se centran en el almacenamiento de información, principalmente el comportamiento del cliente. La sesión y el token se centran en la autenticación, principalmente en el comportamiento del lado del servidor. Las tres soluciones aún están vivas en muchos escenarios, y solo al comprender los escenarios podemos elegir la solución adecuada.
Artículo
—————————————————
Declaración de derechos de autor: este artículo es un artículo original del blogger de CSDN "LQzhang_11" y sigue el acuerdo de derechos de autor de CC 4.0 BY-SA. Para reimprimirlo, adjunte el enlace de la fuente original y la declaración de este artículo.
Enlace original: https://blog.csdn.net/LQzhang_11/article/details/131853314