Skip to content

Latest commit

 

History

History
92 lines (68 loc) · 4.75 KB

File metadata and controls

92 lines (68 loc) · 4.75 KB

6.4 Prevenir el hijacking de sesión

El hijacking de sesión es una amenaza conocida y seria de seguridad. Los clientes usan el identificador de sesión para validarse y otros propósitos cuando se comunican con el servidor. Desafortunadamente, paquetes deterceros pueden capturar estas comunicaciones y encontrar el identificador de sesión del cliente.

En esta sección vamos a mostrar como hijackear una sesión con propósitos educacionales.

El proceso de hijacking de sesión

El siguiente código es un contador para la variable count:

	func count(w http.ResponseWriter, r *http.Request) {
	    sess := globalSessions.SessionStart(w, r)
	    ct := sess.Get("countnum")
	    if ct == nil {
	        sess.Set("countnum", 1)
	    } else {
	        sess.Set("countnum", (ct.(int) + 1))
	    }
	    t, _ := template.ParseFiles("count.gtpl")
	    w.Header().Set("Content-Type", "text/html")
	    t.Execute(w, sess.Get("countnum"))
	}

El contenido de count.gtpl es el siguiente:

	Hi. Now count:{{.}}

Podemos ver el siguiente contenido en el navegador:

Figur 6.4 conteo en el navegador.

Manté refrescando hasta que el número sea 6, entonces abre el manejador de cookies (Uso chrome aquí). Podrás ver la siguiente información:

Figura 6.5 cookies guardadas en el navegador.

Este es un paso muy importante: abre otro navegador (Uso firefox aquí), copia la URL en el nuevo navegador, abre el simulador de cookies para crear una nueva cookie y escribe exactamente el mismo valor que la cookie que vimos en el primer navegador.

Figura 6.6 Simular una cookie.

Refresca la página y verás lo siguiente:

Figura 6.7 hijacking de la sesión exitoso.

Aquí podemos que ver que podemos hijackear las sesiones entre diferentes navegadores y las acciones relizadas en uno pueden afectar el estado de la página del otro navegador. Porque HTTP es sin estado, no hay manera de saber si el identificador de sesión de firefox fue simulado, y chrome tampoco puede saber que su sesión fue hijackeada.

prevenir el hijacking de sesión

cookie solamente y token

A través de este simple ejemplo de hijacking de sesión, puedes ver que es muy peligroso porque permise a los atacantes hacer lo que quieran. ¿Cómo podemos prevenir el hijacking de sesión?

El primer paso es únicamente definir el identificador en las cookies, en vez de las URLs. También asignr la propiedad httponly cookie a verdadero. Esto restringe a los scripts del lado del cliente ganen acceso al identificar de sesión. Usando estas técnicas las cookie sno pueden ser accesadas por XSS y no será tan fácil como se demostró robar un identificador de sesión del manejador de cookies.

El segundo paso es agregar un token a cada petición. Similar a la manera en la que lidiamos con la repetición de subida de formularios en una sección anterior. Agregamos un campo oculto que contenga un token. Cuando una petición es enviada al servidor, podemos verificar el token para saber si es único.

	h := md5.New()
	salt:="astaxie%^7&8888"
	io.WriteString(h,salt+time.Now().String())
	token:=fmt.Sprintf("%x",h.Sum(nil))
	if r.Form["token"]!=token{
	    // ask to log in
	}
	sess.Set("token",token)

Tiempo de agotamiento del identificador de sesión

Otra solución es crear un tiempo para cada sesión, y reemplazar los identificadors de sesión con algunos nuevos. Esto puede prevenir las sesiones de ser hijackeadas bajo ciertas circunstancias, como cuando el hijacking se hace tarde.

	createtime := sess.Get("createtime")
	if createtime == nil {
	    sess.Set("createtime", time.Now().Unix())
	} else if (createtime.(int64) + 60) < (time.Now().Unix()) {
	    globalSessions.SessionDestroy(w, r)
	    sess = globalSessions.SessionStart(w, r)
	}

Cuando definimos el valor a guardar el tiempo de creación, si no ha expirado (60 segundos aquí). Este paso puede muy a menudo fristrar intentos de ataques de hijacking.

Al combinar las dos técnias de arriba podemos ser capaces de prevenir la mayoría de ataques de hijacking de que sean exitosos. Por otra parte, los identificadores de sesión que son reestablecidos frecuentemente resultan en que el atacante siempre obtiene identificadores de sesión expirados. También definiendo la configuración httponly en cookies y asegurarnos que la sesión solo pueda ser pasada por medio de cookies, todos los ataques por URL pueden ser mitigados. Finalmente definimos MaxAge=0 en nuestras cookies, lo que significa que el identificador de sesión no será almacenado en el historial del navegador.

Enlaces