Universidad Jaume I

Desarrollo Web Avanzado

Seguridad Web

Desarrollo Web Avanzado

Seguridad Web

 INDICE

Indice
Indice de guras 1. Introduccin a la seguridad Web. o 2. Algunos datos. 3. Consideraciones bsicas de seguridad. a 3.1. Entrada de datos, variables globales y escapado automtico, consideraciones. a 3.2. Autenticacin de usuarios. . . . . . . . . . . . . . . . . . . . . . . . . . . . o 3.2.1. Almacenamiento de contraseas. . . . . . . . . . . . . . . . . . . . . n 3.3. Gestin de la sesin. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . o o 4. Errores de seguridad convencionales. 4.1. HTML injection. . . . . . . . . . . . . . 4.2. SQL Injection. . . . . . . . . . . . . . . . 4.3. Blind SQL Injection. . . . . . . . . . . . 4.4. Cross Site Scripting (XSS). . . . . . . . . 4.4.1. XSS en sesiones no autenticadas. 4.4.2. XSS autocontenidos. . . . . . . . 4.5. Cross Site Request Forgeries (CSRF). . . 4.6. XPath Injection. . . . . . . . . . . . . . 4.7. Cross Site Tracing (XST). . . . . . . . . 4.8. Session Fixation. . . . . . . . . . . . . . 4.9. Session Hijacking. . . . . . . . . . . . . . 4.10. Weak Upload File Checks. . . . . . . . . 4.11. Allow url fopen. . . . . . . . . . . . . . . 4.12. Divisin de respuesta HTTP. . . . . . . . o 4.13. DNS Rebinding. . . . . . . . . . . . . . . 4.14. Comprobacin insuciente. . . . . . . . . o 4.15. Null Byte. . . . . . . . . . . . . . . . . . 4.16. Apache y mod mime. . . . . . . . . . . . 3 6 7 9 9 11 14 15 16 16 17 18 19 20 21 21 22 22 23 24 24 25 25 26 27 27 28 28 28 29 30 30 32

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

5. Tcnicas de proteccin adicionales. e o 5.1. Captchas, tipos de ataques. . . . . . . . . . 5.2. Controles anti-spam, ofuscacin JavaScript. . o 5.3. Herramientas de auditor . . . . . . . . . . a. 5.4. Cookies httponly y secure. . . . . . . . . . . Referencias

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

Indice de guras
1. 2. 3. Clasicacin por objetivo de los atacantes. . . . . . . . . . . . . . . . . . . o A quin se ataca. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . e Vulnerabilidades o tipos de ataques utilizados. . . . . . . . . . . . . . . . . 8 8 9

Desarrollo Web Avanzado

Seguridad Web

Indice de guras

4. 5. 6. 7.

Inyeccin HTML. . . . . . . . . . . . . . o Cross Site Scripting. . . . . . . . . . . . Un ejemplo de Captcha. . . . . . . . . . Captcha de fcil reconocimiento de forma a

. . . . . . . . . . . . . . . . . . . . . . . . . . . automatizada.

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

17 20 29 29

Desarrollo Web Avanzado

Seguridad Web

 INDICE DE FIGURAS

Desarrollo Web Avanzado

Seguridad Web

1 Introduccin a la seguridad Web. o

1.

Introduccin a la seguridad Web. o

La teor de seguridad tradicional contempla tres dimensiones o propiedades bsicas que a a deben protegerse, stas son la condencialidad, la integridad y la disponibilidad. e

Condencialidad: Esta propiedad hace referencia a que el acceso a los datos solo puede ser realizado por aquellas personas o entidades autorizadas. Integridad: Esta propiedad indica que los datos deben mantenerse ntegros, es decir, exactamente igual que en su origen. Disponibilidad: Esta propiedad hace referencia a que los datos deben estar accesibles en el momento en el que son necesarios. Autenticidad: Esta propiedad indica que los datos son autnticos, es decir, que e proceden de quien los origin y que no han sido modicados. Esta propiedad esta o ntimamente relacionada con la integridad.

La teor de seguridad tradicional intenta cubrir, fundamentalmente estos aspectos a pesar a de que no son las unicas propiedades a tener en cuenta1 . Con la evolucin de Internet y la Web, las aplicaciones de escritorio se han visto deo splazadas por las aplicaciones Web basadas en tecnolog de cliente rico. Esto ha sido as posible, en parte, por la evolucin de los navegadores que han pasado de ser simples preo sentadores de pginas web a plataformas de ejecucin de aplicaciones gracias a la adicin a o o por parte de los desarrolladores de funcionalidades como XMLHttpRequest y redibujado dinmico de secciones as como la continua optimizacin aplicada sobre los motores a o JavaScript que incorporan los navegadores. Este hecho ha producido un desplazamiento de la investigacin en materia de segurio 2 dad desde la bsqueda y explotacin en aplicaciones locales o de escritorio hacia la u o investigacin en seguridad de aplicaciones Web. Fruto de esa investigacin, aparece una o o clasicacin de vulnerabilidades ms frecuentes, comnmente aceptadas por los profesiono a u ales del sector. Organizaciones como OWASP3 o WASC4 dirigen sus esfuerzos hacia la mejora de la seguridad Web en general ofreciendo para ello una clasicacin de problemas o comunes de seguridad y qu medidas pueden adoptarse para cada una de ellas. e
1 2

Tambin existe, por ejemplo, el no repudio e Acto de aprovechar un error de seguridad para obtener un efecto que, inicialmente, no se nos permite. 3 Open Web Application Security Project 4 Web Application Consortium

Desarrollo Web Avanzado

Seguridad Web

2.

Algunos datos.

