Modulo Seguridad en Aplicaciones Web 2012 1

1

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA UNAD Escuela de Ciencias Bsicas Tecnologa e Ingeniera Especializacin en Seguridad Informtica / Curso de Seguridad en Aplicaciones Web

SEGURIDAD EN APLICACIONES WEB

233008

CONTENIDO DIDACTICO DEL CURSO

Elaborado por:

Ing. Carlos Alberto Amaya Tarazona

DUITAMA (Boyac).

Enero de 2013

2


ASPECTOS DE PROPIEDAD INTELECTUAL Y VERSIONAMIENTO

GUA DIDCTICA Autor: Carlos Alberto Amaya Tarazona Ingeniero de Sistemas Magister en Software Libre y Administracin de Redes y sistemas Operativos

COMIT DIRECTIVO

Jaime Alberto Leal Afanador Rector

Gloria Herrera Vicerrectora Acadmica y de Investigacin

Roberto Salazar Ramos Vicerrector de Medios y Mediaciones Pedaggicas

Gustavo Velsquez Decano Escuela de Ciencias Bsicas Tecnologa e Ingeniera

Celia del Carmen Lpez Secretaria Acadmica Escuela de Ciencias Bsicas Tecnologa e Ingeniera

Alexandra Aparicio Coordinadora Nacional Ingeniera de Sistemas.

CURSO SEGURIDAD EN APLICACIONES WEB MATERIAL ACADEMICO Primera Edicin

@Copy Right Universidad Nacional Abierta y a Distancia

ISBN

2005 Centro Nacional de Medios para el aprendizaje 2008 Actualizacin: No aplica

3


CONTENIDO

Pg

INTRODUCCION: 9 UNIDAD I: INTRODUCCION A LA SEGURIDAD EN APLICACIONES WEB 11 CAPITULO 1: CONCEPTOS BSICOS DE SEGURIDAD EN 11 APLICACIONES WEB Leccin 1: INTRODUCCION AL PROTOCOLO HTTP 14

1.1 Caractersticas y Funcionamiento 15 1.2 Anlisis de una cabecera HTTP 16 1.3 Mtodos HTTP 19 1.4 Codificacin de la Informacin 21

Leccin 2: VULNERABILIDADES EN APLICACIONES WEB 22 2.1 Como trabajan las aplicaciones web 22 2.2 Arquitecturas mas complejas 23 2.3 Proyecto OWASP y las Vulnerabilidades en Aplicaciones Webs 25 2.4 Sniffeo y codificacin de cabeceras 27 2.5 Inyectando cdigo 28 2.6 CR/LF Injections 28 2.7 XSS y SQL Injections 29 2.8 PHP Injections 30 2.9 Banner Grabbing 31 2.10 HTTP Fingerprinting 32 Leccin 3: HERRAMIENTAS PARA LA DETECCIN DE VULNERABILIDADES 35 3.1 Fiabilidad de los Analizadores Automticos de Vulnerabilidades 35 3.2 Ventajas y Beneficios 36 3.3 Inconvenientes y Desventajas 37 3.4 Criterios de valoracin para herramientas de seguridad web 38 3.4.1 Herramientas Comerciales 38 3.4.2 Herramientas de Cdigo abierto 39 3.4.3 Herramientas de auditora aplicadas a SQL Injection 40 3.4.4 Herramientas de auditora aplicadas a XSS (Ataques de Cross-Site Scripting) Leccin 4: MITOS EN LA SEGURIDAD WEB 43 4.1 Auditora y control de vulnerabilidades 45 4.2 Puntos dbiles 45 4.3 Tipos de Escaners 46 Leccin 5: SISTEMA DE LOGS 46 5.1 Formato del fichero de LOG 47

4


5.2 Anlisis del fichero de LOG 48 5.3 Programas de anlisis de LOGS 49 CAPITULO 2: PROTOCOLOS DE SEGURIDAD PARA APLICACIONES WEB 49 Leccin 6: TIPOS DE ANALISIS 51 6.1 Metodologas de anlisis de seguridad web 51 Leccin 7: ESCALACION DE PRIVILEGIOS EN APLICACIONES WEB 52 Leccin 8: AUTENTICACION Y AUTORIZACION 53 8.1 La Autenticacin 53 8.2 La Autorizacin 55 Leccin 9: EJECUCION DE INSTRUCCIONES DE ACCESO 55 9.1 Codificacin y las validaciones de Entrada / Salida 55 9.2 Gestin de sesiones y usuarios 56 9.3 Gestin de errores y excepciones 57 Leccin 10: CONFIGURACION SEGURA DE SERVIDORES 58 10.1 Organizacin del servidor Web 58 10.2 Organizacin de las aplicaciones Web 59 CAPITULO3: DESARROLLO SEGURO DE APLICACIONES 60 Leccin 11: CONCEPTOS GENERALES PARA EL DESARROLLO SEGURO 60 DE APLICACIONES 11.1 Normas bsicas de seguridad 62 Leccin 12: CONTROLES DE AUTORIZACION DE OBJETOS 64 12.1 Listas de control de acceso (ACL) 66 12.1.1 Configuracin de las ACL 67 12.1.2 Funciones de la ACL 67 Leccin 13: CONSIDERACIONES DE SEGURIDAD EN WEB SERVICES 67 13.1 Exposicin de datos 68 13.2 Pginas privadas y los sistemas de autenticacin 68 13.3 Ataques de fuerza bruta 68 13.4 Espionaje de contraseas (Password sniffing) 69 13.5 Registros persistentes 70 Leccin 14: VALIDACION DE ENTRADAS 70

5


Leccin 15: SQL INJECTION 72 15.1 Variantes de sintaxis 77 15.2 Otras clases de Inyeccin 77 UNIDAD 2: ANALISIS Y DISEO SEGURO DE APLICACIONES WEB 78 CAPITULO 4: AREAS CRITICAS DE DESARROLLO 78 Leccin 16: SECUENCIAS DE COMANDOS EN SITIOS CRUZADOS (XSS) 78 16.1 Tipos de vulnerabilidades XSS 78 Leccin 17: PERDIDA DE AUTENTICACION Y GESTION DE SESIONES 81 Leccin 18: REFERENCIA DIRECTA INSEGURA A OBJETOS 83 Leccin 19: ALMACENAMIENTO CRIPTOGRAFICO INSEGURO 84 Leccin 20: RESTRICCIONES DE ACCESO A URL 86 CAPITULO 5: CICLO DE VIDA DE DESARROLLO SEGURO DEL SOFTWARE (SDLC) Leccin 21: INTRODUCCION A SDLC 88 Leccin 22: Fases de SDLC 89 22.1 Seguridad en la fase de anlisis 90 22.2 Seguridad en la etapa de diseo 91 22.3 Seguridad en la codificacin 92 22.4 Seguridad en la etapa de pruebas 93 22,5 Seguridad en la implementacin 94 Leccin 23: SDLC-IT 95 Leccin 24: APLICACIN DE SDLC 99 Leccin 25: OTRAS VULNERABILIDADES QUE AFECTAN SDLC 101 25.1 Vulnerabilidades de la capa de transporte 102 25.2 Origen de las vulnerabilidades 103 25.3 Herramientas de monitoreo 104 25.4 Sistema de deteccin de intrusos 105 25.5 Tipos de IDS 105 25.6 Herramientas de gestin 107 CAPITULO 6: ATAQUES DE DENEGACION DE SERVICIO (DDoS) APLICACIONES WEB Leccin 26: DENEGACION DE SERVICIO (DoS) / (DDoS) 109

6


26.1 Denegacin De Servicio Distribuido: DDoS 110 26.2 Denegacin De Servicio Distribuido: DDoS 111 26.3 Plataformas afectadas 112 26.4 Caracterizacin de los ataques DoS 112 26.4.1 Uso de IP Source Spoofing 112 26.4.2 Similitud de trfico legtimo 113 Leccin 27: FASES PREVIAS A LA REALIZACION DEL ATAQUE 114 27.1 Actividades previas al ataque (DoS) 114 27.2 Topologa o distribucin fsica 115 27.3 Funcin de ICMP en los ataques DoS 116 27.4 Descubrimiento de usuarios 119 27.5 Informacin del Dominio 119 Leccin 28: FINGERPRINTING 120 28.1 Transmisin en el protocolo de control 120 28.2 Exploracin de puertos 122 28.2.1 Exploracin de puertos UDP 123 28.2.2 Escaneo basado en el protocolo ICMP 124 28.3 Fragmentacin IP 125 Leccin 29: TIPOS DE ATAQUES 129 29.1 ATAQUE TCP/SYN Flooding: 129 29.2 Ataque Broadcast IP Flooding 133 29.3 Smurf 134 29.4 STeardrop 134 29.5 Snork 136 29.6 Ataque Distribuido TRINOO /TRIN00 137 Leccin 30: HERRAMIENTAS QUE AYUDAN A PREVENIR ATAQUES DoS 139 GLOSARIO DE TERMINOS 143 ANEXOS 152 FUENTES DOCUMENTALES 153

7


LISTADO DE TABLAS

Pg

Tabla 1: Cdigos de estado en HTTP 20 Tabla 2: Propiedades de los controles de validacin 65 Tabla 3: Tipos de Amenazas 103 Tabla 4: Mensajes y cdigos del protocolo ICMP 118 Tabla 5: Escenario para un ataque DoS TCP/SYN Flooding 131 Tabla 6: Descripcin de los parmetros del ataque TCP/SYN Flooding 132 Tabla 7: Herramientas de gestin que ayudan a detectar ataques DoS 141 Tabla 8: Herramientas utilizadas 142

LISTADO DE FIGURAS

