Cookies - Vectores de ataque
Es interesante este tema y creo que con esto hacemos el trio perfecto, porque ya hablamos de que son las cookies en detalle para los formados. Tambien educamos sobre que podemos hacer para evitar problemas con las cookies.
Ahora quedaria ver como podria un cuaker aprovecharse de las cookies para utilizarlas en contra de nosotros. Pero antes que nada veamos como podemos ver las cookies que estan ejecutandose en nuestor navegador:
Si ahora vemos la pagina mediante el inspector de codigo 😱, que locura de pedidos!!
Y esta imagen es solo una parte, de TODAS las que llegaron con la solicitud. La mayoria bloqueadas o con riesgo detectado. Pero algunas si que pasaron de todas formas.
Si ahora ejecutamos un document.cookie podemos ver algunas de ellas, cada separacion con ; corresponde a una cookie.
De estas cookies tenemos varias funcionalidades, destacamos:
- eptz=AR: ubicación, con “AR” se refiere a Argentina.
- uid_ns=CgEI+mYm5c6I1AAJEj/GAg==: Esta codificada pero aparenta ser el ID que nos asigna como usuario.
- pbsVisit=first: Indica que es la primera visita.
- s_vncd=1713841199812%26vn%3D1: el seguimiento como usuario.
- didomi_token=…, euconsent-v2=…: Asi se cubre del cumplimiento de regulaciones de privacidad y consentimiento.
- arc-geo=…: geolocalización.
Bueno ya te mostre como se ven en real! estas cookies, ahora vamos a ver como pueden usarlas, para analizarnos y vulnerarnos.
El secuestro de cookies es, de hecho, una técnica utilizada por atacantes para robar información de sesión de los usuarios. En este tipo de ataque, el atacante se apodera de la cookie válida de un usuario. Esta cookie se utiliza para autenticar al usuario en un sitio web sin requerir que ingrese sus credenciales nuevamente. Una vez que el atacante tiene acceso a la cookie, puede hacerse pasar por el usuario legítimo y acceder a su cuenta sin necesidad de proporcionar credenciales.
Ahora imaginemos por un momento que somos los malos y creamos un codigo JavaScript y lo inyectamos en una pagina web o lo enviamos en un correo con enlace a un sitio comprometido.
El codigo seria algo tan sencillo como var roboTuCookie = document.cookie; asi de facil recuperamos todas las cookies del navegador del usuario comprometido.
SameSite.
Si www.misitioweb.com tiene un enlace <a href="www.otrositioweb.com">...</a> va a enviar la o las cookies si SameSite no esta seteada o esta seteada en None o Lax. Si "otrositioweb" esta comprometido, es posible obtener las cookies sin mayores problemas, incluso reenviarlas modificadas.
Si www.misitioweb.com se precarga mediante <link rel="prerender" href=".."/> entonces se ejecuta una solicitud anticipada, si SameSite=None entonces, la o las cookies se envian en esta solicitud. En cambio si SameSite=Lax no se envia la cookie.
Si www.misitioweb.com envia una solicitud AJAX mediante $.get("...") por ejemplo, y se incluye la cookie en esa solicitud, la configuracion SameSite=None deja que se envie la cookie a "otrositioweb".
En el caso de no esta seteado SameSite, atento a la extension RFC6265bis los nevegadores deberian tomar por defecto, un comportamiento determinado, por ejemplo si SameSite no se especifica deberia ser por defecto SameSite=Lax y si SameSite=None deberia tambien ir acompañado de Secure.
CSRF. (cross site request forgery)
Como pudimos ver las cookies se adjuntan a casi cualquier solicitud y desconociendo incluso quien inicia la solicitud.
Para profundizarlo mas, supongamos que www.otrositioweb.com esta vulnerado y al dirigirnos hacia el, porque ahi hay una imagen que usa www.misitioweb.com lo que va a ocurrir cuando des click en la imagen o en el enlace de la imagen. Es que se van a enviar nuestras cookies a "otrositioweb" y de esta manera este sitio vulnerado, reenvie nuestra informacion.
Y que puede pasar? Facil! que nos eliminen publicaciones de nuestra pagina, que nos pongan un cartelito de que fuimos hackeados, etc, etc, etc. O lo que ya mencionamos con anterioridad.
Configurar bien SameSite, es un metodo eficaz contra este tipo de ataque. Podemos hacer algo mas? Si, bloqueando las cookies, a costa de una menor experiencia de navegacion en las paginas web. Y como se bloquean bueno en las imagenes mas arriba te mostre como se ve cuando se bloquean las cookies. Hay varios metodos para esto, desde la configuracion del navegador hasta el uso de addons (en el caso de mozilla).
POST y GET
Otro vector de ataque son los metodos POST y GET con las cookies, cuando necesitamos modificar un usuario o contraseña o algun otro tipo de dato personal que modifiquemos en un formulario, es siempre mas seguro usar POST antes que GET.
Esto se debe a que GET deja en el encabezado de la solicitud, en los propios registros del servidor y en el historial del navegador. Los parametros que corresponden a nuestros datos.
Si utilizamos GET en vez de POST cuando modificamos parametros de usuario, contraseña, etc. Nos arriesgamos a que cualquiera con el conocimiento, pueda hacer uso de CSRF en un sitio web que no sea de su propiedad.
Pero como?
Si logra cargar en el sitio algo tan simple como una imagen etiquetada o mas facil hacer un comentario con esta carga util, va a poder a traves de GET abusar de CSRF.
Bueno hay muchisimo mas para seguir hablando y prometo hacer algo de codigo al respecto pero ya es suficiente por el momento. Saludos!!