En este artículo aprenderás sobre:
HTTP es un potocolo sin estado, esto quiere decir que desde la petición hasta la respuesta no hay un registro del estado del mensaje. Si te logueas en una petición, esto se olvida en otras peticiones.
Esto quiere decir que las webpages no tienen memoria. Un usuario yendo de página en página va a ser tratado por el webpage como un nuevo visitante. Una de las primeras soluciones para esto fue crear una ‘session cookie’, que habilita al webpage a hacer un seguimiento del movimiento de un usuario de una página a otra. Estas sesion cookies son diccionarios con información del usuario y sus movimientos el cual se crea tanto en la base de datos del lado del servidor como en el navegador y son asignadas a un usuario mediante un session Id.
Las cookies le permiten pasar por muchas páginas de un sitio de forma sencilla sin tener que autenticar o reprocesar cada nueva área que visita.
El ejemplo más común de esta funcionalidad es el carrito de compra en cualquier e-commerce. Cuando visita una página de un catálogo y selecciona algunos artículos, la session cookie recuerda su selección para cuando esté listo para pagar. Sin las session cookies, si hace click en pagar, la nueva página no reconoce sus actividades pasadas y su carrito siempre estará vacío.
<h1>CSRF</h1>CSRF o Cross Site Request Forgery es una vulnerabilidad de seguridad web. Permite a los atacantes hacer que los usuarios ejecuten acciones que no tienen intención de hacer. Por ejemplo cambiarle la dirección de correo electrónico de la cuenta del ususario.
Para que un ataque de este tipo sea posible, es necesario que el sitio cuente con tres condiciones.
Una acción relevante: Que exista una acción en la aplicación que el atacante tenga razones para provocar, como un cambio de email o contraseña de la cuenta.
Manejo de sesiones basado en cookies: Que no exista otro mecanisco para rastrear usuarios sino que la aplicación solo identifique al usuario basado en las cookies de sesión.
Sin parámetros de solicitud impredesibles: Que las solicitudes que realizan la acción no contengan ningún parámetro cuyo el atacante no pueda determinar o adivinar. Por ejemplo, para que un usuario cambie su contraseña, no necesite conocer el valor de la contraseña existente.
Para manejar este ataque, y para resolver problemas de escalabilidad de la aplicación lo cual hablaremos más adelante, los sitios web modernos utilizan tokens en vez de cookies de sesiones para verificar a los usuarios.
<h1>Autenticación basada en Tokens</h1>La autenticación a través de sesiones obliga al servidor a crear un registro en una base de datos con información del usuario cada vez que este se autentique, esto supone una pérdida de escalabilidad de la aplicación. Además tener el backend que encargarse de esto, si se quiere por ejemplo desarrollar un aplicación móvil aparte de la aplicación web, se necesitaría otro backend diferente.
Por ello una de las nuevas tendencias es la autenticación por medio de tokens y que el backend sea una API RESTful sin información de estado, stateless. El funcionamiento es el siguiente.
Un usuario se autentica en la aplicación, bien con un par de usuario y contraseña, o a través de un proveerdor como Facebook o Google por ejemplo. A partir de entonces, cada petición HTTP que haga el usuario va acompañada de un token en el header. Este token no es más que una firma cifrada que permite a la aplicación identificar al usuario. Este token no se almacena en el servidor, si no en el lado del cliente, por ello no hay información de estado y la aplicación se vuelve totalmente escalable, permitiendo así el uso de la misma API para diferentes aplicaciones (Web, Mobile, Android, IOS…).
Hoy en día el estándar que se utiliza es Json web tokens (JWT). Un JWT consiste en tres partes, el header, payload and signature.
###HEADER###
{
"alg": "HS256",
"typ": "JWT"
}
###PAYLOAD###
{
"sub": "1234567890",
"name": "John Doe",
"iat": 1516239022
}
###SIGNATURE###
{
HMACSHA256(base64UrlEncode(header) + "." +
base64UrlEncode(payload),
secret)
}
Al JWT se le asigna un algoritmo de codificación, por ejemplo HMACSHA256 y se verá así.
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkFkbyBLdWtpYyIsImFkbWluIjp0cnVlLCJpYXQiOjE0Estos tokens se incluyen en cada petición al servidor para autenticar. El servidor decodificará el token y si es válido enviará la respuesta. Cuando un usuario se desloguea, el token se destruye en el lado del cliente sin interactuar con el servidor. Esto provee cierta seguridad.
Es importante señalar que los sitios web siguen utilizando cookies para tener control del estado de los usuario, solo que las utilizan cada vez menos para verificar su autenticidad.
Me pone muy contento que hayas leído hasya aquí. Si tienes algún aporte por favor comenta que estaré muy agradecido de leerlo!
entonces como se manejaría el estado si no uso cookies hay alguna forma de hacerlo con jwt y algo mas ?
Estoy teniendo problemas de autenticacion en webmail de cpanel. Error 401, y buscando en la red llegue hasta aqui. Segun entendi esto quiere decir q cpanel es mas seguro por este token en la URL. Logre resolver duplicando pestañas o abriendo desde menu secundario/abrir en pestaña nueva, y asi la URL nueva ya lleva el token y no sale el error 401. Pero Gmail y demas monstruos, q uno todavia abre a diestra y siniestra como sea y nunca sale este error:: van a por este camino?. Esto de las cookies segun entiendo esta a punto de desaparecer. Y si se amaña alguna manera de convertir token en cookie y q esta cree URLs con el token para q no salte el 401?. O lo q acabo de decir es una barrabasada?