Pg Figura 1: Niveles superiores de OSI. Origen de vulnerabilidades en sitios 13 web Figura 2: Tecnologas y protocolos de red modelo OSI 14 Figura 3: Operaciones de solicitud respuesta con HTTP 16 Figura 4: Anlisis de cabeceras HTTP 18 Figura 5: Niveles de comunicacin en aplicaciones web 22 Figura 6: Arquitectura de cuatro capas en aplicaciones web 24 Figura 7: OWSP Top 10 2013 26 Figura 8: Banner deteccin FTP 31 Figura 9: Banner grabbing por mtodo HEAD 32 Figura 10: Uso de un Escucha de Red para hallar huellas identificativas 33 de un host en la red Ethernet Figura 11: Uso de un Escucha de Red para hallar huellas identificativas 34 de un host remoto Figura 12: Funciones de auditora en escneres de aplicaciones web. 39 Herramientas comerciales Figura 13: de auditora en escneres de aplicaciones web. 40 Herramientas de cdigo Figura 14: Funciones de auditora en escneres de aplicaciones 41 web para SQL Injection Figura 15: Funciones de auditora en escneres de aplicaciones 42 web para XSS Figura 16: Categora de Vulnerabilidades 44 Figura 17: Formato de fichero de Logs 47 Figura 18: Metodologa de desarrollo seguro 61 Figura 19: Filtrado de paquetes con ACL 66 Figura 20: Formulario de validacin de datos 76 Figura 21: Prdida de Autenticacin 82

8


Figura 22: Almacenamiento criptogrfico inseguro 86 Figura 23: Relacin costo tiempo en el desarrollo de aplicaciones web 88 Figura 24: SDLC 90 Figura 25: Escenario de un Ataque de Denegacin de servicio (DoS) 110 Figura 26: Escenario de un Ataque de Denegacin de servicio Distribudo 111 Figura 27: Estructura de un datagrama IP V 4.0 115 Figura 28: Estructura de un mensaje ICMP 116 Figura 29: Cabecera de un datagrama ICMP 117 Figura 30: Topologa de una red genrica 120 Figura 31: Mecanismo de tres vas 121 Figura 32: Datagrama IP No fragmentado 126 Figura 33: Datagrama IP de 4028 fragmentado con MTU de 1500 bytes 127 Figura 34: Reensamblado de frames en Wireshark 128 Figura 35: Fragmentacin y Reensamblado de 4028 bytes con una MTU 128 de 1500 bytes. Analizado en Wireshark Figura 36: Fragmentacin Reensamblado TCP. Diagrama Flow Graph 129 Figura 37: Escenario para un ataque DoS TCP/SYN Flooding 130 Figura 38: Ataque Broadcast IP Flooding 133 Figura 39: Ataque Smurf 134 Figura 40: Cabecera Paquete IP V 4.0. 135 Figura 41: Ataque DoS Snork 136 Figura 42: Ataque DDoS TRIN00 138 Figura 43: Esquema de comunicaciones de TRIN00 139

9


INTRODUCCIN

Tanto el auge de internet , las Telecomunicaciones, el mundo digital y todo lo que engloba el manejo de datos, han tenido un crecimiento significativo , exponencial y paralelos a las temticas que tienen que ver con la privacidad formacin tanto personal como profesional. En la web encontramos funcionando a tiendas en lnea, redes sociales, negocios que mueven grandes cantidades de dinero, redes de los servicios que habilitan el comercio a nivel internacional que contienen informacin muy delicada de la vida privada de sus miembros. Para dar inicio a este universo de la privacidad y seguridad de la informacin que en la web viaja, el presente contenido acadmico hace relevancia a la necesidad de implementar procedimientos seguros cuando se desarrollan aplicaciones web para compartir y publicar informacin pueden haber muchos puntos de vista pero uno de los ms ms crticos de la seguridad del Internet, lo tienen las piezas que intervienen de forma directa con las masas de usuarios, los servidores web.

Para poder abordar el siguiente contenido acadmico, es necesario tener como base muchos de los conceptos de seguridad abordados en redes de telecomunicaciones, sistemas operativos e informtica forense. Es por ello que el tema de seguridad se debe asimilar como un engranaje en el que intervienen muchas reas y tcnicas cuando se trata de proteger la integridad de la informacin y la privacidad de los datos de los usuarios.-

El contenido que a continuacin se presenta aborda los conceptos y mecanismos fundamentales para la deteccin de vulnerabilidades en aplicaciones web, en las que primero se incluyen temticas bsicas introductorias pero especficas al diseo de aplicaciones web seguras, para luego tratar con los protocolos de seguridad ms usados en aplicaciones web.

Las reas crticas del diseo de aplicaciones web demostrarn que van desde la misma infraestructura en telecomunicaciones, el entorno de implementacin, hasta el cdigo c y los lenguajes de programacin usados para la puesta en marcha de las aplicaciones web. Todo es parte de un ciclo de vida de desarrollo web pero teniendo en cuanta aspectos de seguridad que protegen la forma y el fondo de las aplicaciones.- No se trata de disear y de implementar aplicaciones que solo den una buena imagen y gusto al cliente, sino tambin aspectos de seguridad que minimicen el riesgo de prdida de informacin o de manipulacin de la misma.

10


En cuanto a la utilidad prctica de estos contenidos, alcanza a llevar a que el estudiante sea competente en la identificacin de diseos inseguros en aplicaciones web y que lo lleve a proponer mejoras o planes de contingencia que reduzcan el riesgo. El mdulo, no pretende conceptualizar ni ejercitar al estudiante en el proceso de implementacin de servidores web o soluciones tipo LAMP1, WAMP2

Finalmente el contenido de este mdulo, se encuentra referenciado y apoyado al proyecto OWASP (The Open Web Application Security Project),

, ni ahondarnos en el desarrollo web, que deben ser competencias previas como presaberes a estos contenidos. Tampoco es posible llegar a la prctica o demostracin de cada herramienta que detecte vulnerabilidades o demostrar cada riesgo. Estos son aspectos Tcnicos que se aplican de forma operativa y el curso entindase tiene un carcter acadmico investigativo que lleva al estudiante a formular diseos propios, soluciones y anlisis de todas las herramientas y que lo lleven a detectar vulnerabilidades y controlarlas. Durante el desarrollo del aula, se ejercitarn prcticas que en lo posible toquen cada tema expuesto en los contenidos de este mdulo.

3

1 Disponible en internet desde 2 Disponible en internet desde 3 Disponible en internet desde

como un grupo de expertos en temas de desarrollo y seguridad con las intensiones de plantear proyectos que a su vez trabajaran en temas de seguridad de aplicaciones, buenas prcticas para desarrollo seguro, pruebas de seguridad para software entre otros. Muchas referencias, actividades y experiencias en la temtica de aplicaciones web, estn apoyadas en este proyecto.

11


PRIMERA UNIDAD

INTRODUCCION A LA SEGURIDAD EN APLICACIONES WEB

CAPITULO I

1. CONCEPTOS BSICOS DE SEGURIDAD EN APLICACIONES WEB

:

El enfoque dado a los contenidos, pretende confrontar Mitos que se tienen cuando se tratan vulnerabilidades de aplicaciones web. Uno de ellos es el de no contemplar entornos y escenarios externos, topologas, otras capas del modelo OSI, protocolos y servicios. La seguridad tiene que verse como un todo, en donde cualquier variable puede afectar lo menos pensado. Es por ello que no solo se trata de identificar riesgos en aplicaciones web sino tambin en los equipos (computadores, servidores) que las soportan, las redes por donde viajan los datos y los servicios que los sistemas operativos y las aplicaciones ofrecen. Para dar inicio a este curso que trata los temas de la privacidad y seguridad de la informacin que en la web viaja, el presente contenido acadmico hace relevancia a la necesidad de implementar procedimientos seguros cuando se desarrollan aplicaciones web para compartir y publicar informacin pueden haber muchos puntos de vista pero uno de los ms crticos de la seguridad del Internet, lo tienen las piezas que intervienen de forma directa con las masas de usuarios, los servidores web

No se deja a un lado la seguridad perimetral ni de la infraestructura de telecomunicaciones, que desde las capas inferiores del modelo OSI deben contemplar los diseadores, programadores y administradores de sistemas, hasta las capas superiores, pero si se enfoca este material a que el lector pueda determinar los aspectos funcionales en diseo, arquitectura, conceptualizacin e implementacin de aplicaciones web que medianamente puedan ser seguras o que estn enmarcadas en su implementacin dentro de un protocolo y estndar de funcionamiento medianamente seguro.

Respecto a los servidores web, es comn escuchar sobre fallas en los sistemas de proteccin de los servidores ms frecuentemente utilizados:

12


Apache: Este es el ms comn y ms utilizado en todo el mundo. Adems, es gratuito y de cdigo abierto, as que se podra decir que corre sobre cualquier plataforma 4 Microsoft IIS: Su proveedor es Microsoft, y como servidor de aplicaciones web ha tenido randes avances en seguridad y en servicios.

5

Tomcat: Servidor web tambin llamado Jakarta Tomcat. Funciona como un contenedor de servelets desarrollado bajo el proyecto Jakarta en la Apache Software Foundation. Tomcat. implementa las especificaciones de los servelets y de JavaServer Pages (JSP) de Sun Microsystems.

6

Sun Java System Web Server: Este producto pertenece a la casa Sun, y suele empalarse sobre entorno de este sistema. Sin embargo, como Apache, es multiplataforma, y recientemente Sun ha decidido distribuirlo con licencias de cdigo abierto (BSD concretamente).

7

Ngnix: Este es un servidor Web muy ligero y corre sobre sistemas Unix y Windows. Se ha convertido en el 4 servidor HTTP ms popular de la red y tambin se distribuye bajo licencia BSD.

8

Lighttp: Este servidor Web es otro de los ms ligeros que hay en el mercado. Est especialmente pensado para hacer cargas pesadas sin perder balance, utilizando poca RAM y poca de CPU. Algunas pginas populares que lo usan son Youtube, Wikipedia y otras que soportan gran trfico diariamente. Tambin es gratuito y se distribuye bajo licencia BSD.

9

