Como funciona el ataque Aplicativo en Cross-Site-Scripting.
Ataque al Aplicativo
Este tipo de ataque por medio del Cross-Site-Scripting es menos frecuente que el ataque a los usuarios, pero aun así existen personas que se deleitan fastidiando un sitio web por puro placer y consiste en poder almacenar scripts que se reflejen en el sitio para causar alguna alteración o eliminación del mismo, veremos algunos ejemplos comunes pero como en el tipo de ataque anterior existen agresiones mas peligrosas y dañinas que las que veremos aca.
Tomaremos como referencia un blog ya que sitios como blogs, foros y libros de visita, son los que mas fácilmente permiten este tipo de ataques, debido que en muchas ocasiones permiten el formateo de nuestro texto con etiquetas HTML y no validan correctamente el tipo de inserción que estamos haciendo.
Ahora comencemos de lo simple:
Hagamos un post como este:
<script>alert("hola");</script>
Al cargar la página donde se refleja nuestro post aparecerá una ventanita como esta.
Bien parece algo chistoso, un pequeño saludo de entrada, pero ahora quizás a ese hola podemos agregarle algo más:
<script>while(1)alert("hola");</script>
Al cargar la pagina nos aparecerá la misma ventanita de saludo pero esta vez al darle click volverá a aparecer, floodeando nuestro navegador, ya que siempre que demos click en el botón aceptar del cuadro de dialogo nos seguirá apareciendo la misma ventanita, quitándonos toda posibilidad de interactuar con el sitio ya que la única forma de cerrar este cuadro de dialogo es cerrando la web que lo ejecuta, como vemos ya dejo de ser chistoso, pero hasta aquí llegaron los principiantes.
Ahora veamos lo que puede hacer alguien mas experimentado en el XSS.
Que tal si intentaran algo como esto:
<iframe src=http://mipagina.com/pagina.htm>
Y en el código de pagina.htm algo como esto:
<SCRIPT TYPE="text/javascript" LANGUAGE=JAVASCRIPT>
if (top.frames.length!=0)
top.location=self.document.location; </SCRIPT>
Como podemos observar cada vez que se ingrese a la página donde se refleja esta inyección se mostrara pagina.htm como frame superior.
Ahora veamos algo más dañino, vamos a eliminar todo el contenido de la página de post y vamos a remplazarlo por un mensaje nuestro y se logra de una manera tan sencilla como esta:
<script>document.documentElement.innerHTML="Borrada";</script>
Bueno creo que con esto tenemos suficiente como para tomarle importancia a algo que a simple vista parece inofensivo, así que pasaremos directamente a las recomendaciones para solucionar este tipo de agujeros en nuestra seguridad.
Quiero que dejemos en claro que en el tema del Cross-Site-Scripting, en sitios y ataque a usuarios mediante sitios vulnerables es completa responsabilidad de los desarrolladores el permitir o no este tipo de vulnerabilidad.
Este tipo de ataque por medio del Cross-Site-Scripting es menos frecuente que el ataque a los usuarios, pero aun así existen personas que se deleitan fastidiando un sitio web por puro placer y consiste en poder almacenar scripts que se reflejen en el sitio para causar alguna alteración o eliminación del mismo, veremos algunos ejemplos comunes pero como en el tipo de ataque anterior existen agresiones mas peligrosas y dañinas que las que veremos aca.
Tomaremos como referencia un blog ya que sitios como blogs, foros y libros de visita, son los que mas fácilmente permiten este tipo de ataques, debido que en muchas ocasiones permiten el formateo de nuestro texto con etiquetas HTML y no validan correctamente el tipo de inserción que estamos haciendo.
Ahora comencemos de lo simple:
Hagamos un post como este:
<script>alert("hola");</script>
Al cargar la página donde se refleja nuestro post aparecerá una ventanita como esta.
Bien parece algo chistoso, un pequeño saludo de entrada, pero ahora quizás a ese hola podemos agregarle algo más:
<script>while(1)alert("hola");</script>
Al cargar la pagina nos aparecerá la misma ventanita de saludo pero esta vez al darle click volverá a aparecer, floodeando nuestro navegador, ya que siempre que demos click en el botón aceptar del cuadro de dialogo nos seguirá apareciendo la misma ventanita, quitándonos toda posibilidad de interactuar con el sitio ya que la única forma de cerrar este cuadro de dialogo es cerrando la web que lo ejecuta, como vemos ya dejo de ser chistoso, pero hasta aquí llegaron los principiantes.
Ahora veamos lo que puede hacer alguien mas experimentado en el XSS.
Que tal si intentaran algo como esto:
<iframe src=http://mipagina.com/pagina.htm>
Y en el código de pagina.htm algo como esto:
<SCRIPT TYPE="text/javascript" LANGUAGE=JAVASCRIPT>
if (top.frames.length!=0)
top.location=self.document.location; </SCRIPT>
Como podemos observar cada vez que se ingrese a la página donde se refleja esta inyección se mostrara pagina.htm como frame superior.
Ahora veamos algo más dañino, vamos a eliminar todo el contenido de la página de post y vamos a remplazarlo por un mensaje nuestro y se logra de una manera tan sencilla como esta:
<script>document.documentElement.innerHTML="Borrada";</script>
Bueno creo que con esto tenemos suficiente como para tomarle importancia a algo que a simple vista parece inofensivo, así que pasaremos directamente a las recomendaciones para solucionar este tipo de agujeros en nuestra seguridad.
Quiero que dejemos en claro que en el tema del Cross-Site-Scripting, en sitios y ataque a usuarios mediante sitios vulnerables es completa responsabilidad de los desarrolladores el permitir o no este tipo de vulnerabilidad.
Kenyie Araya Ramos