Explotación de vulnerabilidad de fijación de sesión
El protocolo HTTP fue diseñado para cumplir unos requisitos muy limitados, sin tener en cuenta muchas de las necesidades de la actualidad; por ejemplo, el protocolo no es capaz inicialmente de proporcionar o restringir visibilidad sobre sus recursos dependiendo de qué usuario los solicite.
Cuando un usuario accede a un servidor web éste realiza el saludo a tres bandas, solicita un recurso al servidor mediante HTTP, el servidor le devuelve el recurso solicitado y se cierra la conexión, por lo que si pinchamos en un enlace de la web, el servidor lo vería como una petición nueva y desconocerá que somos el mismo usuario. Por ello fue necesaria la creación del concepto de sesión, de tal forma que el servidor web sepa que somos el mismo usuario y en función de la sesión, proporcione visibilidad sobre unos recursos y con un determinado formato.
Esta sesión es un valor que debe ser aleatorio, difícil de adivinar y con una caducidad temporal. Normalmente la sesión irá como parámetro de la URL, en las cookies o en métodos POST; la sesión será generada y proporcionada por el servidor, mientras que el cliente web tendrá la obligación de añadir la sesión en sus peticiones para que el servidor tenga constancia de quién está realizando la solicitud. Por ejemplo, imagínese que usted se autentica en su webmail de tal forma que se le permita leer su correo electrónico y por algún tipo de vulnerabilidad, por ejemplo un XSS, alguien tiene acceso a su sesión. Este atacante podrá tener las mismas funcionalidades en el recurso web que tiene usted. Su usuario y contraseña solo le sirvieron para indicarle al servidor Web que conceda a su sesión visibilidad sobre su correo.
Por ello existen multitud de posibles vectores de ataque para que un potencial atacante intente obtener su sesión y, por tanto, sea capaz de suplantar a su usuario.
Contenido completo en fuente original Security Art Works I, II y III
Cuando un usuario accede a un servidor web éste realiza el saludo a tres bandas, solicita un recurso al servidor mediante HTTP, el servidor le devuelve el recurso solicitado y se cierra la conexión, por lo que si pinchamos en un enlace de la web, el servidor lo vería como una petición nueva y desconocerá que somos el mismo usuario. Por ello fue necesaria la creación del concepto de sesión, de tal forma que el servidor web sepa que somos el mismo usuario y en función de la sesión, proporcione visibilidad sobre unos recursos y con un determinado formato.
Esta sesión es un valor que debe ser aleatorio, difícil de adivinar y con una caducidad temporal. Normalmente la sesión irá como parámetro de la URL, en las cookies o en métodos POST; la sesión será generada y proporcionada por el servidor, mientras que el cliente web tendrá la obligación de añadir la sesión en sus peticiones para que el servidor tenga constancia de quién está realizando la solicitud. Por ejemplo, imagínese que usted se autentica en su webmail de tal forma que se le permita leer su correo electrónico y por algún tipo de vulnerabilidad, por ejemplo un XSS, alguien tiene acceso a su sesión. Este atacante podrá tener las mismas funcionalidades en el recurso web que tiene usted. Su usuario y contraseña solo le sirvieron para indicarle al servidor Web que conceda a su sesión visibilidad sobre su correo.
Por ello existen multitud de posibles vectores de ataque para que un potencial atacante intente obtener su sesión y, por tanto, sea capaz de suplantar a su usuario.
Contenido completo en fuente original Security Art Works I, II y III
0 Comments:
Publicar un comentario
Gracias por dejar un comentario en Segu-Info.
Gracias por comentar!