El material aqu abordado referencia la mayora de los problemas de seguridad en los sitios web que tienen su origen en los niveles superiores del modelo OSI a nivel de aplicacin (Ver figura 1) y que son el resultado de escritura defectuosa de cdigo, que por lo general viene motivada por aspectos de forma en los que el diseador le importa cmo se vea un sitio web o una aplicacin y que tan llamativo y cautivador para el cliente puedan ser, pero no se detallan aspectos de forma en cuanto a seguridad; debemos entender que programar aplicaciones web seguras

O en los lenguajes de programacin en los que son escritas las aplicaciones que son ejecutadas por estos servidores. Es de reconocer, que la mayora de los problemas de vulnerabilidad detectados en servicios web no son provocados por fallas intrnsecas de ninguna de estas partes, ya que una gran cantidad de los problemas se generan por malos usos por parte de los programadores.

4 Disponible en internet dese 5 Disponible en internet desde 6 Disponible en internet desde 7 Disponible en internet desde 8 Disponible en internet desde 9 Disponible en internet desde

13


no es una tarea fcil, ya que requiere por parte del programador, no nicamente mostrar atencin en cumplir con el objetivo funcional bsico de la aplicacin, sino una concepcin general de los riesgos que puede correr la informacin contenida, solicitada y recibida por el sistema.

No quiere decir esto que en los dems niveles no se presenten amenazas y vulnerabilidades que afecten a los sitios web. E la Leccin 25, trataremos aspectos de seguridad en otros niveles y protocolos de la capa OSI que afectan aplicaciones web.

Figura 1: Niveles superiores de OSI, orgenes de vulnerabilidades en sitios web Fuente: El autor

En la figura1, se puede identificar los niveles superiores del modelo OSI donde son tpicas las vulnerabilidades en aplicaciones web.

En la actualidad, aunque existen muchos documentos, publicaciones, estudios basados en prueba y error, comunidades de desarrollo sobre todo en cdigo abierto (comunidades libres), que permiten formar un criterio sobre el tema, no existen acuerdos bsicos sobre lo que se debe o no se debe hacer, y lo que en algunas publicaciones se recomienda, en otras es atacado. Sin embargo, en lo sustancial s existen algunas recomendaciones que son generales y sern las que describo en este documento junto con los ataques ms comunes a aplicaciones web y las tcnicas de defensa a las inicialmente el profesional puede aplicar en primera instancia. Es tarea del profesional que aborde estas temticas, que

14


defina su estrategia de diseo e implementacin segura de sus aplicaciones web basado en experiencias como las que presenta este mdulo y comparto.

En el contenido de este escrito, se tratan temas esenciales de seguridad que se suelen encontrar en las aplicaciones PHP, adems se remiten ejemplos y estrategias para evitar cometer los mismos errores, si bien, la mayora de los problemas (sino es que todos) revisados sern para cdigo PHP, los mismos consejos suelen aplicar para otros lenguajes de tecnologas similares que por lo mismo enfrentan problemas parecidos y cuya solucin es la misma, slo con las variantes propias del lenguaje.

LECCION 1: INTRODUCCION AL PROTOCOLO HTTP:

El modelo TCP/IP cuenta con diversos protocolos en su capa de aplicacin: HTTP, SMTP y FTP son tres de los ms importantes. En principio, cualquiera de ellos puede ser utilizado para la transferencia de mensajes SOAP pero HTML es el protocolo estndar para la web y el ms usado en los servicios web XML. En la figura 2 se observa los protocolos que actan en las respectivas capas del modelo OSI. Todos los protocolos presentan deficiencias en su diseo y por tanto ofrecen de alguna forma vulnerabilidades que afectan las caractersticas de seguridad de una aplicacin web (integridad, disponibilidad, confidencialidad).

Figura 2: Tecnologas y protocolos de red modelo OSI Fuente: El autor

15


El Protocolo de Transferencia de HiperTexto (Hypertext Transfer Protocol) es un sencillo protocolo cliente-servidor que articula los intercambios de informacin entre los clientes web y los servidores HTTP. Es un protocolo del nivel de aplicacin usado para la transferencia de informacin entre sistemas, de forma clara y rpida. Este protocolo ha sido usado por el World-Wide Web desde 1990. La especificacin completa del protocolo HTTP/1.0 est recogida en el RFC 1945.10

10 Disponible en internet desde

Fue propuesto por Tim Berners-Lee, atendiendo a las necesidades de un sistema global de distribucin de informacin como el World Wide Web. El protocolo HTTP se basa en un paradigma de peticiones y respuestas. Un cliente enva una peticin en forma de mtodo, una URI, y una versin de protocolo seguida de los modificadores de la peticin de forma parecida a un mensaje MIME, informacin sobre el cliente y al final un posible contenido. El servidor contesta con una lnea de estado que incluye la versin del protocolo y un cdigo que indica xito o error, seguido de la informacin del servidor en forma de mensaje MIME y un posible contenido 1.1 CARACTERISTICAS Y FUNCIONAMIENTO

Desde el punto de vista de las comunicaciones, HTTP se establece sobre la capa de conexin TCP/IP, y funciona de la misma forma que el resto de los servicios comunes de entornos UNIX: un proceso servidor escucha en un puerto de comunicaciones TCP (por defecto, el 80), y espera las solicitudes de conexin de los clientes web. Una vez que se establece la conexin, el protocolo TCP se encarga de mantener la comunicacin y garantizar un intercambio de datos libre de errores. HTTP se basa en sencillas operaciones de solicitud/respuesta. Un cliente establece una conexin con un servidor y enva un mensaje con los datos de la solicitud. El servidor responde con un mensaje similar, que contiene el estado de la operacin y su posible resultado. Todas las operaciones pueden adjuntar un objeto o recurso sobre el que actan; cada objeto web es identificado por su URL. La figura 3 muestra estas sencillas operaciones de dilogo que genera HTTP cuando se lanza una solicitud de servicio a una aplicacin web.

16


Figura 3: Operaciones de solicitud - respuesta con HTTP Fuente: El autor

Se detalla a continuacin las principales caractersticas del protocolo HTTP:

Toda la comunicacin entre los clientes y servidores se realiza a partir de caracteres US-ASCII de 7 bits.

Permite la transferencia de objetos multimedia, codificando los archivos binarios en cadenas de caracteres. El contenido de cada objeto intercambiado est identificado por su clasificacin MIME.

Existen ocho verbos que permiten que un cliente pueda dialogar con el servidor. Los tres ms utilizados son: GET, para recoger un objeto, POST, para enviar informacin al servidor y HEAD, para solicitar las caractersticas de un objeto (por ejemplo, la fecha de modificacin de un documento HTML).

17


Cada operacin HTTP implica una conexin con el servidor, que es liberada al trmino de la misma. Es decir, en una operacin se puede recoger un nico objeto. Con la versin HTTP 1.1 se ha mejorado este procedimiento, permitiendo que una misma conexin se mantenga activa durante un cierto periodo de tiempo de forma que sea utilizada en sucesivas transacciones. Este mecanismo, denominado HTTP Keep Alive, es empleado por la mayora de los clientes y servidores modernos.

No mantiene estado. Cada peticin de un cliente a un servidor no es influida por las transacciones anteriores. El servidor trata cada peticin como una operacin totalmente independiente del resto.

Cada objeto al que se aplican los verbos del protocolo est identificado a travs de un localizador uniforme de recurso (URL) nico.

Cada vez que un cliente realiza una peticin a un servidor, se ejecutan los siguientes pasos:

1. Un usuario accede a una URL, seleccionando un enlace de un documento HTML o introducindola directamente en el navegador.

2. El cliente web descodifica la URL, separando sus diferentes partes. As identifica el protocolo de acceso, la direccin DNS o IP del servidor, el puerto (de carcter opcional; el valor por defecto es 80) y el objeto requerido del servidor.

3. Se abre una conexin TCP/IP con el servidor, llamando al puerto TCP correspondiente.

4. Se realiza la peticin. Para ello, se enva el comando necesario (GET, POST, HEAD,), la direccin del objeto requerido (el contenido de la URL que sigue a la direccin del servidor), la versin del protocolo HTTP empleada y un conjunto variable de informacin, que incluye datos sobre las capacidades del navegador, datos opcionales para el servidor, etc.

5. El servidor devuelve la respuesta al cliente. Consiste en un cdigo de estado y el tipo de dato MIME de la informacin de retorno, seguido de la propia informacin.

18


6. Se cierra la conexin TCP. Si no se utiliza el modo HTTP Keep Alive, este

proceso se repite para cada acceso al servidor HTTP.

El dilogo con los servidores HTTP se establece a travs de mensajes formados por lneas de texto, cada una de las cuales contiene los diferentes comandos y opciones del protocolo. Solo existen dos tipos de mensajes, uno para realizar peticiones y otro para devolver la correspondiente respuesta.

1.2 ANALISIS DE UNA CABECERA HTTP:

Realizando una peticin HEAD al sitio web www.unad.edu.co como se muestra en la figura 4, identificaremos las cabeceras HTTP. El ejercicio se realiza desde una sesin de consola en un sistema operativo BackTrack 5 con permisos de root y accediendo a la web mediante una conexin ADSL sin restricciones o puertas traseras firewalls configurados y sin restriccin de puertos.

Figura 4: Anlisis de cabeceras HTTP Fuente: El autor

Al realizar la peticin al sitio web, el servidor nos manda el cdigo de respuesta [2] 200. Los cdigos de rango 2xx indican que la operacin se ha realizado con xito, Cache-Control: Genera las directivas que deben ser usadas por cualquier mecanismo a lo largo de la peticin/respuesta. Connection: Indica que la conexin se cierra, no se mantiene como en keep-alive Date: Fecha y hora actual. Server: Indica el tipo de S.O que corre en el servidor (Vease /.0x07)

19


Content-Length: Campo que indica el tamao del cuerpo del documento o, en decimal, enviado al destinatario que hubiera enviado la peticin. ContenrtType: Tipo de contenido y codificacin del archivo al que realizamos la peticin Expires: Muestra la fecha en la que va caducar la cache de nuestra peticin. Set-Cookie: Es la coockie que nos enva la pagina a la que hemos realizado la peticin, en ella aparece su ID. Su fecha de expiracin, sobre que directorio acta y el dumio desde donde se ha obtenido.

