javascript seguro. -parte 1

En diciembre del año pasado decidí dejar de trabajar en mi antiguo empleo para convertirme en freelance. Debo decir que la verdad ha sido un poco difícil ya que aun que tengo la experiencia que muchos que agarran trabajos no tienen, me hace falta el portafolio que respalde esa experiencia. Sin embargo, no me puedo quejar; he obtenido algunos proyectos que me han permitido salir adelante y en el camino he ganado a más de un amigo. Una de las cosas que no me faltan cuando envío un presupuesto, es mencionar que soy un desarrollador enfocado en optimización y seguridad por lo que he decidido escribir un poco sobre seguridad aquí en el blog.

Para empezar con esta serie de artículos voy a tratar uno de los temas más comunes en el ataque a la seguridad, o falta de esta, de un sitio. Para ello voy a usar un ejemplo. Supongamos que el sitio programadoresverdes.com ha sido desarrollado por unos chicos que se han creído que por saber unas cuantas etiquetas de html y como encontrar trucos cool de javascript en la web ya son programadores web. Como estos chicos quieren demostrar sus habilidades de programadores han puesto un toque ‘personal’ a su sitio de modo que cuando ingresas a programadoresverdes.com te sale una ventana pidiendo que introduzcas tu nombre. Tu introduces tu nombre y le das a aceptar. El sitio entonces, ‘se aprende’ tu nombre y cada que cambias de pagina en la cabecera te aparece un mensajito que dice ‘Gracias por visitar el sitio nombre‘, donde nombre es tu nombre. Para hacer esto, nuestros amigos se valen de técnicas poco seguras. Para pasar el nombre de una página a otra usan el variables que pasan por get, las cuales después toman en la siguiente página para poder imprimirlas en la cabecera del sitio. Cada enlace se ve de esta forma:

http://www.programadoresverdes.com/portafolio.html?nombre=mrB

Por supuesto que esto llama nuestra atención desde un inicio y empezamos a especular sobre lo que podría pasar si le movemos por aquí y por aya. Lo primero que hacemos es modificar el valor de nombre y ver que pasa.

http://www.programadoresverdes.com/portafolio.html?nombre=srB

Accedemos a esa dirección diréctamente y vemos que efectivamente en lugar de imprimirse mrB como nuestro nombre, se imprime srB. Ahora empezamos a probar un poco más y volvemos a editar la url.

http://www.programadoresverdes.com/portafolio.html?nombre=<script>alert(‘XSS&#8217;);</script>

Navegamos hacia esa dirección y Oh YES!!!, obtenemos una alerta que dice XSS. Pero, que fue lo que pasó?

Para ver un poco el fallo de nuestros amigos veamos un poco como es que este sitio hipotético ha sido montado.

Primero, al cargar la primera página nos sale un prompt, desde el cual, por cierto, podemos hacer el ataque. Este prompt nos pregunta por nuestro nombre para después poder almacenarlo en una variable y agregarlo a cada enlace. Cuando navegamos a otra página dentro de programadoresverdes.com, esa otra página recoge la variable nombre de url y la inyecta en el html tal como viene. Para eso pueden usar un simple document.write

var obtNombre = function(){
//code para obtener el nombre de la url
//….
return nombre;
}

document.write(obtNombre());

Como puedes ver, el código empleado simplemente recoge la variable nombre de la url, lo cual puede hacerse de diferentes maneras, y lo inserta tal como viene en el documento. Aquí es donde podemos ver el gran error de los chicos. Como no hay nada que valide o que haga un chequeo del dato que se está recibiendo, podemos simplemente pasar cualquier cosa y el código la va a inyectar en la página, es por eso que nuestro alert() funciona ya que al ser inyectado, es interpretado como otra pieza de código más.

Ahora, cual es realmente el problema, preguntarán algunos. Que daño puede hacer una alerta? La verdad es que no mucho. Sin embargo, el problema radica en el hecho de que existe la posibilidad de inyectar código dentro de la página. Algo que muchas veces pensamos es, por que quería yo modificar una url para inyectar code en un sitio que estoy visitando? La verdad es que no se por que querrías hacer eso. Lo que sí se, es que no es lo que chico que sombrero negro haría. Nuestro amigo (de verdad???) de sombrero negro haría es por ejemplo mandar un email en el que de una u otra forma intentara convencerte que visitaras el sitio programadoresverdes.com. El enlace por supuesto que ha sido modificado de modo que inyecte código dentro del sitio para atacar a la persona que está visitando el sitio, es decir, la persona que recibió el mail y que siguió el enlace. El código inyectado puede hacer infinidad de cosas dependiendo el sitio que está siendo usado para hacer el ataque.

Imagina que en lugar de ser programadoresverdes.com el sitio que tiene la vulnerabilidad, es banco.com. Entonces el panorama se torna completamente diferente ya que en banco.com el atacante puede hacer mucho daño. Otro caso puede ser que tu servicio de correo fuera el vulnerable, entonces el atacante podría robar desde tu correo hasta tus cookies para poder después entrar al sitio como si fueras tu.

A este tipo de ataque se le conoce como Corss Site Scripting, y dejar vulnerabilidades abiertas para este tipo de ataques es muy fácil, especialmente si no se sabe lo que se hace al desarrollar un sitio web. Los medios más comunes para este tipo de ataque son campos de texto o áreas de texto ya que muchas veces esto sirven para postear mensajes o comentarios. Si la información introducida por el usuario nos propiamente chequeada y validada, lo más probable es que se sea víctima de este tipo de ataques. Por ejemplo, alguien puede dejar un comentario como este:

Hola, está bueno el artículo. <script>//algo de js malicioso…</script>

Ese comentario se guarda en una base de datos y cuando alguien más visita la página, se cargan los comentarios y entre ellos el comentario que lleva el ataque. De esta manera, nuestro amigo de sombrero negro ha logrado atacar a alguien más.

En un futuro artículo estaré hablando más sobre ataques y como defenderse de ellos. Por ahora los dejo con la regla de oro en seguridad: Todo contenido provisto por el usuario debe ser propiamente chequeado y validado. Como dicen en inglés, trust the user, but not the input.

2 thoughts on “javascript seguro. -parte 1

  1. hola buzu, es buen articulo. me preguntaba si el hacias podcast. ser de interesting que compartas tu conocimientos en un podcast. aunque creo que tu tiempo no lo deje be anyway muchas gracias por dar a conocer tus conocimientos.

    Atte. Alberto

    • Hola, no no tengo podcast pero sería interesante. Hace tiempo planeábamos algo con mi hermano, pero nunca se concretó. A ver si en el futuro se puede. De hecho tengo unas ideas, pero me falta tiempo y recursos (camara y cosas de esas)

      Gusto verte por acá!

Comments are closed.