Sobre la mencionada clasicacin, han surgido estudios que indican, en la medida de lo o posible, que objetivos se buscan detrs de un ataque contra una aplicacin Web y qu tipo a o e de errores se suelen aprovechar para conseguirlos. Estos estudios, se realizan mediante la exploracin de las listas de informacin de vulnerabilidades5 o por empresas del sector de o o la seguridad informtica. a WASC esta llevando a cabo un proyecto en el que las empresas ms relevantes en el ambito a de la seguridad informtica ofrecen sus datos estad a sticos para mantener una informacin o completa sobre las amenazas ms relevantes en cuanto a errores aprovechados por ataques a en aplicaciones Web. A continuacin expondremos los datos, para el informe que comprende el ao 2007. El o n primer aspecto que se estudia en el informe es la motivacin de los ataques realizados, esto o es, el porqu de las acciones llevadas a cabo. Con respecto a esto, la gura 1 podemos ver e como la mayor de los ataques buscan obtener informacin condencial sobre la que no a o tienen acceso l cito, esto vulnerar la condencialidad y el tipo de informacin que suele a o buscarse en estos ataques son nmeros de tarjetas de crdito, cuentas bancarias, credenu e ciales de acceso a aplicaciones, direcciones de correo electrnico y secretos industriales. o Por otro lado vemos que la segunda motivacin en orden de aparicin es el defacement o o o modicacin de alguna de las pginas Web que componen el sitio, este hecho suele o a responder a motivos pol ticos6 o ideolgicos y afecta fundamentalmente a la integridad o de la informacin. Podemos tambin apreciar como el objetivo de instalar malware7 en o e los servidores web tambin es el tercer motivo de ataque de las aplicaciones Web, estas e instalaciones de malware permiten a los atacantes instalar software malicioso en algunas de las mquinas que visitan el sitio Web obteniendo el control sobre las mismas y a creando redes de botnets 8 . Por ultimo el tipo de motivaciones que podemos identicar, las podemos agrupar en chantajes y estafas o engaos. Recientemente surgi la alarma n o 9 en Internet por la aparicin del virus GPCode , este virus realiza un cifrado de archivos o con ciertas extensiones utilizando criptograf fuerte de clave pblica y despus solicita la a u e compra de un software para recuperar lo archivos. Esto ser obviamente, un ejemplo de a, chantaje.

Como, por ejemplo, Bugtraq o Full-disclosure Noticias relacionadas Hackean la web Ministerio de Vivienda y Un descuido en la web de Rajoy permite que cualquiera la cambie. 7 Malware. 8 Botnet en wikipedia. 9 Informacin sobre el virus. o
6

Desarrollo Web Avanzado

Seguridad Web

2 Algunos datos.

Figura 1: Clasicacin por objetivo de los atacantes. o

En este estudio tambin se clasican los ataques por organizaciones como puede verse en e la gura 2. Podemos ver como los objetivos ms atacados son aplicaciones Web gubernaa mentales, organizaciones educativas y tiendas on-line.

Figura 2: A quin se ataca. e

El informe nos ofrece tambin una clasicacin por tipos de errores o tcnicas de ataque e o e utilizadas contra estas aplicaciones Web.Vase la gura 3. e Desarrollo Web Avanzado Seguridad Web

A travs de este documento presentaremos una descripcin de estas tcnicas y algunas e o e otras tambin utilizas as como la forma de prevenirlas en nuestras aplicaciones web. e

Figura 3: Vulnerabilidades o tipos de ataques utilizados.

3.
3.1.

Consideraciones bsicas de seguridad. a

Entrada de datos, variables globales y escapado automtico, a consideraciones.

Podemos simplicar el funcionamiento de una aplicacin web indicando que sta funciona o e de la siguiente forma:

1. El cliente, usualmente un navegador, solicita unos datos mediante una peticin o HTTP. En algunos casos el cliente ofrece datos necesarios para acceder a esos datos (inputs). Desarrollo Web Avanzado Seguridad Web

10

3 Consideraciones bsicas de seguridad. a

2. El servidor procesa los datos de entrada, en el caso de existir, y en funcin de o ellos recupera otros datos de alguna fuente (BBDD, cheros,etc), les da un formato determinado y los muestra.

La entrada de datos en el servidor desde el cliente puede darse de diferentes formas:

En la peticin HTTP mediante GET o POST: Es la forma estndar de recibir datos o a por parte del servidor, en el primer caso los datos se codican en la URL de la peticin y en el segundo en el cuerpo de la misma peticin. o o En campos INPUT de un formulario: Estos campos input son enviados al servidor utilizando uno de los dos mtodos indicados arriba. e En forma de COOKIE: Podemos ver una cookie como un dato que establece un servidor en un cliente y que ste ultimo env automticamente en cada peticin e a a o posterior.

Estos inputs o entradas de datos deben ser siempre saneados en funcin del uso que se o vaya a hacer de ellos, por ejemplo, para utilizarlos en el acceso a BBDD debemos escapar los caracteres \ i NULL puesto que estos pueden dar lugar a modicaciones sobre las consultas predenidas provocando comportamientos no esperados en nuestra aplicacin, o como veremos ms adelante en la seccin relativa a SQL injection y Blind SQL Injection. a o Otro tipo de modicaciones sobre estos datos, pueden alterar el comportamiento de consultas sobre estructuras XML, como tambin veremos en la seccin de XPath injection. e o Si los datos de entrada van a ser incluidos en la presentacin Web nal, entonces, debeo mos tener especial cuidado con las marcas HTML que stas entradas posean puesto que e nuevamente, una entrada especialmente diseada puede modicar la pgina Web nal. n a Los lenguajes de programacin ms utilizados en programacin web, nos ofrecen hero a o ramientas para realizar estos saneamientos, por ejemplo en PHP y Java podemos utilizar:

PHP magic quotes gpc: Esta directiva se establece en el chero de conguracin del o interprete PHP y hace que las entradas de datos a travs de GET, POST y e COOKIE se escapen automticamente frente a los caracteres ,,\ i NULL. a Esta funcionalidad ha sido motivo de polmica entre los desarrolladores de e PHP puesto que conar en ella puede ser peligroso si la aplicacin que lo hace o necesita migrarse por cualquier motivo y la nueva instalacin de PHP tiene o esta funcionalidad desactivada. Probablemente, esto har que en la aplicacin a o Desarrollo Web Avanzado Seguridad Web

3.2 Autenticacin de usuarios. o

11

aparecieran multitud de problemas de seguridad que no exist antes. Otra an razn en contra es que todos los datos de entrada son escapados indiscrimio nadamente, a pesar de que stos no vayan a ir a parar a una consulta SQL. Por e ultimo, tener en cuenta estos dos ultimos aspectos, hace que la programacin o sea algo ms tediosa como puede verse en el siguiente ejemplo: a gpc.php
1 2 3 4 5 6 7

<? if (!get_magic_quotes_gpc()) { $data = addslashes($_POST[data]); } else { $data = $_POST[data]; } ?> Por esto, los desarrolladores de PHP han decidido eliminar esta caracter stica de la versin 6 de PHP y dejar en manos del programador o los entornos de o desarrollo las medidas de seguridad necesarias. o strip tags(): Funcin PHP que elimina las marcas correspondientes a HTML y PHP. addslashes(): Tiene el mismo efecto que la activacin de magic quotes gpc al o ser aplicada sobre una variable. htmlentities(): Esta funcin convierte los caracteres especiales HTML a sus o correspondientes entidades codicadas de forma que el navegador las muestra sin que intereran en el cdigo original. o htmlspecialchars(): Convierte tambin caracteres especiales a entidades HTML, e la diferencia con htmlentities es que no convierte todos los caracteres, slo los o ms habituales. a