1.3 METODOS HTTP:

Los mtodos HTTP ms comunes y los ms usados son los que a continuacin se mencionan. Es importante identificarlos ya que son los ms manipulados en la aplicacin en ataques y tcnicas de PenTesting y de snifeo de cabeceras HTTP.

GET: Sirve para recoger cualquier tipo de informacin del servidor. Se utiliza siempre que se pulsa sobre un enlace o se teclea directamente a una URL. Como resultado, el servidor HTTP enva el documento ubicado en la direccin especificada por dicha URL. HEAD: Es un comando similar a GET pero que pide solamente la cabecera del objeto. Lo utilizan principalmente los gestores de cachs de pginas o los servidores proxy para conocer cundo es necesario actualizar la copia que se mantiene de un fichero. POST: Este comando enva datos de informacin al servidor, normalmente procedentes de un formulario web, para que el servidor los administre o los aada a una base de datos. PUT: Almacena un objeto en la URL especificada. Si la direccin de destino ya contena un objeto, se considera que se est enviando una versin actualizada del mismo. DELETE: Elimina el objeto especificado. Este comando es muy poco utilizado. TRACE: Realiza un eco de la solicitud recibida para que el cliente pueda conocer qu servidores intermedios estn aadiendo informacin o modificando la peticin. OPTIONS: Devuelve los mtodos HTTP que soporta el cliente. Se suele utilizar para comprobar la funcionalidad de un servidor web. CONNECT: Se utiliza en los servidores proxy que puedan establecer un tnel dinmicamente (por ejemplo, un tnel SSL). Ante cada transaccin con un servidor HTTP, ste devuelve un cdigo numrico en la primera lnea del mensaje de respuesta que informa sobre el resultado de la operacin. Estos cdigos aparecen en algunos casos en la pantalla del cliente, cuando se produce un error. Los cdigos de estado estn clasificados en cinco categoras:

1xx: Mensajes informativos. 2xx: Mensajes asociados con operaciones realizadas correctamente.

20


3xx: Mensajes de redireccin, que informan de operaciones complementarias que se deben realizar para finalizar la operacin.

4xx: Errores del cliente; el requerimiento contiene algn error, o no puede ser realizado.

5xx: Errores del servidor, que no ha podido llevar a cabo una solicitud. En la siguiente tabla podemos ver una lista con los cdigos que se utilizan con mayor frecuencia:

La tabla 1 muestra los cdigos de estado ms comunes en una conversacin establecida con el protocolo HTTP. Estos cdigos son los que generalmente se modifican en interceptaciones o ataques a servicios HTTP y sern parte del anlisis en los ejercicios propuestos del curso.

CODIGO ACCION DESCRIPCION 200 OK Operacin realizada satisfactoriamente 201 Created La operacin ha sido realizada correctamente, y como resultado se ha creado

un nuevo objeto, cuya URL de acceso se proporciona en el cuerpo de la respuesta. Este nuevo objeto ya est disponible.

202 Accepted La operacin ha sido realizada correctamente, y como resultado se ha creado un nuevo objeto, cuya URL de acceso se proporciona en el cuerpo de la respuesta. El nuevo objeto no est disponible por el momento. En el cuerpo de la respuesta se debe informar sobre la disponibilidad de la informacin.

204 No Content La operacin ha sido aceptada, pero no ha producido ningn resultado de inters. El cliente no deber modificar el documento que est mostrando en este momento.

301 Moved Pemanently

El objeto al que se accede ha sido movido a otro lugar de forma permanente. El servidor proporciona, adems, la nueva URL en el campo Location de la respuesta.

302 Found El objeto al que se accede ha sido movido a otro lugar de forma temporal. El servidor proporciona, adems, la nueva URL en el campo Location de la respuesta. El cliente no debe modificar ninguna de las referencias a la URL errnea.

304 Not Modified Se devuelve cuando se hace un GET condicional y el documento no ha sido modificado

400 Bad Request La peticin tiene un error de sintaxis y no es entendida por el servidor. 401 Unauthorized La peticin requiere una autorizacin especial, que normalmente consiste en

un nombre y clave que el servidor verificar. El campo WWW-Autenticate informa de los protocolos de autentificacin aceptados para este recurso.

403 Forbidden Est prohibido el acceso a este recurso. No es posible utilizar una clave para modificar la proteccin.

404 Not Found La URL solicitada no existe, no est disponible o no se encuentra. 500 Internal Server

Error El servidor ha tenido un error interno, y no puede continuar con el procesamiento.

501 Not Implemented

El servidor no tiene capacidad, por su diseo interno, para llevar a cabo el requerimiento del cliente.

502 Bad Gateway El servidor, que est actuando como proxy o pasarela, ha encontrado un error al acceder al recurso que haba solicitado el cliente.

503 Service Unavailable

El servidor est actualmente deshabilitado y no es capaz de atender el requerimiento.

Tabla 1: Cdigos de estado en HTTP Fuente:

21


1.4 CODIFICACION DE LA INFORMACION:

Una de las caractersticas de HTTP reside en que la comunicacin entre cliente y servidor se realiza a partir de caracteres US-ASCII de 7 bits. El problema aparece cuando deseamos realizar la transmisin de un archivo binario, cuyo contenido no puede ser representado por este grupo tan reducido de caracteres. Para solventar esta limitacin se utiliza el estndar de Internet MIME (Extensiones de correo de Internet multipropsito). Son una serie de convenciones o especificaciones dirigidas a que se puedan intercambiar a travs de Internet todo tipo de archivos (texto, audio, vdeo, etc.) de forma transparente para el usuario. Una parte importante de MIME est dedicada a mejorar las posibilidades de transferencia de texto en distintos idiomas y alfabetos. La especificacin de este estndar se encuentra recogidas en las RFC 2045, 2046, 2047, 2048 y 2049.11

Los recursos u objetos que actan como entrada o salida de un comando HTTP estn clasificados por su descripcin MIME, que se especifica en el campo de cabecera Content-Type. De esta forma, el protocolo puede intercambiar cualquier tipo de dato sin preocuparse de su contenido. La identificacin MIME permitir que el receptor trate adecuadamente los datos. Existen nueve tipos definidos por la IANA:

12

7 bit: Utilizado por defecto, supone que los archivos son de texto.

application, audio, example, image, message, model, multipart, text y video. Dentro de cada tipo existen multitud de subtipos: (text/html, image/gif, image/jpeg, audio/x-mpeg, video/quicktime). Existen tres mtodos bsicos de codificacin:

Quoted-printable: Se usa para codificar texto con caracteres que excedan de los 7 bits utilizados en US-ASCII. Con esto podremos representar caracteres de otros alfabetos como los idiomas procedentes del latn. Se codifica en 3 caracteres de 7 bits. Por ejemplo, la letra se corresponder con los caracteres =F1.

Base64: Se utiliza para codificar contenido no legible por humanos, como por ejemplo archivos multimedia. Cada 3 octetos se codifican en 4 caracteres que pertenecen a un subconjunto de 64 caracteres imprimibles del US-ASCII.

11 Disponible en internet desde 12 Disponible en internet desde

22


LECCION 2: VULNERABILIDADES EN APLICACIONES WEB:

