Seguridad Web

Universidad Jaume I

Desarrollo Web Avanzado

Seguridad Web

2


Seguridad Web

INDICE

3

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 guras1. 2. 3. Clasicacin por objetivo de los atacantes. . . . . . . . . . . . . . . . . . . o A quin se ataca. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . e Vulnerabilidades o tipos de ataques utilizados. . . . . . . . . . . . . . . . . 8 8 9


Seguridad Web

4

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


Seguridad Web

INDICE DE FIGURAS

5


Seguridad Web

6

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. e1 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


Seguridad Web

7

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. o6

5


Seguridad Web

8

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

9

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. aEntrada 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.php1 2 3 4 5 6 7

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


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 a10 11

Pgina del proyecto JAD a Pgina del proyecto Flash Decompiler a


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


Seguridad Web

14


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 a14 15

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


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 Injection alterando el resule tado nal. htmlinj.php

1 2 3 4 5 6 7 8 9

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

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 %


Seguridad Web

4.4 Cross Site Scripting (XSS).

19

...

Hasta obtener el nombre de usuario correcto. bsqlinj.php1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

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 alert(document.cookie); 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

Seguridad Web

Documents

Transcript of Seguridad Web