Java PreparedStatement: En Java, esta clase escapa los caracteres especiales en relacin a consultas SQL. o StringEscapeUtils: Esta clase perteneciente al paquete commons de Apache, nos permite realizar la misma traduccin que htmlentities o

3.2.

Autenticacin de usuarios. o

Entendemos por autenticacin de usuarios el proceso que indica que un usuario es quien o dice ser o, al menos, tiene bajo su control las credenciales que le han sido ofrecidas en algn tipo de proceso de registro. u Desarrollo Web Avanzado Seguridad Web

12

3 Consideraciones bsicas de seguridad. a

Por otro lado la autorizacin es entendida como la capacidad de que un usuario ya ideno ticado acceda a un recurso concreto dependiendo del grupo o rol al que pertenece dentro de la aplicacin. o En lo que al desarrollo de aplicaciones Web se reere, debemos adoptar varias consideraciones especiales con respecto a este procedimiento:

Autenticacin en el lado del cliente: o Autenticacin mediante scripts ejecutados en cliente: Nunca hay que autenticar o al usuario en el lado del cliente mediante scripts sobre los que l tiene control e puesto que puede manipularlos obteniendo acceso a recursos para los que no esta autorizado. Autenticacin utilizando Applets Java o Flash: Si la autenticacin del usuario o o va a llevarse a cabo mediante el despliegue de una aplicacin Java (applet) o o Flash en el cliente, debe hacerse correctamente y cuidadosamente de forma que no se incluyan datos relevantes en el proceso de autenticacin que permitan o a un atacante saltarse el mismo. Esta recomendacin viene dada puesto que o los applets Java son fcilmente decompilables con, por ejemplo, JAD10 y los a cheros swf generados durante la compilacin de ash, pueden decompilarse o tambin con facilidad utilizando, por ejemplo, Flash Decompiler11 . e La forma correcta de autenticar a un usuario utilizando un applet Java o una aplicacin ash, es mediante la utilizacin de un servicio Web que realice la o o comprobacin e indique la pgina a visitar en caso de xito. o a e Autenticacin por IP: La forma ms simple de autenticar a un usuario es en funcin o a o de la ip de la mquina que utiliza y a pesar de ser ste un mtodo poco seguro si se a e e utiliza de forma aislada, puede complementar controles sobre sesiones autenticadas como veremos ms adelante. a Cuando un cliente realiza una peticin HTTP a un servidor, ste exporta dos vario e ables de entorno que son fundamentales en la relacin con la autenticacin por IP, o o estas son a REMOTE ADDR: Nos indica la ip de la mquina que ha conectado con el servidor. X FORWARDED FOR: La aparicin de este campo en la peticin HTTP es o o debido a que la mquina que realiza la peticin HTTP se encuentra detrs de a o a un proxy, y ste establece esta cabecera como informacin adicional sobre cual e o de las mquinas que realizan peticiones a travs de l ha sido la causante de la a e e peticin. o Cuando autenticamos, o realizamos controles sobre la IP, no es suciente comprobar el campo REMOTE ADDR puesto que dos mquinas que realizaran peticiones a
10 11

Pgina del proyecto JAD a Pgina del proyecto Flash Decompiler a

Desarrollo Web Avanzado

Seguridad Web

3.2 Autenticacin de usuarios. o

13

a travs del mismo proxy compartir el valor de este campo y por tanto la autene an ticacin sin ser este el efecto deseado. o El utilizar unicamente el campo X FORWARDED FOR tampoco es correcto puesto que este campo puede ser manipulado por el cliente para indicar cualquier direccin o IP. Para realizar un correcto control de la direccin IP deber o amos utilizar el campo o REMOTE ADDR y si existe el campo X FORWARDED FOR, la unin de ambos, por ejemplo de esta forma: REMOTE ADDR - X FORWARDED FOR. Autenticacin por Usuario/Contrasea: o n Cuando autenticamos al usuario por medio de un nombre de usuario y contrasea n y en general por cualquier tipo de datos que el usuario utilice como credenciales de acceso y stas le den acceso a ciertas partes de la aplicacin Web, debemos tener e o en cuenta que puede estar accediendo desde, por ejemplo, una red inalmbrica sin a cifrado de datos, o desde una LAN donde, con las herramientas adecuadas, puede redirigirse el trco de datos de una mquina a otra sin que el usuario lo perciba. a a Por esto, debemos utilizar SSL en la medida de lo posible, de forma que aunque los datos sean capturados, estos no sean inteligibles por terceros. Autenticacin tipo CHAP: o Muchas veces, por restricciones de nuestro proveedor de hosting o por el hecho de intentar eliminar el requisito SSL de nuestro proyecto, no podemos utilizar esta tecnolog En estos casos podemos utilizar CHAP12 . a. CHAP es interesante por el hecho de que permite realizar autenticacin sin transo mitir ninguna contrasea por el canal de comunicaciones utilizado. Este mtodo se n e compone de los siguientes pasos: 1. Ambas partes, cliente y servidor conocen las credenciales de autenticacin. o 2. El cliente solicita iniciar el procedimiento de autenticacin. o 3. El servidor genera un reto aleatorio y lo env al cliente. a 4. Cliente y servidor realizan la operacin x = hash(reto + credenciales), donde o 13 hash es una funcin de resumen y + representa una operacin de concateo o nacin. o 5. El cliente env x al servidor. a 6. El servidor compara x con x correspondiente al valor calculado por l. Si ambos e coinciden, la autenticacin se ha llevado a cabo con xito. o e De esta forma si alguien captura x al ser enviado desde el cliente al servidor no podr utilizarlo puesto que deber iniciar el proceso de autenticacin y el servidor a a o generar un nuevo reto y por tanto x ser distinto. a a Se puede encontrar una implementacin completa haciendo uso de JavaScript en el o lado del cliente y PHP en el lado del servidor en:
12 13

Challenge Handshake Authentication Protocol. http://en.wikipedia.org/wiki/Cryptographic hash function

Desarrollo Web Avanzado

Seguridad Web

14

3 Consideraciones bsicas de seguridad. a