2.1 COMO TRABAJAN LAS APLICACIONES WEB Iniciemos con una breve descripcin de cmo trabajan e interactan las aplicaciones y servicios web con diferentes componentes y escenarios tecnolgicos. El uso de aplicaciones web es tan comn como tan masificado hoy en da por todo tipo de usuarios, empresas e instituciones. Su uso va desde la simple accin de leer un correo electrnico hasta realizar una compra en lnea o una transaccin bancaria sin importar el cubrimiento de estas aplicaciones, el tamao, diseo, cdigo en que estn realizadas, plataformas y arquitecturas en las que estn montadas. Algo en comn de estas aplicaciones es que la mayora son interactivas, agradables para el usuario, con datos en lnea que se comparten y que ponen a disposicin del usuario. Muchas de ellas soportadas por grandes bases de datos y que usan como canal de distribucin Internet. La forma como una aplicacin web trabaja, a simple vista es sencilla y prctica. Tal vez por ello y sin ser una afirmacin, es que son vulnerables. Po lo general consisten en una base de datos que por decirlo as, est ubicada detrs del sitio web alojado en un servidor y que est escrita en un lenguaje de programacin que es capaz de extraer informacin especfica de esa base de datos por solicitudes y peticiones de los usuarios remotos o locales mediante interacciones dinmicas con esos usuarios o clientes. Cuando se usan bases de datos para la gestin de los mismos en aplicaciones web, es comn que estas aplicaciones estn compuestas por tres niveles: Un nivel de presentacin (un navegador web o motor de bsqueda). Un nivel lgico (un lenguaje de programacin, como C #, ASP, NET, PHP, JSP, etc.). Y un nivel de almacenamiento (base de datos como Microsoft SQL Server, MySQL, Oracle, etc.)

23


Figura 5: Niveles de comunicacin en aplicaciones web. Fuente: El autor

En la (figura 5) se identifica la secuencia de peticiones y operacin de los tres niveles en donde si el navegador Web (el nivel de presentacin, por ejemplo, Internet Explorer, Safari, Firefox, etc) enva peticiones a la capa media (la capa de lgica), que define los servicios, las solicitudes, consultas y actualizaciones de la base de datos (el nivel de almacenamiento). 2.2 UNA ARQUITECTURA MS COMPLEJA: En los ltimos aos, el modelo de tres niveles fue reevaluado y un nuevo concepto basado en la escalabilidad y mantenimiento fue creado. Surge una solucin de cuatro niveles que implica el uso de una pieza de middleware, tpicamente llamado un servidor de aplicaciones, entre el servidor Web y el servidor de aplicaciones de base de datos. Esta nueva capa de abstraccin, consta de un servidor que aloja una interfaz de programacin de aplicaciones (API) para exponer la lgica de negocio y procesos de negocio para uso de los servidores Web. Adems, el servidor de aplicaciones

24


pueden hablar con varias fuentes de datos, incluyendo bases de datos, mainframes u otros sistemas de legado.

Figura 6: Arquitectura de cuatro capas en aplicaciones web.

Fuente: El autor En la Figura 6, el navegador Web (presentacin) enva peticiones a la capa intermedia (lgica), que a su vez llama a la API expuesta del servidor de aplicaciones que residen en la capa de aplicacin y es el que realiza las consultas y actualizaciones de la base de datos (almacenamiento). El usuario ejecuta en el navegador de Internet una consulta y se conecta a http://www.victima. com. El servidor web que reside en la capa de lgica carga una secuencia de comandos del sistema de archivos y se lo pasa a travs de su motor de scripting en el que se analiza y se ejecuta El script llama a una API expuesta desde el servidor de aplicacin que reside en la capa de aplicacin. El servidor de aplicacin abre una conexin con el nivel de almacenamiento usando un conector de base de datos y ejecuta una instruccin SQL en la base de datos. Se devuelven los datos al conector de la base de datos y al servidor de aplicaciones que implementa las reglas de la lgica de aplicacin o negocio antes de devolver los datos al servidor Web que aplica un retoque de (lgica final) antes de la presentacin de los datos en formato HTML en el navegador Web del usuario. La presentacin de la web se hace mediante HTML que le muestra al usuario una representacin grfica de la cdigo Esto sucede de manera instantnea y es transparente para el usuario. Pero por que se dividen las tareas en capas o niveles?: El concepto bsico de una arquitectura estratificada implica dividir una aplicacin en trozos lgicos, o niveles, cada uno de los cuales se le asignan roles. Las capas se pueden localizar

25


(implementar) en diferentes mquinas o en la misma mquina de forma virtualizada o separados el uno del otro. Ventajas: Cuando se dividen las responsabilidades de una aplicacin en mltiples capas hace que sea ms fcil de escalar la aplicacin, permite una mejor distribucin de las tareas de desarrollo entre los desarrolladores, y hace una aplicacin ms fcil de leer dndole incluso enfoque de rehso y de adaptabilidad a otras aplicaciones existentes o nuevas. Le da caractersticas de robustez a las aplicaciones permitiendo eliminar puntos de fallos crticos y nicos que se puedan presentar si la aplicacin sufre una cada total o irreparable. Por ejemplo, la decisin de cambiar de proveedor de bases de datos debe requerir nada ms que algunos cambios en las porciones aplicables de la capa de aplicacin, la presentacin y los niveles lgicos. 2.3 EL PROYECTO OWASP Y LAS VULNERABILIDADES EN APLICACIONES WEB Antes de dar inicio y entrar en la temtica fuerte de la seguridad en aplicaciones web, se trae a la lectura como referencia el proyecto OWASP: El proyecto abierto de seguridad en aplicaciones Web (OWASP por sus siglas en ingls) es una comunidad abierta dedicada a habilitar a las organizaciones para desarrollar, comprar y mantener aplicaciones confiables. Se citan textualmente apartes del mismo proyecto que dejan claro que la temtica es amplia y de trabajo continuo. Este mdulo acadmico que se presenta ac, no pretende abarcar la totalidad de las vulnerabilidades, estrategias, escenarios, herramientas y metodologa usados tanto para detectar, disear, proveer, monitorear y corregir fallos de seguridad en aplicaciones web. Es un referente para que el profesional tome como partida y apoyo para el anlisis de las temticas que ac se presentan. Existen otros proyectos que tratan este tema y de los cuales tambin se han referenciado lecciones en este mdulo, pero con OWASP se pretende que el estudiante lo identifique y derive sus conclusiones, aportes y posiciones con referencia a la temtica. Que mejor que apoyarse en esa experiencia de una comunidad de desarrolladores, empresas, corporaciones, casas fabricantes de software, profesionales de la TICs, para citar este inicio que nos ubica en el contexto de la seguridad en la web y que se aborda de manera acadmica, objetiva, investigativa y como un ejercicio profesional en el rea de la seguridad, as: No sin antes

26


referenciar el OWASP top 10 de 2013 que lo encuentran ac: 13

Figura 7: OWASP Top 10 - 2013

y que es de necesaria lectura antes de continuar.

Fuente: http://owasptop10.googlecode.com/files/OWASP%20Top%2010%20-%202013%20-%20RC1.pdf Con licencia Creative Commons

La gua completa del Top 10, es parte del anexo de este mdulo:

No se detenga en el Top 10. Existen cientos de problemas que pueden afectar la seguridad general de una aplicacin web tal como se ha discutido en la Guia de Desarrollo OWASP.14

13 Disponible en internet con acceso y formato pdf 14 Disponible en internet desde

Este documento es de lectura esencial para cualquiera desarrollando aplicaciones web hoy en da. Una efectiva orientacin en como encontrar vulnerabilidades en aplicaciones web es suministrada en la

27


Guia de Testeo OWASP15 y la Guia de Revision de Codigo OWASP,16

Piense positivamente. Cuando se encuentre preparado para dejar de buscar vulnerabilidades y focalizarse en establecer controles seguros de aplicaciones, OWASP ha producido el

las cuales han sido significativamente actualizadas desde la ltima edicin del Top 10.

Cambio constante. Este Top 10 continuara cambiando. Incluso sin cambiar una lnea de cdigo en su aplicacin, la misma puede ser vulnerable a algo que nadie haya pensado anteriormente. Por favor revise los consejos detallados al final del Top 10 Prximos pasos para Desarrolladores, Verificadores y Organizaciones para mayor informacin.

Application Security Verification Standard (ASVS)17

SDLC Seguro. Aplicaciones Web seguras son solo posibles cuando se utiliza un SDLC Seguro. Para orientacin sobre como implementar un SDLC Seguro, leer el

como una gua para organizaciones y revisores de aplicaciones que detalla los controles de seguridad a verificar en una aplicacin.

Utilice herramientas inteligentemente. Las vulnerabilidades de seguridad pueden ser bastante complejas y encontrarse ocultas en montaas de cdigo. En virtualmente todos los casos, el enfoque mas eficiente y econmico para encontrar y eliminar estas vulnerabilidades es asignar expertos armados de buenas herramientas para realizar esta tarea.

Open Software Assurance Maturity Model (SAMM),18 el cual es una actualizacin significativa al OWASP CLASP Project.19

Estas herramientas pueden venir en forma de Addons o Plugins para diferentes navegadores, que entre los cuales destacan para FireFox, Tamper Data y Live HTTP Headers, o tambin pueden ser programas independientes propietarios o de

2.4 SNIFFEO Y CODIFICACION DE CABECERAS:

La temtica que hasta aqu se ha tratado, ha descrito de forma general el protocolo HTTP y las negociaciones entre cliente-servidor que se establecen a travs de cabeceras, los HTTP Headers.

Para poder trabajar con las cabeceras necesitaremos de una serie de utilidades cuya finalidad es la de interceptar las cabeceras que manda nuestro navegador, para permitir su anlisis o su modificacin. Estas utilidades se denominan sniffers, y funcionan interceptando el trfico que pasa por el puerto 80 (HTTP).

15 Disponible en internet desde 16 Disponible en internet desde 17 Disponible en internet desde 18 Disponible en internet desde 19 Disponible en internet desde

28


cdigo abierto. Estas herramientas son fundamentales para el trabajo con las cabeceras http.

Existen otras formas de trabajar con las cabeceras sin tener que sniffearlas para modificarlas, como por ejemplo aprovechar algn programa que haga negociaciones TCP, como por ejemplo pueden ser Telnet, Putty, o los populares Netcat y CryptCat.

2.5 INYECTANDO CODIGO

Cuando se hace un proceso de sniffing a las cabeceras HTTP, se puede hacer con dos objetivos: Observar los datos que se envan y de ah buscar un posible CSRF (Cross Site Request Forguery) o bien para modificar la cabecera y aadirle cdigo malicioso, el cual provoque en una aplicacin vulnerable una respuesta que no era la que deba.

Se inyecta cdigo a las cabeceras y si se manejan datos procedentes de la cabecera sin realizarles un correcto filtrado, es ah cuando una aplicacin web se vuele ms vulnerable y ms cuando sin restricciones o controles de acceso, se le permite al front-End (usuarios hackers) la modificacin de la cabecera para que la aplicacin web maneje cdigos maliciosos, y ejecute stos, de esta forma podemos convertir a las cabeceras como medio para inyectar sentencias SQL maliciosas, JavaScript, etc. para realizar diversos ataques a una web.

En las siguientes lecciones, se detallarn los procedimientos para detectar inyecciones de cdigo como el SQL Injection

2.6 CR/LF INJECTIONS:

Esta vulnerabilidad hace referencia a un trmino comn: (HTTP Splitting). Hace referencia al manejo de cabeceras con caracteres especiales que trabajan en conjunto llamados CR (Carriage Retun) y LF (Line Feed) que bsicamente traducen un Salto de lnea en el momento de una conversacin o salto de cabecera. En programacin las seales de salto de lnea se plasman con los caracteres de escape \r\n.

Una aplicacin es vulnerable a CR/LF injection cuando no filtra de forma correcta las variables, permitiendo escanear (indagar) en ellas valores prohibidos como lo son stos. Esta vulnerabilidad implica el que un usuario malintencionado pueda

29


manipular a su antojo las cabeceras de un servidor y ms si es bien conocido que la finalizacin de una cabecera se seala con un doble salto de lnea

Es aqu cuando un atacante identificando ese salto de lnea final, provocar la particin de la cabecera, permitiendo colocar junto al doble salto de lnea el cdigo que l considere oportuno, normalmente ser una segunda cabecera.

A la tcnica de truncar o cortar una cabecera para controlar una respuesta del servidor se la denomina HTTP Splitting. Una tcnica derivada del HTTP Splitting puede ser lo que se denomina File Download Injection y consiste en infectar con el cdigo que nosotros deseemos una descarga.

2.7 XSS Y SQL INJECTIONS

Las fallas de inyeccin, ya sea de SQL, LDAP o comandos del sistema operativo, son comunes en aplicaciones Web. La inyeccin ocurre cuando los datos proporcionados por el usuario son enviados e interpretados como parte de una orden o consulta. Los atacantes interrumpen el intrprete para que ejecute comandos no intencionados proporcionando datos especialmente modificados. Esta tcnica es usada para explotar aplicaciones web que no validan la informacin suministrada por el cliente, para generar consultas SQL maliciosas. El proceso de inyeccin requiere de verificar cada parmetros que se enva y se recibe, lo que suele no ser sencillo y muchas veces se puede creer que no es vulnerable una aplicacin que lo es. Se debe chequear cada parmetro de cada script de cada aplicacin. Para el siguiente ejemplo en la que se inyecta el comando (se solicita una informacin): SELECT id FROM usuarios WHERE user=$f_user AND password=$f_pass; Si no se identifica un usuario (campo en blanco en la validacin) o si se typean los parmetros predeterminados de los usuarios: admin, administrator, guest, invitado entre otros, al modificar la injeccin de SQL por: $f_user= or 1=1 -- en las que se usa: ; para ejecutar mltiples queries -- para comentar el final del query construcciones del tipo or = construcciones del tipo numero or 1=1

30


Se podra explotar esta vulnerabilidad de validacin de usuario e ingresar al sistema Ataques de CrossSite Scripting : Las fallas de XSS ocurren cuando una aplicacin toma informacin originada por un usuario y la enva a un navegador Web sin primero validar o codificar el contenido. XSS permite a los atacantes ejecutar secuencias de comandos en el navegador Web de la vctima que pueden secuestrar sesiones de usuario, modificar sitios Web, insertar contenido hostil, etc. Este tipo de ataques han sido explotados para crear poderosos ataques de phishing y de abusos en el navegador donde los atacantes tpicamente se valen de cdigo HTML y de scripts ejecutados en el cliente. Desde la liberacin del lenguaje JavaScript, se previeron los riesgos de permitir a un servidor Web enviar cdigo ejecutable al navegador. Un problema se presenta cuando los usuarios tienen abiertos varias ventanas de navegador, en algunos casos un script de una pgina podra acceder datos en otra pgina u objeto, observando el peligro de que un sitio malicioso intentara acceder datos sensibles de esta forma. 20

20 Tomado de: UNAM CERT; Aspectos Bsicos de la Seguridad en Aplicaciones Web

Poltica sameorigin: Esencialmente esta poltica permite la interaccin entre objetos y pginas, mientras estos objetos provengan del mismo dominio y en el mismo protocolo. Evitando as que un sitio malicioso tenga acceso a datos sensibles en otra ventana del navegador va JavaScript. A partir de entonces se han introducido otros mecanismos y polticas de control en los navegadores y en los lenguajes en el lado del cliente, para proteger a los usuarios de sitios maliciosos. Las vulnerabilidades XSS pueden ser vistas como tcnicas de evasin de las polticas de proteccin. La mayora de casos la variable vulnerable (en el caso de los XSS) suele ser alguna que se utiliza para mostrar alguna informacin tipo IP, User-Agent y dems. Por so la mayora de webs que ofrecen servicios adicionales como el de mostrar el nombre de usuario logueado, mostrar la IP, mostrar zonas horarias, mostrar datos de fecha de inicio de sesin entre otros, datos que suelen ser vulnerables cuando se modifican las cabeceras.

2.8 PHP INJECTIONS

Existen algunos ataques que aprovechan la posibilidad de la aplicacin de subir archivos al servidor. Estos ataques funcionan de la siguiente manera:

31


Generalmente PHP almacena los archivos subidos en un carpeta temporal, sin embargo es comn en las aplicaciones cambiar la localizacin del archivo subido a una carpeta permanente y leerlo en la memoria. Al hacer este tipo de procedimientos debemos revisar el parmetro que har referencia al nombre del archivo, ya que puede ser truqueado a modo de apuntar a archivos de configuracin del sistema (como /etc/passwd en sistemas Unix).

Las aplicaciones invocan comandos externos a travs de un intrprete de comandos. Segn la forma de invocarlos, es posible que un usuario malicioso logre ejecutar un comando externo distinto al esperado. Ej.: uso del caracter ; en Unix o & en Windows.

2.9 BANNER GRABBING

Se le suceder que el sitio web despliegue banners que emiten informacin del sitio. De estos banners no hay que fiarse si no se tienen definidos los scripts filtrados para los usuarios que accedan al sitio. Se define bsicamente banner a la informacin (aplicacin, versin, plataforma sobre la que corre) que trasmite un servicio cuando se trabaja sobre en el.

Un ejemplo de deteccin de esta informacin (se revela el servicio que est disponible, el tipo de servidor montado y el puerto 21 al que responde) es el acceso a servicios ftp. La figura 8 muestra un rastreo al servicio de alojamiento de archivos (descargas) muy tpico del sitio www.hp.com.

Figura 8: Banner deteccin por ftp Fuente: El autor

32


En la figura 9 se aplica un banner grabbing hacia la web www.unad.edu.co: Informacin del tipo de servidor, versin sistema operativo sobre el cual se ejecuta, versin de PHP entre otros.

Figura 9: Banner grabbing por mtodo HEAD Fuente: El autor

El ataque consistira en obtener los encabezados por HEAD desde un navegador y editaros para reenviar peticiones y modificar comportamientos del sitio.

2.10 HTTP FINGERPRINTING

Se trata entonces de obtener informacin de un sistema concreto y de alguna vulnerabilidad especfica. Esto se hace obteniendo su huella identificativa respecto de la pila TCP/IP de los equipos atacados. Esta tcnica es la que se conoce como Fingerprinting y la informacin que puede brindar esta tcnica dentro de las muchas opciones que tiene de descubrir datos de la vctima es la de permitir descubrir de forma muy fiable el sistema operativo que se ejecuta en la maquina analizada. La aplicacin de esta tcnica consiste en la ejecucin de 4 tests (orden de campos al hacer un HEAD, respuesta ante un DELETE, respuesta ante una versin del protocolo HTTP incorrecta, y por ltimo, la respuesta que da el servidor ante un protocolo errneo).

Con los resultados de los mencionados cuatro tests, podremos diferenciar perfectamente entre servidores Apache y los IIS, ya que de cada uno se extrae un resultado diferente ante cada uno de los tests. Adems de las versiones de

33


sistema operativo, puertos abiertos y capas de seguridad implementadas al protocolo HTTP. La informacin que puede brindar esta tcnica dentro de las muchas opciones que tiene de descubrir datos de la vctima son:

Permitir descubrir de forma muy fiable el sistema operativo que se ejecuta en la maquina analizada.

Identificar el tipo de servidor y la versin en la que se soporta el servicio El tipo de servicio que se ejecuta y la versin.

Una de las muchas tcnicas que existen para levantar este tipo de informacin con respecto al levantamiento de una huella identificativa, es el uso de Escuchas de Red o escaners de puertos como la herramienta nmap, con miras a establecer un posible ataque. En la Figura 10 se muestra un escaneo a un host de una red local en busca de su huella identificativa. Se ha identificado informacin con el nmero de puertos cerrados que tiene la vctima, en este caso con la direccin IP 10.1.1.16, los puertos en servicio abiertos, la identificacin del sistema Operativo y la direccin fsica de la interfaz de red. Se ha ejecutado en una consola haciendo uso de nmap como herramienta de exploracin.

Figura 10: Uso de un Escucha de Red para hallar huellas identificativas de un host en la red Ethernet

Fuente: El autor

34


En la Figura 11 se ha realizado la inspeccin de la huella identificativa de un sistema remoto en la web. Es el caso de www.unab.edu.co haciendo uso de un Sniffer como Ettercap. Se identifica el Sistema Operativo del Servidor, en este caso FreeBSD 4.3 que da el servicio, el puerto que est activo con el servicio http en el puerto TCP 80 y el administrador Web que da el servicio: Oracle Aplication Server.

Figura 11: Uso de un Escucha de Red para hallar huellas identificativas de un host remoto Fuente: El autor

Una de las herramientas para realizar estas detecciones y ataques es usar hping2, se puede: evaluar el desempeo de la red utilizando diferentes protocolos, tamaos de paquetes, TOS (type of service, o sea, tipo de servicio), y fragmentacin; realizar descubrimiento de camino utilizando el campo MTU (onda traceroute); transferir archivos (incluso ante reglas de firewall muy fascistas); realizar funciones al estilo `traceroute' pero bajo diferentes protocolos; deteccin remota de OS (`remote OS fingerprinting'); auditar una implementacin de TCP/IP (`TCP/IP stack') en particular; etc. hping2 es una buena herramienta para aprender acerca de TCP/IP.21

