¿Qué es un ataque de Inyección de Scripts?
Un ataque por inyección de código se plantea como objetivo lograr inyectar en el contexto de un dominio un código Javascript, VBScript o simplemente HTML, con la finalidad de engañar al usuario o realizar una acción no deseada suplantándole.
Un concepto que debe quedar muy claro es que en este tipo de ataque el afectado no es directamente el servidor, como podría ser en el caso de un ataque de SQL Injection, sino que el objetivo directo es el usuario. Posteriormente, si el ataque es exitoso y mediante suplantación de personalidad, se podrán ejecutar las acciones deseadas en el servidor afectado y al que pueda accederse desde una página web.
Esto ha implicado que los fallos de inyección de scripts no sean considerados como amenazas críticas en algunos sectores de la seguridad informática, declarando incluso que errores de este tipo no podrían llegar a comprometer la seguridad de un sitio web. La inyección de scripts puede llegar a ser tan peligrosa como cualquier otra técnica si se sabe cuál es su límite y cuál es su potencial.
Se exponen a continuación casos reales relacionados con XSS ( cross site scripting) en los que la seguridad de algún sitio web ha quedado comprometida. A pesar del escepticismo de algunos, XSS puede permitir la obtención de privilegios sobre algún sistema lo suficientemente débil como para permitir insertar código Javascript.
Casos de Inyección de Scripts
Zone-H: El primero de los casos es el de Zone-H, página dedicada a mantener un registro de los sitios atacados a los que se les ha modificado la apariencia de la página principal, lo que en argot se denomina “defaceados”. Este sitio registra también los autores identificados de las acciones maliciosas. Resulta irónico que fuesen ellos mismos los atacados.
El método usado por los atacantes fue el de enviar a uno de los administradores del sitio un correo electrónico a su cuenta de Hotmail, donde recientemente habían localizado un fallo de XSS. Explotando el error lograron robar su cookie de sesión y con ella pudieron visitar el sitio web de Zone-H. Una vez aquí, solicitaron una recuperación de la contraseña que, evidentemente, se les envió al correo electrónico que habían secuestrado previamente. Con esta cuenta de administrador del sitio no les quedó más que publicar una noticia que incluía código HTML, especialmente escrito para colocar sobre el resto de la página el contenido que ellos deseaban.
Samy Worm y MySpace. El segundo caso real, utilizado como ejemplo, donde el XSS logró comprometer la seguridad de un sitio, fue el protagonizado por Samy Worm y MySpace. Samy es un chico de Estados Unidos que detectó una vulnerabilidad de XSS en el famoso portal de MySpace. Para explotar este fallo y aprovechando sus dotes de programación Javascript, Samy creó un gusano informático que luego se conocería como Samy Worm.
Un gusano informático es un programa que se replica entre sistemas afectados por la misma vulnerabilidad. En un entorno web, un gusano sería un código Javascript que se replica entre los perfiles de los usuarios del sitio. Y eso fue lo que hizo Samy con su gusano, replicarlo en más de un millón de perfiles de MySpace.
El gusano no era especialmente maligno. Únicamente efectuaba tres acciones: se replicaba como cualquier gusano, añadía al usuario de Samy como amigo de la persona infectada e incluía la frase “but most of all Samy is my hero” en el apartado de héroes personales de cada perfil.
En menos de 24 horas actuando llegó a bloquear el sistema de MySpace y los administradores de la red tuvieron que detener el servicio mientras limpiaban los perfiles de los usuarios infectados. A Samy le detuvieron y le condenaron a pagar una multa económica, a realizar un mes de tareas para la comunidad y a un año de inhabilitación para trabajar con ordenadores.
Hacker Safe. En el último de los casos presentado e ilustrativo de esta polémica aparece la compañía Hacker Safe, dedicada a comercializar soluciones de seguridad. Esta iniciativa promete, tras el pago de cierta cantidad monetaria, revisar diariamente la seguridad de un sitio web mediante el uso de herramientas automatizadas. Además permite incluir una pequeña imagen con el texto: “100% Hacker Safe” en el sitio, con el objeto de inspirar confianza a los usuarios.
Tras descubrirse y hacerse público que algunas de las páginas “100% Hacker Safe” presentaban vulnerabilidades de tipo XSS, algunos de los máximos responsables de la compañía llegaron a afirmar que los fallos de XSS no eran críticos y que nunca se habían llegado a utilizar para comprometer totalmente la seguridad de un sitio. Como se ha podido observar en los casos anteriores y se podrá corroborar en las páginas siguientes, esta afirmación es cuanto menos, ignorante.
TIPOS DE ATAQUES POR INYECCIÓN DE SCRIPTS
I. Cross Site Scripting (XSS)
Es un tipo de inseguridad informática o agujero de seguridad típico de las aplicaciones Web, que permite a una tercera persona inyectar en páginas web visitadas por el usuario código JavaScript o en otro lenguaje similar (ej: VBScript), evitando medidas de control como la Política del mismo origen. Este tipo de vulnerabilidad se conoce en español con el nombre de Secuencias de órdenes en sitios cruzados.
Una página es vulnerable a XSS cuando aquello que nosotros enviamos al servidor (un comentario, un cambio en un perfil, una búsqueda, etc.) se ve posteriormente mostrado en la página de respuesta.
Esto es, cuando escribimos un comentario en una página y podemos leer posteriormente nuestro mensaje, modificamos nuestro perfil de usuario y el resto de usuarios puede verlo o realizamos una búsqueda y se nos muestra un mensaje: “No se han encontrado resultados para <texto>”, se está incluyendo dentro de la página el mismo texto que nosotros hemos introducido. Ahí es donde vamos a empezar a investigar para lograr introducir nuestro código XSS.
Una vez se ha detectado una zona de la aplicación que al recibir texto procedente del usuario lo muestra en la página, es el momento de determinar si es posible utilizar esa zona como punto de ataque de XSS. Para ello es posible insertar un pequeño código Javascript que muestra un mensaje de alerta para descubrir rápidamente si se está actuando en la línea correcta de ataque.
Dentro de los posibles fallos de XSS podemos distinguir dos grandes categorías:
Permanentes: El ejemplo comentado en el párrafo anterior pertenece a esta categoría. Su denominación se debe al hecho de que, como mostraba el ejemplo, la ventana de alerta en Javascript queda almacenada en algún lugar, habitualmente una base de datos SQL, y se va a mostrar a cualquier usuario que visite nuestro perfil. Evidentemente este tipo de fallos de XSS son mucho más peligrosos que los no permanentes, que se comentan a continuación.
No permanentes: Esta categoría queda ilustrada cuando nos encontramos con una página web que dispone de buscador, el cual, al introducir una palabra inventada o una cadena aleatoria de caracteres, muestra un mensaje del tipo: “No se han encontrado resultados para la búsqueda <texto>”, donde <texto> es la cadena introducida en el campo de búsqueda.
Una vez se ha detectado una zona de la aplicación que al recibir texto procedente del usuario lo muestra en la página, es el momento de determinar si es posible utilizar esa zona como punto de ataque de XSS. Para ello es posible insertar un pequeño código Javascript que muestra un mensaje de alerta para descubrir rápidamente si se está actuando en la línea correcta de ataque. Para los ejemplos se utilizará el siguiente código:
<script>alert("¡Hola Mundo!");</script>
El código anterior va a ser válido para la mayor parte de los casos, aunque
como se verá posteriormente determinados filtros Anti-XSS pueden imposibilitar el uso de ciertos caracteres a la hora de introducir el código Javascript. Por ejemplo, las comillas dobles o los caracteres de “mayor que” y “menor que” suelen estar prohibidos.
Imaginemos que disponemos de un perfil en una red social donde se nos permite modificar nuestra descripción personal. En lugar de escribir otra información en este apartado, se introduce el código JavaScript anterior. Si al visitar de nuevo nuestro perfil se muestra una ventana de alerta con el mensaje “¡Hola Mundo!” se puede afirmar que la página en cuestión es vulnerable a XSS.
Las posibilidades que ofrece el XSS son realmente amplias. Las únicas limitaciones la constituye la imposibilidad de ejecutar código fuera del navegador, dado que la sandbox sobre la que se ejecuta no permite el acceso a ficheros del sistema, y a las propias funcionalidades que ofrezca el sitio web objeto del posible ataque.
Métodos para introducir XSS (cross site scripting)
Los métodos expuestos se nombrarán en función de las zonas de código de la aplicación web donde va a quedar ubicado el código Javascript introducido.
El código se copia entre dos etiquetas HTML: Es el modo más sencillo. Simplemente debemos introducir el código Javascript que deseemos ejecutar.
<script>alert("¡Hola Mundo!");</script>
El código se copia dentro de una etiqueta value de una etiqueta <input>: El ejemplo básico es el de los buscadores en sitios web y que se describió anteriormente. Cuando realizamos una búsqueda a través de ellos, lo habitual es que el término introducido se copie dentro del campo del buscador.
Esto en HTML quedaría como el código que se muestra a continuación:
<input type="text" name="q2 value="[busqueda]" />
Como se puede observar, nuestro código queda situado entre unas comillas dobles de un atributo perteneciente a una etiqueta HTML que no permiten que este se ejecute. Por ello será necesario cerrar la etiqueta HTML en la que nos encontremos y posteriormente insertar el código Javascript
"/><script>alert("¡Hola Mundo!");</script><div class="
Esta sería la combinación resultante.
<input type="text" name="q" value=""/>
<script>alert("Hola Mundo!");</script><div class="" />
Al final del código generado se ha introducido una etiqueta <div> para evitar de este modo que el código HTML quede malformado.
El código se copia dentro de un comentario HTML: Este caso suele ser común en páginas mal programadas que dejan mensajes de depuración dentro del código fuente HTML. Un ejemplo de lo que podríamos encontrar en una situación de este tipo es el siguiente:
<!-- La busqueda fue "[busqueda]" -->
Donde [busqueda] correspondería a la cadena de texto buscada. En este caso se deberían cerrar los caracteres de comentario HTML, introducir nuestro código Javascript y posteriormente volver a abrir los comentarios HTML. De este modo el código creado por nosotros debería compenetrarse perfectamente con el código original de la página.
--><script>alert("¡Hola Mundo");</script><!-
Esta podría ser la combinación adecuada.
<!-- La busqueda fue "--><script>alert("Hola Mundo");</script> <!--" -->
El código se copia dentro de un código Javascript: Esto es habitual cuando
las páginas utilizan datos introducidos por el usuario para generar algún tipo de evento personalizado o para almacenar datos que se van a usar posteriormente en algún otro lugar de la aplicación web. La sintaxis sería
como la siguiente:
<script> var busqueda = "[busqueda]"; </script>
En este punto no es necesario incluir las etiquetas <script>, sino que podemos
directamente introducir el código Javascript como se refleja en la siguiente sintaxis. No tener que incluir las etiquetas <script> será importante cuando sea necesario evitar los filtros anti-XSS que las eliminan.
";alert("¡Hola Mundo!");//
Hemos utilizado las barras al final de la sintaxis para lograr que el resto de la línea Javascript quede comentada y no interfiera en la ejecución de nuestro código. Esta circunstancia es ahora aún más determinante que cuando nos encontramos incorporando el código generado al código HTML, debido a que si el Javascript no es válido la mayoría de los navegadores
no lo ejecutarán.
<script> var busqueda ="";alert("¡Hola Mundo");//";</script>
Información extraída de Alonso y otros. Ataques a aplicaciones web. Universidad de Cataluña.
Website. https://www.exabyteinformatica.com/uoc/Informatica/Seguridad_en_bases_de_datos/Seguridad_en_bases_de_datos_(Modulo_2).pdf
Un ataque por inyección de código se plantea como objetivo lograr inyectar en el contexto de un dominio un código Javascript, VBScript o simplemente HTML, con la finalidad de engañar al usuario o realizar una acción no deseada suplantándole.
Un concepto que debe quedar muy claro es que en este tipo de ataque el afectado no es directamente el servidor, como podría ser en el caso de un ataque de SQL Injection, sino que el objetivo directo es el usuario. Posteriormente, si el ataque es exitoso y mediante suplantación de personalidad, se podrán ejecutar las acciones deseadas en el servidor afectado y al que pueda accederse desde una página web.
Esto ha implicado que los fallos de inyección de scripts no sean considerados como amenazas críticas en algunos sectores de la seguridad informática, declarando incluso que errores de este tipo no podrían llegar a comprometer la seguridad de un sitio web. La inyección de scripts puede llegar a ser tan peligrosa como cualquier otra técnica si se sabe cuál es su límite y cuál es su potencial.
Se exponen a continuación casos reales relacionados con XSS ( cross site scripting) en los que la seguridad de algún sitio web ha quedado comprometida. A pesar del escepticismo de algunos, XSS puede permitir la obtención de privilegios sobre algún sistema lo suficientemente débil como para permitir insertar código Javascript.
Casos de Inyección de Scripts
Zone-H: El primero de los casos es el de Zone-H, página dedicada a mantener un registro de los sitios atacados a los que se les ha modificado la apariencia de la página principal, lo que en argot se denomina “defaceados”. Este sitio registra también los autores identificados de las acciones maliciosas. Resulta irónico que fuesen ellos mismos los atacados.
El método usado por los atacantes fue el de enviar a uno de los administradores del sitio un correo electrónico a su cuenta de Hotmail, donde recientemente habían localizado un fallo de XSS. Explotando el error lograron robar su cookie de sesión y con ella pudieron visitar el sitio web de Zone-H. Una vez aquí, solicitaron una recuperación de la contraseña que, evidentemente, se les envió al correo electrónico que habían secuestrado previamente. Con esta cuenta de administrador del sitio no les quedó más que publicar una noticia que incluía código HTML, especialmente escrito para colocar sobre el resto de la página el contenido que ellos deseaban.
Samy Worm y MySpace. El segundo caso real, utilizado como ejemplo, donde el XSS logró comprometer la seguridad de un sitio, fue el protagonizado por Samy Worm y MySpace. Samy es un chico de Estados Unidos que detectó una vulnerabilidad de XSS en el famoso portal de MySpace. Para explotar este fallo y aprovechando sus dotes de programación Javascript, Samy creó un gusano informático que luego se conocería como Samy Worm.
Un gusano informático es un programa que se replica entre sistemas afectados por la misma vulnerabilidad. En un entorno web, un gusano sería un código Javascript que se replica entre los perfiles de los usuarios del sitio. Y eso fue lo que hizo Samy con su gusano, replicarlo en más de un millón de perfiles de MySpace.
El gusano no era especialmente maligno. Únicamente efectuaba tres acciones: se replicaba como cualquier gusano, añadía al usuario de Samy como amigo de la persona infectada e incluía la frase “but most of all Samy is my hero” en el apartado de héroes personales de cada perfil.
En menos de 24 horas actuando llegó a bloquear el sistema de MySpace y los administradores de la red tuvieron que detener el servicio mientras limpiaban los perfiles de los usuarios infectados. A Samy le detuvieron y le condenaron a pagar una multa económica, a realizar un mes de tareas para la comunidad y a un año de inhabilitación para trabajar con ordenadores.
Hacker Safe. En el último de los casos presentado e ilustrativo de esta polémica aparece la compañía Hacker Safe, dedicada a comercializar soluciones de seguridad. Esta iniciativa promete, tras el pago de cierta cantidad monetaria, revisar diariamente la seguridad de un sitio web mediante el uso de herramientas automatizadas. Además permite incluir una pequeña imagen con el texto: “100% Hacker Safe” en el sitio, con el objeto de inspirar confianza a los usuarios.
Tras descubrirse y hacerse público que algunas de las páginas “100% Hacker Safe” presentaban vulnerabilidades de tipo XSS, algunos de los máximos responsables de la compañía llegaron a afirmar que los fallos de XSS no eran críticos y que nunca se habían llegado a utilizar para comprometer totalmente la seguridad de un sitio. Como se ha podido observar en los casos anteriores y se podrá corroborar en las páginas siguientes, esta afirmación es cuanto menos, ignorante.
TIPOS DE ATAQUES POR INYECCIÓN DE SCRIPTS
I. Cross Site Scripting (XSS)
Es un tipo de inseguridad informática o agujero de seguridad típico de las aplicaciones Web, que permite a una tercera persona inyectar en páginas web visitadas por el usuario código JavaScript o en otro lenguaje similar (ej: VBScript), evitando medidas de control como la Política del mismo origen. Este tipo de vulnerabilidad se conoce en español con el nombre de Secuencias de órdenes en sitios cruzados.
Una página es vulnerable a XSS cuando aquello que nosotros enviamos al servidor (un comentario, un cambio en un perfil, una búsqueda, etc.) se ve posteriormente mostrado en la página de respuesta.
Esto es, cuando escribimos un comentario en una página y podemos leer posteriormente nuestro mensaje, modificamos nuestro perfil de usuario y el resto de usuarios puede verlo o realizamos una búsqueda y se nos muestra un mensaje: “No se han encontrado resultados para <texto>”, se está incluyendo dentro de la página el mismo texto que nosotros hemos introducido. Ahí es donde vamos a empezar a investigar para lograr introducir nuestro código XSS.
Una vez se ha detectado una zona de la aplicación que al recibir texto procedente del usuario lo muestra en la página, es el momento de determinar si es posible utilizar esa zona como punto de ataque de XSS. Para ello es posible insertar un pequeño código Javascript que muestra un mensaje de alerta para descubrir rápidamente si se está actuando en la línea correcta de ataque.
Dentro de los posibles fallos de XSS podemos distinguir dos grandes categorías:
Permanentes: El ejemplo comentado en el párrafo anterior pertenece a esta categoría. Su denominación se debe al hecho de que, como mostraba el ejemplo, la ventana de alerta en Javascript queda almacenada en algún lugar, habitualmente una base de datos SQL, y se va a mostrar a cualquier usuario que visite nuestro perfil. Evidentemente este tipo de fallos de XSS son mucho más peligrosos que los no permanentes, que se comentan a continuación.
No permanentes: Esta categoría queda ilustrada cuando nos encontramos con una página web que dispone de buscador, el cual, al introducir una palabra inventada o una cadena aleatoria de caracteres, muestra un mensaje del tipo: “No se han encontrado resultados para la búsqueda <texto>”, donde <texto> es la cadena introducida en el campo de búsqueda.
Una vez se ha detectado una zona de la aplicación que al recibir texto procedente del usuario lo muestra en la página, es el momento de determinar si es posible utilizar esa zona como punto de ataque de XSS. Para ello es posible insertar un pequeño código Javascript que muestra un mensaje de alerta para descubrir rápidamente si se está actuando en la línea correcta de ataque. Para los ejemplos se utilizará el siguiente código:
<script>alert("¡Hola Mundo!");</script>
El código anterior va a ser válido para la mayor parte de los casos, aunque
como se verá posteriormente determinados filtros Anti-XSS pueden imposibilitar el uso de ciertos caracteres a la hora de introducir el código Javascript. Por ejemplo, las comillas dobles o los caracteres de “mayor que” y “menor que” suelen estar prohibidos.
Imaginemos que disponemos de un perfil en una red social donde se nos permite modificar nuestra descripción personal. En lugar de escribir otra información en este apartado, se introduce el código JavaScript anterior. Si al visitar de nuevo nuestro perfil se muestra una ventana de alerta con el mensaje “¡Hola Mundo!” se puede afirmar que la página en cuestión es vulnerable a XSS.
Las posibilidades que ofrece el XSS son realmente amplias. Las únicas limitaciones la constituye la imposibilidad de ejecutar código fuera del navegador, dado que la sandbox sobre la que se ejecuta no permite el acceso a ficheros del sistema, y a las propias funcionalidades que ofrezca el sitio web objeto del posible ataque.
Métodos para introducir XSS (cross site scripting)
Los métodos expuestos se nombrarán en función de las zonas de código de la aplicación web donde va a quedar ubicado el código Javascript introducido.
El código se copia entre dos etiquetas HTML: Es el modo más sencillo. Simplemente debemos introducir el código Javascript que deseemos ejecutar.
<script>alert("¡Hola Mundo!");</script>
El código se copia dentro de una etiqueta value de una etiqueta <input>: El ejemplo básico es el de los buscadores en sitios web y que se describió anteriormente. Cuando realizamos una búsqueda a través de ellos, lo habitual es que el término introducido se copie dentro del campo del buscador.
Esto en HTML quedaría como el código que se muestra a continuación:
<input type="text" name="q2 value="[busqueda]" />
Como se puede observar, nuestro código queda situado entre unas comillas dobles de un atributo perteneciente a una etiqueta HTML que no permiten que este se ejecute. Por ello será necesario cerrar la etiqueta HTML en la que nos encontremos y posteriormente insertar el código Javascript
"/><script>alert("¡Hola Mundo!");</script><div class="
Esta sería la combinación resultante.
<input type="text" name="q" value=""/>
<script>alert("Hola Mundo!");</script><div class="" />
Al final del código generado se ha introducido una etiqueta <div> para evitar de este modo que el código HTML quede malformado.
El código se copia dentro de un comentario HTML: Este caso suele ser común en páginas mal programadas que dejan mensajes de depuración dentro del código fuente HTML. Un ejemplo de lo que podríamos encontrar en una situación de este tipo es el siguiente:
<!-- La busqueda fue "[busqueda]" -->
Donde [busqueda] correspondería a la cadena de texto buscada. En este caso se deberían cerrar los caracteres de comentario HTML, introducir nuestro código Javascript y posteriormente volver a abrir los comentarios HTML. De este modo el código creado por nosotros debería compenetrarse perfectamente con el código original de la página.
--><script>alert("¡Hola Mundo");</script><!-
Esta podría ser la combinación adecuada.
<!-- La busqueda fue "--><script>alert("Hola Mundo");</script> <!--" -->
El código se copia dentro de un código Javascript: Esto es habitual cuando
las páginas utilizan datos introducidos por el usuario para generar algún tipo de evento personalizado o para almacenar datos que se van a usar posteriormente en algún otro lugar de la aplicación web. La sintaxis sería
como la siguiente:
<script> var busqueda = "[busqueda]"; </script>
En este punto no es necesario incluir las etiquetas <script>, sino que podemos
directamente introducir el código Javascript como se refleja en la siguiente sintaxis. No tener que incluir las etiquetas <script> será importante cuando sea necesario evitar los filtros anti-XSS que las eliminan.
";alert("¡Hola Mundo!");//
Hemos utilizado las barras al final de la sintaxis para lograr que el resto de la línea Javascript quede comentada y no interfiera en la ejecución de nuestro código. Esta circunstancia es ahora aún más determinante que cuando nos encontramos incorporando el código generado al código HTML, debido a que si el Javascript no es válido la mayoría de los navegadores
no lo ejecutarán.
<script> var busqueda ="";alert("¡Hola Mundo");//";</script>
Información extraída de Alonso y otros. Ataques a aplicaciones web. Universidad de Cataluña.
Website. https://www.exabyteinformatica.com/uoc/Informatica/Seguridad_en_bases_de_datos/Seguridad_en_bases_de_datos_(Modulo_2).pdf
No hay comentarios:
Publicar un comentario