http://www.devarticles.com/c/a/JavaScript/Building-a-CHAP-Login-System-EncryptingData-in-the-Client/ Una implementacin alternativa de este mtodo pasa por la utilizacin del algoritmo o e o de cifrado por ujo RC4 de sencilla implementacin y que sustituir el uso de la o a funcin de resumen. o Como contrapartida, este mtodo obliga al servidor a almacenar la contrasea del e n cliente en formato plano. Autenticacin X509: o Este tipo de autenticacin forma parte del protocolo TLS14 y permite autenticar o tanto a cliente como servidor haciendo uso de una infraestructura de clave pblica15 . u Para ello es necesario que tanto el servidor como el cliente entiendan ssl. Utilizando un tamao de clave adecuado para cada algoritmo de cifrado, este mtodo es uno n e de los ms fuertes que podemos utilizar. a En este punto cabe mencionar que este tipo de autenticacin puede utilizarse tamo bin sin necesidad de hacer uso de SSL. Para esto, ser necesario desplegar una e a aplicacin en el cliente, por ejemplo un applet Java, que le permitiera al usuario ro mar unos datos aleatorios que el servidor habr enviado, el procedimiento completo a ser a: 1. El cliente realiza un peticin de autenticacin al servidor. o o 2. El servidor genera unos datos aleatorios y los env junto con un applet que se a despliega en el cliente permitindole rmar. e 3. El cliente rma esos datos haciendo uso del applet y env la rma de vuelta a al servidor. 4. El servidor comprueba que la rma es correcta y vlida y en tal caso da al a cliente como autenticado.

3.2.1.

Almacenamiento de contrase as. n

En el cliente: Una de las funciones de la aplicacin en cuanto a su nivel de seguridad o es informar en la medida de lo posible y de una forma util y clara al usuario de los problemas de seguridad que puede experimentar al utilizar ciertas funcionalidades de los navegadores, como por ejemplo el almacenamiento de contraseas. n Este almacenamiento es relevante desde el punto de vista de la seguridad puesto que, como veremos ms adelante, existen tcnicas para obtener esos datos utilizando otras a e vulnerabilidades de las aplicaciones Web. En el servidor: En el lado del servidor, las contraseas deber almacenarse, en la n an medida de lo posible, de forma ininteligible. De esta forma las contraseas estarn n a
14 15

http://www.faqs.org/rfcs/rfc2246.html http://es.wikipedia.org/wiki/X.509

Desarrollo Web Avanzado

Seguridad Web

3.3 Gestin de la sesin. o o

15

protegidas frente a accesos no autorizados a este tipo de informacin. Para ello o podemos utilizar, nuevamente, una funcin de resumen (como sha1 o sha256 ). o

3.3.

Gestin de la sesin. o o

En este punto nos referimos a sesin como la parte que queda en el servidor que relaciona o a un usuario con su entorno autenticado, dejando a un lado otras generalidades como sesiones no autenticadas. Sobre una sesin autenticada, debemos establecer, al menos, los siguientes controles: o

Validez temporal de la sesin: La sesin debe expirar en un tiempo razonable, o o dependiendo el objetivo de la misma, pero no debe permitir sesiones sin caducidad ni con excesivo tiempo de expiracin. o Un ejemplo donde la gestin incorrecta de este aspecto de la sesin podr inducir o o a problemas de seguridad es en los ordenadores de acceso pblico, bien sean cibercafs, u e bibliotecas, salas multimedia, etc. Donde al cambiar de un usuario a otro, si el primero no ha eliminado la sesin de alguna forma, el segundo puede utilizarla o il citamente. Debe realizarse un control de IP: Si, por cualquier motivo, un atacante consigue el identicador de sesin de otro, no debe ser posible que acceda a la aplicacin o o utilizando este identicador desde otra mquina. a Env de token asociado a formularios: Este control consiste en establecer o bien o un campo hidden con un token unico en formularios y enlaces a zonas autenticadas de la aplicacin o un parmetro token=xxxxxxxxxx a las URL destino de zonas o a autenticadas. De esta forma emulamos sesiones autenticadas con accesos, de un solo uso y este uso se invalida frente un acceso del usuario generando un nuevo token. La forma de utilizar esto es la siguiente: 1. El cliente se autentica ofreciendo las credenciales correctas. 2. El servidor genera un valor aleatorio sucientemente grande, unos 20 bytes ser ms que suciente, y lo aade a un campo hidden o a la URL de todas a a n los enlaces que se generen en la pgina a enviar al cliente. a 3. El servidor almacena ese valor aleatorio en la sesin. o 4. Cuando el cliente realiza una nueva peticin, env el token de forma transo a parente, el servidor lo valida, genera un nuevo token y sustituye el anterior. A partir de aqu se contina nuevamente desde el punto 2. u En entornos abiertos: En este punto, nos referimos a transmisiones realizadas mediante WIFI, LANs y entornos poco ables. En estos casos, deber amos utilizar SSL Desarrollo Web Avanzado Seguridad Web

16

4 Errores de seguridad convencionales.

puesto que a un usuario autenticado, se le podr robar el identicador de sesin y a o suplantar su direccin IP. o

Mediante cookies: Podemos ver las cookies como datos adicionales que se establecen en el lado del cliente y contienen, en el caso de las sesiones, el identicador de sesin. o Sobre stas, deben aplicarse las medidas de seguridad explicadas anteriormente. e SessionId: De forma alternativa a las cookies para almacenar el identicador de sesin en el cliente, algunas implementaciones de lenguajes de servidor, nos permiten o inicializar la sesin aadiendo sessionid=xxxxxx al nal de la URL que representa o n la peticin. o

4.

Errores de seguridad convencionales.

A continuacin, veremos una relacin de descripcin, ejemplo y solucin a aplicar para o o o o las tcnicas ms utilizadas en cuanto a explotacin Web. e a o

4.1.

HTML injection.
Descripcin: Este tipo de tcnica consiste en inyectar cdigo HTML que no es o e o correctamente saneado para manipular el cdigo HTML nal que visualizar el o a usuario. Este tipo de ataques se utilizan como complemento de otros ms complejos a como, por ejemplo, el phishing16 . Ejemplo: A continuacin puede verse un cdigo, escrito en PHP, que es vulnerable, o o en l podemos introducir en el formulario <H1>Injection</H1> alterando el resule tado nal. htmlinj.php

1 2 3 4 5 6 7 8 9

<? if ($_GET[user]){ echo "Hola: " . $_GET[user]; } else{ echo "<form method=GET action=>". "Introduce tu nombre: <input type=text name=user>". "<input type=submit value=enviar>"; }
http://es.wikipedia.org/wiki/Phishing

16

Desarrollo Web Avanzado

Seguridad Web

4.2 SQL Injection.

17

10 11

?>

Figura 4: Inyeccin HTML. o

Solucin: Utilizar funciones de conversin de caracteres especiales a entidades HTML o o para que stos sean visualizados a travs del navegador en lugar de ser interpretados e e por l. e

4.2.