21

35


LECCION 3: HERRAMIENTAS PARA LA DETECCION DE VULNERABILIDDES

3.1 FIABILIDAD DE LOS ANAIZADORES AUTOMATICOS DE VULNERABILIDADES WEB

Se llega al punto de definir qu tan fiables los analizadores automticos de vulnerabilidades Web. En primera instancia al gran nmero de herramientas existentes, los diferentes escenarios en que se aplican y en s mismo la casi por decirlo as infinitas vulnerabilidades que se presentan y la no certeza de deteccin y proteccin total.

Los profesionales informticos, empresas, administradores de TICS, diseadores, desarrolladores e incluso usuarios, concentran sus actividades en aspectos de seguridad en emplear, cada vez ms, herramientas para facilitar la ardua tarea de verificar el nivel de seguridad real de una aplicacin web. Nombres como Appscan, Webinspect, Acunetix y otros tantos son cada vez ms conocidos y utilizados por los profesionales en cualquier proyecto de auditora o de pentest. Las ventajas son innumerables pero tambin los riesgos, y es necesario conocerlos y valorarlos a la hora de decidir el presupuesto de que se dispone para analizar si una pgina Web puede ser comprometida, desde el punto de vista de la seguridad, o si, por el contrario, cumplir con su cometido a la perfeccin.