SQL Injection.
Descripcin: Esta tcnica permite manipular las consultas SQL que se realizan cono e tra una base de datos para que el comportamiento no sea el esperado por el programador. Ejemplo: Imaginemos que en la consulta del siguiente ejemplo, SELECT * FROM users WHERE login=$login and pass=$pass el usuario introduce el siguiente valor de login: OR 1=1#, la consulta SQL resultante se convertir en SELECT * a FROM users WHERE login=OR 1=1# and pass= que siempre devolver tana tas las como usuarios existan en la BBDD y por tanto la comprobacin de la l o nea 13 se evaluar como cierta sin haber introducido las credenciales de acceso correctas. a sqlinj.php

1 2 3 4 5 6 7 8

<? $login= $_POST[login]; $pass= $_POST[pass]; $host= "localhost"; $conexion= mysql_connect($host, user, pwd); $consulta="SELECT * FROM users WHERE login=$login" . "and pass=$pass"; Seguridad Web

Desarrollo Web Avanzado

18

4 Errores de seguridad convencionales.

9 10 11 12 13 14 15 16 17

$result= mysql_db_query(bbdd, $consulta) or die("<h1>Fallo en la consulta</h1>"); $num_rows= mysql_num_rows($result); if ($num_rows > 0) //Usuario logeado; else //Usuario invalido; ?>

Solucin: Utilizar funciones de escapado de caracteres especiales en consultas a o BBDD para los valores introducidos por el usuario. En PHP puede utilizarse la funcin mysql real escape string y en Java la clase PreparedStatement. o

4.3.

Blind SQL Injection.

Descripcin: Esta tcnica se basa en el mismo error de programacin del SQL ino e o jection convencional con la diferencia de que, modicando la sentencia, el atacante slo logra alguna modicacin sutil del sitio Web sin ms informacin. Esto suele o o a o aprovecharse por medio de ataques de fuerza bruta (prueba y error de determinado espacio de soluciones) o ataques con diccionario (prueba y error con espacio de soluciones predenido). Ejemplo: En este ejemplo, podemos ver como ante una consulta vlida, a pesar a de no existir un id determinado, el texto Noticia: aparecer. Si la consulta falla, a este no aparecer. De esta forma el atacante tiene la certeza de que esta enviando a consultas vlidas contra la BBDD y por tanto puede ejecutar el cdigo SQL que sea a o necesario para conseguir su objetivo. Un ataque comn que aprovecha esta vulnerabilidad es el uso de la funcin user() u o para obtener el usuario que conecta con la bbdd ejecutando la siguiente secuencia de sentencias SQL aprovechando la inyeccin: o select * where user() like a % select * where user() like b % select * where user() like c % select * where user() like d % ... select * where user() like ra % select * where user() like rb % select * where user() like rc % select * where user() like rd %

Desarrollo Web Avanzado

Seguridad Web

4.4 Cross Site Scripting (XSS).

19

...

Hasta obtener el nombre de usuario correcto. bsqlinj.php

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

<? $login= $_POST[id]; $host= "localhost"; $conexion= mysql_connect($host, user, pwd); $consulta="SELECT text FROM news WHERE id=$id"; $result= mysql_db_query(bbdd, $consulta) if (!$result) die(); else{ while($r= mysql_fetch_assoc($result)) echo "Noticia: " . $r[text]; } ?>

Solucin: Como en el caso anterior, utilizar funciones de escapado de caracteres o especiales SQL.

4.4.

Cross Site Scripting (XSS).

Descripcin: Esta tcnica aprovecha, de nuevo, el hecho de un saneamiento de o e parmetros de entrada incorrecto para inyectar cdigo de script en el cliente, por a o ejemplo JavaScript, para obtener datos condenciales y enviarlos a un tercer servidor.

Ejemplo: El cdigo que se ha utilizado como ejemplo es el mostrado en el listado del o punto 4.1. En cuyo formulario hemos introducido la siguiente secuencia de caracteres <script>alert(document.cookie);</script> haciendo que se nos muestre la cookie seleccionada para ese dominio. El ataque completo, consiste en hacer que un usuario pinche sobre un enlace especialmente creado con el cdigo indicado en l. o e Desarrollo Web Avanzado Seguridad Web

20

4 Errores de seguridad convencionales.

Figura 5: Cross Site Scripting.

En el ejemplo, hemos utilizado la funcin JavaScript alert para mostrar el efecto o aunque en un ataque real se utilzar marcas como <img src= o <iframe src= an para hacer que el usuario enviara los datos de sesin a un tercer servidor controlado o por el atacante. Solucin: Este error se evita, tambin, realizando el saneamiento adecuado sobre las o e variables de entrada, o bien eliminando las marcas especiales o bien traduciendo los caracteres especiales a entidades html.

4.4.1.

XSS en sesiones no autenticadas.

Cuando la sesin an no ha sido autenticada, el identicador de sesin existente en la o u o cookie an no tiene valor, an as pueden realizarse dos tipos de ataques. u u ,

Fijacin de sesin: Un atacante podr establecer la cookie mediante, por ejemplo, o o a Javascript utilizando document.cookie=, una vez hecho esto, solo har falta esperar a a que el usuario se autenticara para que el atacante posea un identicador de sesin o correspondiente a una sesin autenticada. o Abuso del gestor de contraseas: Esta tcnica se basa en intentar extraer la conn e trasea del formulario una vez se introduzca automticamente por el gestor de conn a traseas del navegador. n El ataque se basa en inyectar algo como: Desarrollo Web Avanzado Seguridad Web

4.5 Cross Site Request Forgeries (CSRF).

21

<script> function getPwd(){ alert(document.forms[0].pwd.value); } setTimeout("getPwd();",4000); </script> En un sitio Web en el que existe un formulario de autenticacin, el campo de introo duccin de password posee como name pwd y el usuario ha utilizado el gestor de o contraseas para recordarla. n

4.4.2.

XSS autocontenidos.

Las ultimas versiones de navegadores Web, en concreto Firefox y Opera, incorporan la implementacin del RFC 239717 por medio del cual se pueden especicar urls con el siguo iente formato:

data:[<mediatype>][;base64],<data> Esto permite evitar, por parte del atacante, los controles sobre marcas de formato puesto que estas pueden ir codicadas en base64 como puede verse a continuacin: o

data:text/html;base64,PHNjcmlwdD4KYWxlcnQoIlNlbGYtY29udGFpbm VkIFhTUyIpOwo8L3NjcmlwdD4= Que es equivalente a: <script> alert("Self-contained XSS"); </script>

4.5.

Cross Site Request Forgeries (CSRF).

Descripcin: Un forjado o creacin de peticin cruzada consiste, aprovechando una o o o vulnerabilidad de inyeccin de cdigo HTML, en hacer que el usuario realice, sin o o percatarse, una peticin a determinado sitio. o

17

http://www.ietf.org/rfc/rfc2397.txt

Desarrollo Web Avanzado

Seguridad Web

22

4 Errores de seguridad convencionales.

Ejemplo: Supongamos que un usuario permanece autenticado en, por ejemplo, un webmail, nosotros desde un enlace especialmente diseado, hacemos que cargue una n pgina en la que inyectamos el siguiente cdigo: a o <img src=http://webmail.xx.yy/index.php?cmd=delete&mailbox=Inbox&conrm=false/> Casualmente el cdigo inyectado realiza un borrado de la carpeta de entrada de o correo electrnico de ese usuario en el webmail y puesto que la peticin la realiza o o el navegador del usuario, ste env el identicador de sesin y en consecuencia la e a o accin se ejecuta exitosamente. o Solucin: Nuevamente, el escapado de caracteres especiales debidamente, soluciona o este problema.

4.6.

XPath Injection.
Descripcin: Esta tcnica permite manipular las consultas XPath que se realizan o e contra estructuras de datos XML. Ejemplo: Imaginemos la siguiente consulta

//user[name/text()=$login and password/text()=$pass] si se introduce como login: or 1=1 or =, la consulta XPath resultante se convertir en //user[name/text()= or 1=1 or = and password/text()=] que siempre a devolver tantas entidades como usuarios existan en la estructura XML y por tanto a si se comprobara que el nmero de entidades devueltas es distinto de cero, el atau cante habr conseguido obviar la autenticacin. a o

Solucin: Escapar los caracteres especiales en consultas XPath. o

4.7.

Cross Site Tracing (XST).

Descripcin: Este ataque utiliza el mtodo TRACE del protocolo HTTP para tener o e acceso a las cabeceras que env el cliente. Como ejemplo de aplicacin prctica, a o a supongamos que un cliente posee una cookie establecida con el valor httponly (ver punto 5.4), de forma que no se puede acceder a ella mediante scripting por vulnerabilidades XSS pero, si el servidor tuviera activo este mtodo, se podr construir una e a peticin XMLHttpRequest haciendo uso del mtodo TRACE y la cookie nos ser o e a devuelta en el cuerpo de la respuesta como puede verse en el ejemplo a continuacin. o Ejemplo: Este es un ejemplo de funcionamiento del mtodo TRACE en cuya l e nea 17 podemos apreciar como se devuelve la cookie utilizada en el cuerpo de la respuesta.

Desarrollo Web Avanzado

Seguridad Web

4.8 Session Fixation.

23

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

xst.sh paul@chip:~$ telnet jepsi.org 80 Trying 66.98.168.3... Connected to jepsi.org. Escape character is ^]. TRACE / HTTP/1.1 Host: www.jepsi.org Cookie: id=1234567 HTTP/1.1 200 OK Date: Tue, 17 Jun 2008 14:57:09 GMT Server: Apache Transfer-Encoding: chunked Content-Type: message/http 3d TRACE / HTTP/1.1 Cookie: id=1234567 Host: www.jepsi.org

0 Connection closed by foreign host. Solucin: Este ataque no se puede llevar a cabo por s es necesario un vector de o , ataque como puede ser la explotacin de una vulnerabilidad XSS en la aplicacin. o o Por tanto la solucin aqu pasa por, nuevamente, aplicar las medidas de ltrado de o entradas de forma adecuada. Obviamente, la desactivacin del mtodo TRACE en el lado del servidor, anula la o e posibilidad de explotar esta particularidad.

4.8.

Session Fixation.
Descripcin: Esta tcnica consiste en jar la sesin del usuario previamente y o e o esperar a que se autentique en el sistema. De esta forma, como la sesin la ha o establecido el atacante posee su id y por tanto tiene acceso a esta sesin autenticada. o Ejemplo: El atacante hace que el usuario siga un enlace, bien sea publicndolo en a un foro, envindole un mail o mediante un acceso a una pgina controlada por el ataa a cante que contenga enlaces tipo <img src=http://www.xxx.yy/?sessionid=123456>. Una vez que el usuario accede a esa URL de una forma u otra, se le establece una cookie con ese identicador de sesin y en caso de autenticarse seguidamente en el o sitio al que pertenece la cookie, el atacante ya tendr acceso autenticado. a

Desarrollo Web Avanzado

Seguridad Web

24

4 Errores de seguridad convencionales.

Solucin: El no aceptar sesiones que no hayan sido generadas por el servidor, la o regeneracin del identicador de sesin frente a cada peticin o el uso de tokens o o o (vase 3.3) son soluciones posibles. A continuacin mostramos un ejemplo de como e o aceptar unicamente sesiones generadas en el servidor: sessfix.php
1 2 3 4 5 6 7