Por Escner Web se entiende cualquier programa con la capacidad de analizar la seguridad de una aplicacin o pgina Web, es decir, debe incluir los siguientes complementos:

a) Un navegador Web para poder interpretar el cdigo HTML, javascript y dems de la propia pgina.

b) Un "spider" o "crawler" para poder detectar toda la estructura de navegacin de la Web (archivos, directorios, ficheros de imgenes, etc.)

c) Un escner propiamente dicho para hallar fallos de configuracin y vulnerabilidades a nivel Web.

d) Un interface de usuario amigable y fcil de utilizar, que permita configurar de forma sencilla la aplicacin y todos los parmetros de anlisis.

36


e) Un generador de reportes que incluya las vulnerabilidades y errores encontrados, su posible impacto para la aplicacin Web y la forma de corregir los mismos de forma genrica.

Existen multitud de herramientas as, comerciales de pago y con licencia GNU, para Windows y para Linux, ms sencillas y ms completas, de desarrolladores conocidos como RedHat, Oracle, Cisco.

3.2 VENTAJAS Y BENEFICIOS

1. Reduccin de costes: el precio y el esfuerzo en horas de revisar una aplicacin Web se reducen considerablemente utilizando herramientas comerciales del tipo de las anteriormente nombradas, Acunetix, Appscan, Webinspect, etc. A pesar de que el precio por licencia de uso es importante, basta realizar unos pocos anlisis y revisiones para amortizar la herramienta. Adems, existen incluso aplicaciones que no son comerciales sino Open Source que tambin son importantes, es el caso de Wapiti22

, Skipfish, Nikto, etc.

2. Disponibilidad y automatizacin: al poder programar y automatizar cualquier anlisis de seguridad, se puede repetir tantas veces como sea necesario para verificar que se han corregido los errores y vulnerabilidades ya detectados. Tambin se puede definir una frecuencia determinada para que se revise una pgina Web concreta una vez al mes, por ejemplo, y comprobar as si ha habido cambios en la misma y detectar incluso anomalas que pudieran indicar un ataque a la pgina en forma de intrusin o Denegacin de Servicio (DoS). Si en un escaneo programado la pgina no est operativa puede ser debido a un ataque de DoS o un problema de disponibilidad no controlado.

3. Constante revisin y mantenimiento de la aplicacin: La mayora de herramientas lo hacen todo, revisan, analizan detectan las vulnerabilidades y errores de configuracin, sugieren soluciones, generan los informes y reportes. Es trabajo del profesional analizar que herramienta aplicar y si le ofrece estos servicios.

22 Disponible en internet dese

37


3.3 INCONVENIENTES Y DESVENTAJAS

1. Gran cantidad de falsos positivos y falsos negativos: dos peticiones iguales en momentos diferentes a la aplicacin Web por parte del escner, pueden generar respuestas distintas que la herramienta puede interpretar de forma errnea y reportar como una vulnerabilidad inexistente. Anuncios, dependencias con otras pginas y aplicaciones, usuarios conectados interactuando con la Web analizada, etc. En multitud de ocasiones la revisin de seguridad se limita a pasar la herramienta automtica y no se verifica la existencia de las vulnerabilidades reportadas, pudiendo ser falsos positivos o indicios de otras vulnerabilidades s presentes pero no detectadas por la herramienta. Tambin, otras veces, la pgina Web analizada presenta diverso cdigo y contenido intil para revisar la seguridad de la misma que una persona puede identificar de forma rpida y sencilla, pero que no lo es tanto para un ordenador y la correspondiente aplicacin automtica. Un ordenador no es capaz de entender la lgica de la aplicacin Web, y el escaneo de seguridad se basa en comprobar la respuesta de la pgina Web ante los controles y tests que tiene predefinidos la herramienta de anlisis como vulnerabilidades ya conocidas.

2. Imposibilidad de encontrar 0days y errores de diseo: al basarse el anlisis en comprobar la respuesta de la pgina Web ante los controles y tests que la herramienta tiene predefinidos como vulnerabilidades ya conocidas, es muy difcil detectar la presencia de errores no conocidos (0days) y que no estn incluidos en la base de datos del escner Web con el que se realiza la revisin de seguridad. Adems, es complicado que un ordenador pueda entender la lgica de la aplicacin, cosa que para un tcnico con conocimientos no supone ningn reto.

3. Problemas con vulnerabilidades de aplicacin conocidas como Cross Site Scripting (XSS) y SQL Injection (SQLi): estas vulnerabilidades en todas sus modalidades (Blind SQLi, Stored XSS, reflected, etc.) presentan multitud de patrones de ataque, y si adems se encuentran por en medio mecanismos de seguridad como WAF, IPS, firewalls y otros, las herramientas automticas no son capaces de modificar sus peticiones para evadir dichos filtros que plantean estos dispositivos de seguridad. En diversas ocasiones, se ha reportado una vulnerabilidad de SQLi estndar como Blind SQL y la solucin para corregirla es ligeramente distinta. Otro

38


problema es que numerosas herramientas automticas no detectan como ataque de SQLi una vulnerabilidad en "ORDER BY", adems es diferente la forma de tratar esta vulnerabilidad en funcin del motor de base de datos existente, ya sea MS SQL, MySQL, PostgreSQL, etc.

4. Riesgos directos para la aplicacin Web: ya no solo por el lmite de peticiones que una herramienta automtica puede lanzar en paralelo contra la aplicacin Web que puede saturar a la misma y dejarla inaccesible para sus usuarios legtimos, sino tambin por el tipo de patrones y pruebas que tiene definidas para encontrar vulnerabilidades. Una de esas pruebas consiste en utilizar la conocida sentencia para detectar vulnerabilidades de SQLi, "or 1=1--". En una peticin de "SELECT" no hay problema pero si eso mismo acompaa a una peticin de "DELETE" quedara una cosa parecida a "DELETE FROM users where id=1 or 1=1 --" con lo que esto supondra para la aplicacin Web. Un tcnico no usara nunca este mtodo de ataque pero an existen muchas herramientas que se sirven de ella como patrn de ataque

Resumiendo, para entornos productivos, lo ms recomendable para disponer de un nivel aceptable de seguridad en las aplicaciones Web es combinar escaneos con herramientas automticas y detectar aquellas vulnerabilidades de bajo nivel ya conocidas, y disponer tambin de tcnicos de seguridad con amplios conocimientos que puedan realizar pruebas manuales especficas para cada aplicacin. No es lo mismo revisar un CMS conocido tipo Wordpress, Joomla, etc. que una pgina Web sin contenido dinmico ni base de datos detrs. Un tcnico puede ajustar las pruebas y los anlisis a realizar en funcin de las necesidades de cada caso, se trata de soluciones no industrializadas

3.4 CRITERIOS DE VALORACION PARA HERRAMIENTAS DE SEGURIDAD WEB

Continuacin se presenta un anlisis de las principales herramientas usadas para deteccin y gestin de riesgos en seguridad de aplicaciones web. Tanto herramientas de cdigo privado como de cdigo libre. Dentro de los parmetros que se han tenido en cuenta para esta evaluacin, se han tenido e cuenta que las vulnerabilidades y las herramientas se han aplicado en sistemas con seguridad perimetral, interna y de entorno bsicas, con conexiones de internet libres sin restricciones, como las que tienen la mayora de usuarios.

El criterio de valoracin fue la primera serie de caractersticas de auditora de cada herramienta soporta. Una herramienta automatizada no puede detectar una exposicin que no puede reconocer (al menos no directamente, y no sin un

39


anlisis manual), y por lo tanto, el nmero de caractersticas de auditora afectar la cantidad de exposiciones que la herramienta ser capaz para detectar (suponiendo que la funcin de auditora se aplican adecuadamente, que los puntos vulnerables de entrada ser detectado y que la herramienta se encargar de escanear los vectores de entrada vulnerables).

Las herramientas evaluadas fueron a nivel de aplicacin, en cuanto a la deteccin de los riesgos que se podran presentar para atacar a la aplicacin web, y el ataque a los clientes legtimos.

3.4.1 Herramientas Comerciales: El nmero de funciones de auditora en escneres de aplicaciones Web - Herramientas Comerciales.

Figura 12: Funciones de auditora en escneres de aplicaciones web. Herramientas comerciales Fuente:

3.4.2 Herramientas de cdigo Abierto: El nmero de funciones de auditora en escneres de aplicaciones Web - Herramientas de cdigo abierto.

40


Figura 13: Funciones de auditora en escneres de aplicaciones web. Herramientas de cdigo abierto

Fuente:

3.4.3 Herramientas de auditora aplicadas a SQL INJECTION

El anlisis aplica a las herramientas que pueden detectar de SQL Injection, una de las exposiciones ms famosas en ataques comnmente aplicado en los escneres de aplicaciones web. El anlisis siguiente es producto de la evaluacin de que tan buenas son las herramientas en la deteccin de riesgos de inyeccin SQL, partiendo de un punto sin ningn tipo de restricciones que pueden impedir que la herramienta funcione correctamente.

41


La evaluacin se realiz en una aplicacin que utiliza MySQL 5.5.x como su repositorio de datos, y por lo tanto, reflejar la exactitud de la deteccin de la herramienta cuando se escanean los repositorios de datos similares.

La barra azul representa el caso vulnerable prueba de precisin de deteccin, mientras que la barra roja representa falsas categoras positivas detectadas por la herramienta.

Herramientas de cdigo privado

Herramientas de cdigo abierto

Figura 14: Funciones de auditora en escneres de aplicaciones web para SQL Injection Fuente:

42


3.4.4 Herramientas de auditora aplicadas a XSS (Ataques de CrossSite Scripting)