<? if (!isset($_SESSION[SERVER_GENERATED_SID])) { session_destroy(); // destroy all data in session } session_regenerate_id(); // generate a new session identifier $_SESSION[SERVER_GENERATED_SID] = true; ?>

4.9.

Session Hijacking.
Descripcin: Podemos traducir esta tcnica como secuestro de sesin y consiste en o e o obtener acceso a los datos de la sesin para obtener acceso autenticado a determinado o sitio Web. Ejemplo: En un entorno en el que utilizamos conectividad WIFI, alguien captura todos los paquetes que las mquinas conectadas estas emitiendo, en uno de ellos a encuentra una peticin HTTP generada por nuestra mquina en la que se env una o a a cookie a un sitio Web en el que estamos autenticados. Este usuario, se establece dicha cookie y accede al sitio. Solucin: Las soluciones en este punto pasan por cifrar el canal de comunicaciones o o realizar comprobaciones adicionales sobre el cliente que mantiene la cookie de sesin l o cita. Esta ultima, tiene tambin problemas de seguridad puesto que en una e red abierta cualquiera puede competir con nosotros por la misma direccin IP o si no se adoptan las medidas necesarias.

4.10.

Weak Upload File Checks.

Descripcin: Se comprueba el upload o renombrado de cheros de forma insuciente. o Ejemplo: Permitimos que el usuario suba y nombre sus cheros con extensiones del tipo .php, .php4, .php5, .cgi, .py, .asp, .aspx, etc. Estos cheros, dependiendo de la conguracin del servidor Web, pueden convertirse en ejecutables por mdulos o o interprete del servidor Web por el simple hecho de nombrarse as De esta forma un . atacante que perciba esta situacin podr ejecutar cdigo arbitrario en el servidor. o a o Desarrollo Web Avanzado Seguridad Web

4.11 Allow url fopen.

25

Solucin: Desactivar motores interpretes en los directorios en los que se almacenen o los cheros (i.e. php admin ag engine o para PHP) o realizar comprobaciones restrictivas en cuanto a nombre de cheros, esto es, por ejemplo para imgenes .jpg, a permitir unicamente el upload y renombrado de cheros con extensin .jpg en lugar o de permitir todas las extensiones salvo aquellas que acaben en .php, .php5, etc. Las comprobaciones sobre la extensin y las comprobaciones permisivas tienen probo lemas de seguridad adicionales como veremos en los puntos 4.15 y 4.16

4.11.

Allow url fopen.

Descripcin: Muchos mdulos correspondientes a interpretes de lenguajes de servio o dor, permiten llevar a cabo acciones como esta (en PHP):

le get contents(http://www.xxxxx.yy/a) Por otro lado, muchos programadores cometen el error de implementar sus aplicaciones Web con URLs como esta:

http://www.xxxx.yy/index.php?content=products.php estas dos circunstancias permiten inyectar cdigo en el servidor. o Ejemplo: En la URL anterior, el atacante introduce en vez de la cadena products.php, esta otra: http://www.xxxxx.yy/myphp de forma que su script se incluir en a el script del servidor y se interpretar pudiendo ejecutar cdigo arbitrario. a o Solucin: Deshabilitar esta funcionalidad y no permitir que el usuario pueda modio car los includes que realiza el cdigo del servidor. o

4.12.

Divisin de respuesta HTTP. o

Descripcin: Esta tcnica consiste en hacer que el servidor imprima un carriage reo e turn junto con un line feed seguido de una respuesta especialmente confeccionada por el atacante. De esta forma el atacante, puede conseguir realizar ataques XSS o cache poisoning, stos ultimos, consisten en manipular la cache de los proxy-cache e intermedios si los hubiera, de forma que, despus del ataque, enviarn la informacin e a o manipulada como vlida. a Ejemplo: Supongamos una aplicacin que establece el nombre de usuario en una o cookie obteniendo el mismo de una entrada que ha proporcionado el usuario, en condiciones normales, la cookie se establecer como vemos a continuacin: a o Desarrollo Web Avanzado Seguridad Web

26

4 Errores de seguridad convencionales.

setcook
1 2 3 4

HTTP/1.1 200 OK ... Set-Cookie: usuario=paul ... Pero si el usuario introduce la siguiente cadena paulCRLFHTTP/1.1 200 OKCRLF la respuesta ofrecida por el servidor es la siguiente: setcookspl HTTP/1.1 200 OK ... Set-Cookie: usuario=paul HTTP/1.1 200 OK ... De esta forma, se ha divido la respuesta HTTP en dos confundiendo a proxy caches intermedios los cuales pueden almacenar en cache la segunda respuesta como buena, a partir de entonces servirn esa pgina como si de la original se tratara. a a Solucin: Filtrar correctamente las entradas para no permitir que el usuario pueda o manipular la respuesta del servidor.

1 2 3 4 5 6

4.13.

DNS Rebinding.

Descripcin: La tcnica de DNS rebinding es aprovechable desde Applets en Java, o e aplicaciones Flash y tecnolog similares de cliente. El objetivo principal de esta as tcnica suele ser la realizacin de un escaneo de servicios contra mquinas de una e o a red privada no visible desde Internet. Ejemplo: La secuencia de realizacin de este ataque es la siguiente: o 1. El atacante logra que la v ctima visite un sitio Web controlado por l y sobre e cuyo registro DNS correspondiente al dominio tiene control y ha seleccionado un TTL muy bajo en la conguracin del mismo. o 2. El cliente descarga un applet. 3. Este applet unicamente puede conectarse con el dominio del que se descargo debido a la same origin policy. 4. El atacante cambia el registro DNS para que apunte a un ip correspondiente a la mquina que queremos escanear dentro de la red privada, por ejemplo a 10.0.0.5 5. El applet intenta conectar a todos los puertos de esa mquina y recopila toda a la informacin posible. o Desarrollo Web Avanzado Seguridad Web

4.14 Comprobacin insuciente. o

27

6. El atacante restablece el registro DNS con su informacin original. o 7. El applet conecta de nuevo al servidor para devolver el resultado del escaneo. Solucin: La gestin, a veces impredecible, de la cache de los servidores DNS hace o o que este ataque sea impracticable en la realidad. A pesar de ello, las ultimas versiones de entornos de ejecucin de aplicaciones en cliente (plugin Java, plugin Flash, etc.) o realizan una resolucin de nombre en el despliegue de la aplicacin y cachean el o o resultado para utilizarlo durante toda la sesin. o

4.14.

Comprobacin insuciente. o

Descripcin: Otro de los errores comunes en lo referente a la programacin Web o o es el hecho de no realizar las comprobaciones sucientes, por ejemplo, frente a la autorizacin de usuarios al acceso de algunos recursos. o Ejemplo: En un sitio Web, cuando un usuario se autentica le aparece un enlace que le permite llevar a cabo una accin privilegiada. Cuando otro usuario no autenticado o accede directamente a este enlace a pesar de no estar autenticado, puede realizar la accin privilegiada. o Solucin: Comprobar siempre la autorizacin frente al acceso a un recurso en cada o o script. Una tcnica aconsejable es separar scripts con acciones privilegiadas de aquee llos que no lo son, en la medida de lo posible, e invocar funciones de comprobacin o siempre al inicio de los scripts que requieren autenticacin. o

4.15.

Null Byte.

Descripcin: Esta tcnica se basa en la forma en la que se implementan ciertas o e funcionalidades por parte de los interpretes de cdigo. Cuando se abre un chero o o se realiza una lectura, las llamadas a funciones suelen traducirse a implementaciones nativas en C. Esta tcnica aprovecha esta situacin para introducir una marca de e o n de de cadena 0x0 que tiene el efecto de delimitar el n de la cadena en C, pero no tiene ms signicado que un carcter adicional en lenguajes interpretados. a a Ejemplo: Si por ejemplo utilizamos el lenguaje de programacin Java en el servidor, o podr amos realizar la comprobacin de que un nombre de chero naliza con .jpg o de la siguiente forma: nullbyte.java if (filename.endsWith(".jpg")) { File f = new File(filename); Seguridad Web

1 2 3

Desarrollo Web Avanzado

28

5 Tcnicas de proteccin adicionales. e o

4 5

...

Esta comprobacin se evaluar a true ante la cadena chero secreto.txt %00.jpg o a pero al realizar la apertura del chero, ste se interpretar como chero secreto.txt e a puesto que la cadena contiene un byte nulo aqu Por tanto el chero accedido . nalmente ser este ultimo. a Solucin: Filtrar y eliminar los Null Bytes de la cadena antes de realizar operaciones o de bajo nivel.

4.16.

Apache y mod mime.

Descripcin: Puesto que Apache es uno de los servidores Web ms utilizados para o a servir sitios Web, cabe comentar una particularidad que puede hacer que las comprobaciones sobre cheros no se realicen correctamente. Ejemplo: Cuando nombramos un chero como script.php.xyz, el mdulo encargado o de interpretar el tipo de chero adecuado (mod mime), intenta mapear el tipo .xyz, sino existe, intenta mapear el tipo .php y as sucesivamente. Solucin: Realizar comprobaciones restrictivas sobre los nombres de chero como se o indica en el punto 4.10.

5.

Tcnicas de proteccin adicionales. e o

A travs del documento, se han ido mostrando tcnicas de explotacin de errores de e e o seguridad as como las soluciones a aplicar en cada caso, pero existen vulnerabilidades que tienen relacin, no tanto con los errores de programacin, sino con las aplicaciones o o en s a continuacin, describimos algunas de estas situaciones. , o

5.1.

Captchas, tipos de ataques.

Si nuestra aplicacin posee un formulario de registro, contacto, etc. Podemos sufrir un o ataque automatizado en el que un usuario malintencionado puede insertar cientos de registros invlidos en la BBDD. Para evitar esto, se introducen los captchas, variantes de a la Prueba de Turing18 cuyo objetivo es garantizar o asegurar, en la medida de lo posible que el registro no esta siendo realizado de forma automtica. a
18

http://es.wikipedia.org/wiki/Prueba de Turing

Desarrollo Web Avanzado

Seguridad Web

5.2 Controles anti-spam, ofuscacin JavaScript. o

29

Figura 6: Un ejemplo de Captcha.

Estos captchas deben ser lo sucientemente irregulares para imposibilitar el reconocimiento automtico por programas de reconocimiento de imgenes. Por ejemplo un captcha a a como el presentado en la gura 7 ser fcil de obviar por herramientas automatizadas. a a

Figura 7: Captcha de fcil reconocimiento de forma automatizada. a

5.2.

Controles anti-spam, ofuscacin JavaScript. o

Una prctica habitual de los denominados spammers es la de descargar el contenido de a sitios Web y analizarlos en busca de direcciones de correo electrnico a las que poder o enviar correo basura. Para evitar el anlisis automatizado en busca de direcciones de a correo por estas herramientas existen, al menos, dos opciones recomendables:

Codicar la direccin de correo electrnico indicando al usuario que se debe sustituir o o para obtener el original. Por ejemplo santapau at uji dot es. Como segunda opcin podemos utilizar una codicacin en javascript19 de forma que o o este cdigo transforma un texto ininteligible en la direccin correcta. Este mtodo o o e funciona por el hecho de que los analizadores no suelen incorporar interpretes de javascript y por tanto no encuentran la direccin de correo electrnico en el texto. o o

De estas opciones, la segunda es ms recomendable puesto que algunos analizadores a s poseen la habilidad de sustituir ciertas cadenas como las mostradas en el ejemplo (at y dot) obteniendo as la direccin original. o
19

Podis encontrar un utilidad en: http://members.cox.net/timandbeth/spam/ e

Desarrollo Web Avanzado

Seguridad Web

30

5 Tcnicas de proteccin adicionales. e o

5.3.

Herramientas de auditor a.

Existen diferentes herramientas para comprobar si nuestros desarrollos web son vulnerables a cierto tipo de ataques automatizados. Puesto que la descripcin detallada del uso o de estas herramientas sobrepasa el objetivo de este texto, mencionaremos aqu cada una de ellas junto con una descripcin de las mismas. o

WebScarab20 Herramienta promovida por el OWASP, permite auditar diferentes tipos de errores como SQL injection o XSS entre otros. La herramienta ha sido diseada utilizando un arquitectura de plugins de forma que es bastante simple n incorporar nueva funcionalidad. LiveHTTPHeaders21 Esta herramienta viene implementada en forma de extensin o para Mozilla Firefox y nos permite ver que cabeceras, tanto en la peticin como en o la respuesta, se estn produciendo en cada momento. a Tamper Data22 Esta herramienta tambin es una extensin para Mozilla Firefox, su e o caracter stica principal es que permite manipular las cabeceras relativas al protocolo HTTP antes de enviarlas. Nessus Es una completa herramienta de auditor que no se cie unicamente a la a n auditor web sino que explora otros diversos aspectos como arquitectura de red, a servicios de mail, DNS, etc. Tambin posee una arquitectura de plugins que permite e incorporar fcilmente nuevas funcionalidades. a Fuzzers Pod amos describir un fuzzer como un alimentador de entradas aleatorias de un espacio de posibilidades indicado, es decir, un fuzzer genera entradas aleatorias que se corresponden a determinados criterios y las ofrecen al programa en busca de comportamientos poco usuales.

5.4.

Cookies httponly y secure.

httponly: Este modicador de cookie hace que sta no sea accesible mediante lenguae jes de scripting en el lado del cliente, por tanto solo ser enviada en peticiones HTTP. a secure: Este modicador hace que la cookie slo se env si la conexin por la que o e o va a ser enviada implementa SSL, esto es, utiliza el protocolo https.

20

http://www.owasp.org/index.php/Category:OWASP webScarab Project http://livehttpheaders.mozdev.org/installation.html 22 http://tamperdata.mozdev.org/

21

Desarrollo Web Avanzado

Seguridad Web

5.4 Cookies httponly y secure.

31

Desarrollo Web Avanzado

Seguridad Web

32

Referencias

Referencias
[1] Web Application Security Consortium. http://www.webappsec.org/. 2008. [2] Open Web Application Security Project. http://www.owasp.org/. 2008. [3] Gnu Citizen blog. http://www.gnucitizen.org/blog/self-contained-xss-attacks/. 2008. [4] PortSwigger. http://blog.portswigger.net/2008/05/null-byte-attacks-are-alive-andwell.html. 2008. [5] Dafydd Stuttard and Marcus Pinto, The Web Application Hackers Handbook: Detecting and Exploiting Security Flaws.. Wiley, Octubre 2007.

Desarrollo Web Avanzado

Seguridad Web

REFERENCIAS

33

Reconocimiento - No comercial - Compartir igual: Este material puede ser distribuido, copiado y exhibido por terceros si se muestra en los crditos la autor del mismo. No se e a puede obtener ningn benecio comercial y las obras derivadas tienen que estar bajo los u mismos trminos de licencia que el trabajo original. e

Autor: Pal Santapau Nebot. <santapau@sg.uji.es> u Revisado por: Manuel David Mollar Villanueva, Jacobo Avariento Gimeno.