Para el segundo ataque ms comn implementado en los escneres de aplicaciones web se aplic le mismo procedimiento que en los atajes de SQL Injection.

Herramientas de cdigo privado

Herramientas de cdigo abierto

Figura 15: Funciones de auditora en escneres de aplicaciones web para XSS Fuente:

43


Continuando con la evaluacin de herramientas y aplicando ciertos criterios de efectividad y de aplicabilidad, se adjunta como ANEXOS de este mdulo, los anlisis de ciertas variables que son de importancia analizarlas.

Todas estas herramientas son tan solo un puado entre la cantidad de estrategias, mtodos y utilidades que se pueden seguir para realizar la explotacin de las vulnerabilidades en una aplicacin web. El objetivo es obtener informacin de la aplicacin, tratar de realizar una evaluacin de la vulnerabilidad con el fin de obtener informacin sobre los exploits que se pueden utilizar. Una vez hecho esto, explotar las vulnerabilidades y si es necesario, cargar un backdoor o un script que determine la vulnerabilidad encontrada.

Referencio el WAVSEP (The Web Application Vulnerability Scanner Evaluation Project) como una aplicacin web vulnerable diseado para ayudar a evaluar las caractersticas, la calidad y la precisin de los escneres de vulnerabilidades de las aplicaciones web.23

LECCION 4: MITOS EN LA SEGURIDAD WEB

Siempre se cree que las vulnerabilidades ms comunes como SQL Injection, DDoS y XSS, son las que afectan a las aplicaciones web. Tambin que los errores son por deficiencias en la programacin e implementacin de estas aplicaciones. Se referencian ciertos mitos que desmienten estas apreciaciones y que muestran que tan lejos estamos de la realidad del entorno en que las aplicaciones web se aplican y las vulnerabilidades que las rodean:

El cliente hace las peticiones bsicas del sitio y accede a los links que solo le referencia la pgina o sitio (se asume que el cliente no escarba dentro del sitio).

HTML admite el uso de tags (etiquetas) que manipulan la entradas a la aplicacin, por ejemplo si la aplicacin utiliza campos ocultos para enviar informacin sensible estos pueden ser fcilmente manipulados desde el cliente.

23 Disponible en internet desde

44


La validacin solo se puede realizarse nicamente del lado del cliente con JavaScript (esto es falso) si no se efecta ninguna validacin del lado del servidor, cualquier atacante que evite esta validacin (para nada difcil de lograr) tendr acceso total a toda la aplicacin.

Cuando se tiene un sistema y entorno seguro no hay riesgo de vulnerabilidades. El uso de firewalls es suficiente - como explicamos anteriormente, si el firewall tiene que habilitar los puertos 80 y/o 443 para que la aplicacin sea accesible al exterior, no podr hacer nada para detectar entradas maliciosas del cliente, y por supuesto no es proteccin contra ataques internos.

El uso de SSL es una solucin suficiente - SSL simplemente cubre el request/response HTTP dificultando la intercepcin del trfico entre cliente y servidor, pero no agrega seguridad al servidor ni evita el envo de cdigo malicioso desde el cliente.

Otro Mito es el que los desarrolladores y tcnicos encargados de la seguridad enmarcan dentro de solo las supuestas cinco vulnerabilidades ms comunes, dejando a un lado las estrategias de prevenir, analizar, detectar y sobre todo disear aplicaciones expuestas a otro tipo de vulnerabilidades.

Figura 16: Categora de Vulnerabilidades Fuente: El Autor

45


4.1 AUDITORA Y CONTROL DE VULNERABILIDADES:

Muchas empresas slo realizan el escaneo de vulnerabilidades para los periodos de las famosas auditoria seguridad informticas y quizs rara vez, generalmente como una vez al ao. Este es un gran error; no slo se deben realizar las actualizaciones a las redes de forma frecuente, si no que hay que saber que nuevas vulnerabilidades se descubren semanalmente por no decir de forma diaria. Para organizaciones muy grandes, es importante realizar el escaneo de vulnerabilidades como parte del anlisis de seguridad regular con una mayor cantidad de escaneos, mucho ms frecuente (un ejemplo podra ser realizar el escaneo de vulnerabilidades, de forma exhaustiva, cada 4 meses, o sea unas 3 veces al ao).

4.2 PUNTOS DEBILES:

Los hackers siempre quieren encontrar el acceso ms fcil a las redes de las organizaciones valindose de una variedad de tcnicas diferentes. Pero una caracterstica que todos los atacantes hackers tienen en comn es su deseo de buscar los puntos dbiles de una red, cul de ellos puedan usar para lanzar ataques con el mnimo esfuerzo.

Un ladrn normal busca una puerta abierta en una casa, un ladrn de autos busca el vehculo en donde el conductor se haya dejado la llave olvidada, un hacker puede examinar mltiples redes para encontrar la que le proporcione un acceso rpido y simple. Esta situacin plantea un desafo para los administradores de redes que, para combatir a los hackers, deben comenzar a pensar como ellos.

Con referencia a lo anterior, un aspecto que siempre se debe cuidar es evitar que en nuestro sistema se Exploren puertos:

Exploracin de puertos: El escaneo o exploracin de puertos permite determinar las caractersticas de una red o sistemas remotos, con el objetivo de identificar los equipos disponibles y alcanzables desde Internet, as como los servicios que ofrece cada uno. Se puede llegar a conocer los sistemas existentes, los servicios ofrecidos por ellos, cmo estn organizados los equipos, que sistemas operativos ejecutan y cual es le propsito de cada uno. Una herramienta de cdigo abierto que sirve para efectuar rastreo de puertos es nmap.

Con la herramienta hping2 en el modo SCAN (-8 --scan): Permite realizar anlisis de puertos, se pueden especificar distintas opciones para los puertos, rangos, excluir determinados puertos, los puertos incluidos en /etc/services, etc.

46


4.3 TIPOS DE ESCANERS:

Parte de los mitos que rodean la seguridad en aplicaciones web, est el que aplican los tcnicos, administradores de red, desarrolladores y profesionales, que les llevan a pensar que solo se deben implementar escneres que detecten riesgos en las capas superiores del modelo OSI, La seguridad de la informacin es un conjunto engranado que enmarca todos los aspectos en comunicacin, transferencia, trato de informacin. Es por ello que se deben aplicar escner de este tipo para que medianamente se puedan minimizar riesgos y maximizar la seguridad:

Escner de Red: escner de uso general usado para encontrar vulnerabilidades potenciales en la red de la empresa. (Tambin se podra incluir a los escaners de redes VoIP)

Escner de Puerto: software diseado para buscar en una red los puertos abiertos que podran ser usados por los atacantes como puntos de entrada.

Escner para la Seguridad de aplicaciones web: Permite a los negocios realizar evaluaciones de riesgo para identificar las vulnerabilidad en aplicaciones web y as evitar ataques. Este tipo de escaners deben ser utilizados tambin por el departamento de desarrollo (programacin) de una aplicacin web, ayudando as a encontrar todos los bugs que puedan generarse durante la creacin de la aplicacin, antes de poner la aplicacin a un entorno de produccin.

Escner de Base de datos: permite encontrar puntos dbiles en bases de datos, protegiendo as el activo ms importante de una empresa.

LECCION 5: SISTEMA DE LOGS

La auditora y el registro de los eventos que suceden al ejecutar nuestras aplicaciones nos permite monitorizarlas y detectar posibles intentos de ataques o intrusiones.

Un log es un registro oficial de eventos durante un rango de tiempo en particular. Para los profesionales en seguridad informtica se utiliza para registrar datos o informacin sobre quin, qu, cundo, dnde y por qu un evento ocurre en un dispositivo en particular o aplicacin.

47


La mayora de los logs son almacenados o desplegados en el formato estndar, el cual es un conjunto de caracteres para dispositivos comunes y aplicaciones. De esta forma cada log generado por un dispositivo en particular puede ser ledo y desplegado en otro diferente.

Tambin se le considera como aquel mensaje que genera el programador de un sistema operativo, alguna aplicacin o algn proceso, en virtud del cual se muestra un evento del sistema. 24

Figura 17: Formato de fichero de Logs Fuente:

Los sistemas de los deben garantizar la monitorizacin de los eventos que se producen en la aplicacin y asegurar la informacin de los ficheros de registro.

5.1 FORMATO DEL FICHERO DE LOG:

Por norma general, los servidores web guardan los registros en un formato llamado Common Log Format. Los servidores que no usan dicho formato por defecto suelen incluir una opcin para usarlo. El formato Common Log Format es el siguiente:

24 Disponible en internet dese

48


Existen variantes extendidas que se aplican a estos formatos. Variantes que dependen del sistema usado y que generalmente en herramientas de tipo IDS con cdigo abierto, el administrador de la red puede modificar y parametrizar para obtener la informacin deseada.

5.2 ANALISIS DEL FICHERO DE LOG:

Mucha informacin que suministran estos ficheros de registro, no son claros y requieren que se asocien a otros para poderlos interpretar. Lo ms comn es encontrar los siguientes datos:

Nmero de peticiones recibidas (hits). Volumen total en bytes de datos y ficheros servidos. Nmero de peticiones por tipo de fichero (por ejemplo, HTML). Direcciones de clientes diferentes atendidas y peticiones para cada una de

ellas. Nmero de peticiones por dominio (a partir de direccin IP). Nmero de peticiones por directorio o fichero. Nmero de peticiones por cdigo de retorno HTTP. Direcciones de procedencia (referrer). Navegadores y versiones de stos usados.

A pesar de que las informaciones que podemos obtener del anlisis de los ficheros de log son numerosas, hay unas cuantas que no podemos obtener. De ellas, algunas resultaran de especial inters:

Identidad de los usuarios, excepto en aquellos casos en los que el usuario se identifique por peticin del servidor.

Nmero de usuarios. A pesar de tener el nmero de direcciones IP distintas, no

Modulo Seguridad en Aplicaciones Web 2012 1

Documents

Transcript of Modulo Seguridad en Aplicaciones Web 2012 1