SEGURIDAD EN APLICACIONES WEB

Tamaño: px
Comenzar la demostración a partir de la página:

Download "SEGURIDAD EN APLICACIONES WEB"

Transcripción

1 SEGURIDAD EN APLICACIONES WEB Autor: Carlos Alberto Amaya Tarazona Ingeniero de Sistemas Magister en Software Libre y Administración de Redes y sistemas Operativos 1

2 CONTENIDO Pág INTRODUCCIÓN: 5 UNIDAD I: INTRODUCCIÓN A LA SEGURIDAD EN APLICACIONES WEB 10 CAPITULO 1: CONCEPTOS BÁSICOS DE SEGURIDAD EN 10 APLICACIONES WEB Lección 1: INTRODUCCIÓN AL PROTOCOLO HTTP Características y Funcionamiento Análisis de una cabecera HTTP Métodos HTTP Codificación de la Información 17 Lección 2: VULNERABILIDADES EN APLICACIONES WEB Como trabajan las aplicaciones web Arquitecturas más complejas Proyecto OWASP y las Vulnerabilidades en Aplicaciones Webs Sniffeo y codificación de cabeceras Inyectando código CR/LF Injections XSS y SQL Injections PHP Injections Banner Grabbing HTTP Fingerprinting 28 Lección 3: HERRAMIENTAS PARA LA DETECCIÓN DE VULNERABILIDADES Fiabilidad de los Analizadores Automáticos de Vulnerabilidades Ventajas y Beneficios Inconvenientes y Desventajas Criterios de valoración para herramientas de seguridad web Herramientas Comerciales Herramientas de Código abierto Herramientas de auditoría aplicadas a SQL Injection Herramientas de auditoría aplicadas a XSS (Ataques de Cross-Site Scripting) Lección 4: MITOS EN LA SEGURIDAD WEB Auditoría y control de vulnerabilidades Puntos débiles Tipos de Escaners 42 Lección 5: SISTEMA DE LOGS Formato del fichero de LOG Análisis del fichero de LOG 43 2

3 5.3 Programas de análisis de LOGS 44 CAPITULO 2: PROTOCOLOS DE SEGURIDAD PARA APLICACIONES WEB 44 Lección 6: TIPOS DE ANÁLISIS Metodologías de análisis de seguridad web 45 Lección 7: ESCALACION DE PRIVILEGIOS EN APLICACIONES WEB 45 Lección 8: AUTENTICACIÓN Y AUTORIZACIÓN La Autenticación La Autorización 51 Lección 9: EJECUCIÓN DE INSTRUCCIONES DE ACCESO Codificación y las validaciones de Entrada / Salida Gestión de sesiones y usuarios Gestión de errores y excepciones 53 Lección 10: CONFIGURACIÓN SEGURA DE SERVIDORES Organización del servidor Web Organización de las aplicaciones Web 55 CAPITULO3: DESARROLLO SEGURO DE APLICACIONES 56 Lección 11: CONCEPTOS GENERALES PARA EL DESARROLLO SEGURO 56 DE APLICACIONES 11.1 Normas básicas de seguridad 58 Lección 12: CONTROLES DE AUTORIZACION DE OBJETOS Listas de control de acceso (ACL) Configuración de las ACL Funciones de la ACL 63 Lección 13: CONSIDERACIONES DE SEGURIDAD EN WEB SERVICES Exposición de datos Páginas privadas y los sistemas de autenticación Ataques de fuerza bruta Espionaje de contraseñas (Password sniffing) Registros persistentes 66 Lección 14: VALIDACIÓN DE ENTRADAS 66 3

4 Lección 15: SQL INJECTION Variantes de sintaxis Otras clases de Inyección 69 LISTADO DE FIGURAS Figura 1: Niveles superiores de OSI. Origen de vulnerabilidades en sitios 9 web Figura 2: Tecnologías y protocolos de red modelo OSI 11 Figura 3: Operaciones de solicitud respuesta con HTTP 13 Figura 4: Análisis de cabeceras HTTP 15 Figura 5: Niveles de comunicación en aplicaciones web 19 Figura 6: Arquitectura de cuatro capas en aplicaciones web 21 Figura 7: OWSP Top Figura 8: Banner detección FTP 29 Figura 9: Banner grabbing por método HEAD 29 Figura 10: Uso de un Escucha de Red para hallar huellas identificativas 30 de un host en la red Ethernet Figura 11: Uso de un Escucha de Red para hallar huellas identificativas 31 de un host remoto Figura 12: Funciones de auditoría en escáneres de aplicaciones web. 36 Herramientas comerciales Figura 13: de auditoría en escáneres de aplicaciones web. 37 Herramientas de código Figura 14: Funciones de auditoría en escáneres de aplicaciones 38 web para SQL Injection Figura 15: Funciones de auditoría en escáneres de aplicaciones 40 web para XSS Figura 16: Categoría de Vulnerabilidades 41 Figura 17: Formato de fichero de Logs 44 Figura 18: Metodología de desarrollo seguro 59 Figura 19: Filtrado de paquetes con ACL 64 Figura 20: Formulario de validación de datos 72 Pág 4

5 INTRODUCCIÓN 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 temáticas que tienen que ver con la privacidad formación tanto personal como profesional. En la web encontramos funcionando a tiendas en línea, redes sociales, negocios que mueven grandes cantidades de dinero, redes de los servicios que habilitan el comercio a nivel internacional que contienen información muy delicada de la vida privada de sus miembros. Para dar inicio a este universo de la privacidad y seguridad de la información que en la web viaja, el presente contenido académico hace relevancia a la necesidad de implementar procedimientos seguros cuando se desarrollan aplicaciones web para compartir y publicar información pueden haber muchos puntos de vista pero uno de los más más críticos 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 académico, es necesario tener como base muchos de los conceptos de seguridad abordados en redes de telecomunicaciones, sistemas operativos e informática forense. Es por ello que el tema de seguridad se debe asimilar como un engranaje en el que intervienen muchas áreas y técnicas cuando se trata de proteger la integridad de la información y la privacidad de los datos de los usuarios.- El contenido que a continuación se presenta aborda los conceptos y mecanismos fundamentales para la detección de vulnerabilidades en aplicaciones web, en las que primero se incluyen temáticas básicas introductorias pero específicas al diseño de aplicaciones web seguras, para luego tratar con los protocolos de seguridad más usados en aplicaciones web. Las áreas críticas del diseño de aplicaciones web demostrarán que van desde la misma infraestructura en telecomunicaciones, el entorno de implementación, hasta el código c y los lenguajes de programación 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 diseñar y de implementar aplicaciones que solo den una buena imagen y gusto al cliente, sino también aspectos de seguridad que minimicen el riesgo de pérdida de información o de manipulación de la misma. 5

6 En cuanto a la utilidad práctica de estos contenidos, alcanza a llevar a que el estudiante sea competente en la identificación de diseños inseguros en aplicaciones web y que lo lleve a proponer mejoras o planes de contingencia que reduzcan el riesgo. El módulo, no pretende conceptualizar ni ejercitar al estudiante en el proceso de implementación de servidores web o soluciones tipo LAMP 1, ó WAMP 2, ni ahondarnos en el desarrollo web, que deben ser competencias previas como presaberes a estos contenidos. Tampoco es posible llegar a la práctica o demostración de cada herramienta que detecte vulnerabilidades o demostrar cada riesgo. Estos son aspectos Técnicos que se aplican de forma operativa y el curso entiéndase tiene un carácter académico investigativo que lleva al estudiante a formular diseños propios, soluciones y análisis de todas las herramientas y que lo lleven a detectar vulnerabilidades y controlarlas. Durante el desarrollo del aula, se ejercitarán prácticas que en lo posible toquen cada tema expuesto en los contenidos de este módulo. Finalmente el contenido de este módulo, se encuentra referenciado y apoyado al proyecto OWASP (The Open Web Application Security Project), 3 como un grupo de expertos en temas de desarrollo y seguridad con las intenciones de plantear proyectos que a su vez trabajaran en temas de seguridad de aplicaciones, buenas prácticas para desarrollo seguro, pruebas de seguridad para software entre otros. Muchas referencias, actividades y experiencias en la temática de aplicaciones web, están apoyadas en este proyecto. 1 Disponible en internet desde <http://www.lamphowto.com/> 2 Disponible en internet desde <http://www.wampserver.com/en/> 3 Disponible en internet desde <https://www.owasp.org/index.php/main_page> 6

7 PRIMERA UNIDAD INTRODUCCIÓN A LA SEGURIDAD EN APLICACIONES WEB CAPITULO I: 1. CONCEPTOS BÁSICOS 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, topologías, 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 también 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 información que en la web viaja, el presente contenido académico hace relevancia a la necesidad de implementar procedimientos seguros cuando se desarrollan aplicaciones web para compartir y publicar información pueden haber muchos puntos de vista pero uno de los más críticos 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 diseñadores, 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 diseño, arquitectura, conceptualización e implementación de aplicaciones web que medianamente puedan ser seguras o que estén enmarcadas en su implementación dentro de un protocolo y estándar de funcionamiento medianamente seguro. Respecto a los servidores web, es común escuchar sobre fallas en los sistemas de protección de los servidores más frecuentemente utilizados: 7

8 Apache: Este es el más común y más utilizado en todo el mundo. Además, es gratuito y de código abierto, así que se podría 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 también 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 código 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 más popular de la red y también se distribuye bajo licencia BSD. 8 Lighttp: Este servidor Web es otro de los más ligeros que hay en el mercado. Está especialmente pensado para hacer cargas pesadas sin perder balance, utilizando poca RAM y poca de CPU. Algunas páginas populares que lo usan son Youtube, Wikipedia y otras que soportan gran tráfico diariamente. También es gratuito y se distribuye bajo licencia BSD. 9 O en los lenguajes de programación en los que son escritas las aplicaciones que son ejecutadas por estos servidores. Es de reconocer, que la mayoría de los problemas de vulnerabilidad detectados en servicios web no son provocados por fallas intrínsecas de ninguna de estas partes, ya que una gran cantidad de los problemas se generan por malos usos por parte de los programadores. El material aquí abordado referencia la mayoría de los problemas de seguridad en los sitios web que tienen su origen en los niveles superiores del modelo OSI a nivel de aplicación (Ver figura 1) y que son el resultado de escritura defectuosa de código, que por lo general viene motivada por aspectos de forma en los que el diseñador le importa cómo se vea un sitio web o una aplicación 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 4 Disponible en internet dese <http://httpd.apache.org/> 5 Disponible en internet desde <http://www.iis.net/> 6 Disponible en internet desde <http://tomcat.apache.org/> 7 Disponible en internet desde <http://docs.oracle.com/cd/e /index.html> 8 Disponible en internet desde <http://nginx.org/en/> 9 Disponible en internet desde <http://www.lighttpd.net/> 8

9 no es una tarea fácil, ya que requiere por parte del programador, no únicamente mostrar atención en cumplir con el objetivo funcional básico de la aplicación, sino una concepción general de los riesgos que puede correr la información contenida, solicitada y recibida por el sistema. No quiere decir esto que en los demás niveles no se presenten amenazas y vulnerabilidades que afecten a los sitios web. E la Lección 25, trataremos aspectos de seguridad en otros niveles y protocolos de la capa OSI que afectan aplicaciones web. Figura 1: Niveles superiores de OSI, orígenes de vulnerabilidades en sitios web Fuente: El autor En la figura1, se puede identificar los niveles superiores del modelo OSI donde son típicas 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 código abierto (comunidades libres), que permiten formar un criterio sobre el tema, no existen acuerdos básicos 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 serán las que describo en este documento junto con los ataques más comunes a aplicaciones web y las técnicas de defensa a las inicialmente el profesional puede aplicar en primera instancia. Es tarea del profesional que aborde estas temáticas, que defina su 9

10 estrategia de diseño e implementación segura de sus aplicaciones web basado en experiencias como las que presenta este módulo y comparto. En el contenido de este escrito, se tratan temas esenciales de seguridad que se suelen encontrar en las aplicaciones PHP, además se remiten ejemplos y estrategias para evitar cometer los mismos errores, si bien, la mayoría de los problemas (sino es que todos) revisados serán para código PHP, los mismos consejos suelen aplicar para otros lenguajes de tecnologías similares que por lo mismo enfrentan problemas parecidos y cuya solución es la misma, sólo con las variantes propias del lenguaje. LECCION 1: INTRODUCCION AL PROTOCOLO HTTP: El modelo TCP/IP cuenta con diversos protocolos en su capa de aplicación: HTTP, SMTP y FTP son tres de los más importantes. En principio, cualquiera de ellos puede ser utilizado para la transferencia de mensajes SOAP pero HTML es el protocolo estándar para la web y el más usado en los servicios web XML. En la figura 2 se observa los protocolos que actúan en las respectivas capas del modelo OSI. Todos los protocolos presentan deficiencias en su diseño y por tanto ofrecen de alguna forma vulnerabilidades que afectan las características de seguridad de una aplicación web (integridad, disponibilidad, confidencialidad). Figura 2: Tecnologías y protocolos de red modelo OSI Fuente: El autor 10

11 El Protocolo de Transferencia de HiperTexto (Hypertext Transfer Protocol) es un sencillo protocolo cliente-servidor que articula los intercambios de información entre los clientes web y los servidores HTTP. Es un protocolo del nivel de aplicación usado para la transferencia de información entre sistemas, de forma clara y rápida. Este protocolo ha sido usado por el World- Wide Web desde La especificación completa del protocolo HTTP/1.0 está recogida en el RFC Fue propuesto por Tim Berners-Lee, atendiendo a las necesidades de un sistema global de distribución de información como el World Wide Web. El protocolo HTTP se basa en un paradigma de peticiones y respuestas. Un cliente envía una petición en forma de método, una URI, y una versión de protocolo seguida de los modificadores de la petición de forma parecida a un mensaje MIME, información sobre el cliente y al final un posible contenido. El servidor contesta con una línea de estado que incluye la versión del protocolo y un código que indica éxito o error, seguido de la información del servidor en forma de mensaje MIME y un posible contenido 1.1 CARACTERÍSTICAS Y FUNCIONAMIENTO Desde el punto de vista de las comunicaciones, HTTP se establece sobre la capa de conexión 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 conexión de los clientes web. Una vez que se establece la conexión, el protocolo TCP se encarga de mantener la comunicación y garantizar un intercambio de datos libre de errores. HTTP se basa en sencillas operaciones de solicitud/respuesta. Un cliente establece una conexión con un servidor y envía un mensaje con los datos de la solicitud. El servidor responde con un mensaje similar, que contiene el estado de la operación y su posible resultado. Todas las operaciones pueden adjuntar un objeto o recurso sobre el que actúan; cada objeto web es identificado por su URL. La figura 3 muestra estas sencillas operaciones de diálogo que genera HTTP cuando se lanza una solicitud de servicio a una aplicación web. 10 Disponible en internet desde <http://www.freesoft.org/cie/rfc/1945/index.htm> 11

12 Figura 3: Operaciones de solicitud - respuesta con HTTP Fuente: El autor Se detalla a continuación las principales características del protocolo HTTP: Toda la comunicación 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 clasificación MIME. Existen ocho verbos que permiten que un cliente pueda dialogar con el servidor. Los tres más utilizados son: GET, para recoger un objeto, POST, para enviar información al servidor y HEAD, para solicitar las características de un objeto (por ejemplo, la fecha de modificación de un documento HTML). 12

13 Cada operación HTTP implica una conexión con el servidor, que es liberada al término de la misma. Es decir, en una operación se puede recoger un único objeto. Con la versión HTTP 1.1 se ha mejorado este procedimiento, permitiendo que una misma conexión 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 mayoría de los clientes y servidores modernos. No mantiene estado. Cada petición de un cliente a un servidor no es influida por las transacciones anteriores. El servidor trata cada petición como una operación totalmente independiente del resto. Cada objeto al que se aplican los verbos del protocolo está identificado a través de un localizador uniforme de recurso (URL) único. Cada vez que un cliente realiza una petición a un servidor, se ejecutan los siguientes pasos: 1. Un usuario accede a una URL, seleccionando un enlace de un documento HTML o introduciéndola directamente en el navegador. 2. El cliente web descodifica la URL, separando sus diferentes partes. Así identifica el protocolo de acceso, la dirección DNS o IP del servidor, el puerto (de carácter opcional; el valor por defecto es 80) y el objeto requerido del servidor. 3. Se abre una conexión TCP/IP con el servidor, llamando al puerto TCP correspondiente. 4. Se realiza la petición. Para ello, se envía el comando necesario (GET, POST, HEAD, ), la dirección del objeto requerido (el contenido de la URL que sigue a la dirección del servidor), la versión del protocolo HTTP empleada y un conjunto variable de información, 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 código de estado y el tipo de dato MIME de la información de retorno, seguido de la propia información. 13

14 6. Se cierra la conexión TCP. Si no se utiliza el modo HTTP Keep Alive, este proceso se repite para cada acceso al servidor HTTP. El diálogo con los servidores HTTP se establece a través de mensajes formados por líneas 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 ANÁLISIS DE UNA CABECERA HTTP: Realizando una petición HEAD al sitio web como se muestra en la figura 4, identificaremos las cabeceras HTTP. El ejercicio se realiza desde una sesión de consola en un sistema operativo BackTrack 5 con permisos de root y accediendo a la web mediante una conexión ADSL sin restricciones o puertas traseras firewalls configurados y sin restricción de puertos. Figura 4: Análisis de cabeceras HTTP Fuente: El autor Al realizar la petición al sitio web, el servidor nos manda el código de respuesta [2] 200. Los códigos de rango 2xx indican que la operación se ha realizado con éxito, Cache-Control: Genera las directivas que deben ser usadas por cualquier mecanismo a lo largo de la petición/respuesta. Connection: Indica que la conexión 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) 14

15 Content-Length: Campo que indica el tamaño del cuerpo del documento o, en decimal, enviado al destinatario que hubiera enviado la petición. ContenrtType: Tipo de contenido y codificación del archivo al que realizamos la petición Expires: Muestra la fecha en la que va caducar la cache de nuestra petición. Set-Cookie: Es la coockie que nos envía la pagina a la que hemos realizado la petición, en ella aparece su ID. Su fecha de expiración, sobre que directorio actúa y el dumio desde donde se ha obtenido. 1.3 MÉTODOS HTTP: Los métodos HTTP más comunes y los más usados son los que a continuación se mencionan. Es importante identificarlos ya que son los más manipulados en la aplicación en ataques y técnicas de PenTesting y de snifeo de cabeceras HTTP. GET: Sirve para recoger cualquier tipo de información del servidor. Se utiliza siempre que se pulsa sobre un enlace o se teclea directamente a una URL. Como resultado, el servidor HTTP envía el documento ubicado en la dirección 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 cachés de páginas o los servidores proxy para conocer cuándo es necesario actualizar la copia que se mantiene de un fichero. POST: Este comando envía datos de información al servidor, normalmente procedentes de un formulario web, para que el servidor los administre o los añada a una base de datos. PUT: Almacena un objeto en la URL especificada. Si la dirección de destino ya contenía un objeto, se considera que se está enviando una versión 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 están añadiendo información o modificando la petición. OPTIONS: Devuelve los métodos 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 túnel dinámicamente (por ejemplo, un túnel SSL). Ante cada transacción con un servidor HTTP, éste devuelve un código numérico en la primera línea del mensaje de respuesta que informa sobre el resultado de la operación. Estos códigos aparecen en algunos casos en la pantalla del cliente, cuando se produce un error. Los códigos de estado están clasificados en cinco categorías: 1xx: Mensajes informativos. 2xx: Mensajes asociados con operaciones realizadas correctamente. 15

16 3xx: Mensajes de redirección, que informan de operaciones complementarias que se deben realizar para finalizar la operación. 4xx: Errores del cliente; el requerimiento contiene algún 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 códigos que se utilizan con mayor frecuencia: La tabla 1 muestra los códigos de estado más comunes en una conversación establecida con el protocolo HTTP. Estos códigos son los que generalmente se modifican en interceptaciones o ataques a servicios HTTP y serán parte del análisis en los ejercicios propuestos del curso. CODIGO ACCION DESCRIPCION 200 OK Operación realizada satisfactoriamente 201 Created La operación 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 operación 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 información. 204 No Content La operación ha sido aceptada, pero no ha producido ningún resultado de interés. 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, además, 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, además, la nueva URL en el campo Location de la respuesta. El cliente no debe modificar ninguna de las referencias a la URL errónea. 304 Not Modified Se devuelve cuando se hace un GET condicional y el documento no ha sido modificado 400 Bad Request La petición tiene un error de sintaxis y no es entendida por el servidor. 401 Unauthorized La petición requiere una autorización especial, que normalmente consiste en un nombre y clave que el servidor verificará. El campo WWW-Autenticate informa de los protocolos de autentificación aceptados para este recurso. 403 Forbidden Está prohibido el acceso a este recurso. No es posible utilizar una clave para modificar la protección. 404 Not Found La URL solicitada no existe, no está disponible o no se encuentra. 500 Internal Server El servidor ha tenido un error interno, y no puede continuar con el Error procesamiento. 501 Not El servidor no tiene capacidad, por su diseño interno, para llevar a cabo el Implemented requerimiento del cliente. 502 Bad Gateway El servidor, que está actuando como proxy o pasarela, ha encontrado un error al acceder al recurso que había solicitado el cliente. 503 Service Unavailable El servidor está actualmente deshabilitado y no es capaz de atender el requerimiento. Tabla 1: Códigos de estado en HTTP Fuente: <http://www.rfc-editor.org/rfc/rfc1866.txt> 16

17 1.4 CODIFICACIÓN DE LA INFORMACIÓN: Una de las características de HTTP reside en que la comunicación entre cliente y servidor se realiza a partir de caracteres US-ASCII de 7 bits. El problema aparece cuando deseamos realizar la transmisión de un archivo binario, cuyo contenido no puede ser representado por este grupo tan reducido de caracteres. Para solventar esta limitación se utiliza el estándar de Internet MIME (Extensiones de correo de Internet multipropósito). Son una serie de convenciones o especificaciones dirigidas a que se puedan intercambiar a través de Internet todo tipo de archivos (texto, audio, vídeo, 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 especificación de este estándar se encuentra recogidas en las RFC 2045, 2046, 2047, 2048 y Los recursos u objetos que actúan como entrada o salida de un comando HTTP están clasificados por su descripción 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 identificación MIME permitirá que el receptor trate adecuadamente los datos. Existen nueve tipos definidos por la IANA: 12 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 métodos básicos de codificación: 7 bit: Utilizado por defecto, supone que los archivos son de texto. 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 latín. 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 <http://www.ietf.org/rfc/rfc2045.txt> 12 Disponible en internet desde <http://www.iana.org/> 17

18 LECCION 2: VULNERABILIDADES EN APLICACIONES WEB: 2.1 COMO TRABAJAN LAS APLICACIONES WEB Iniciemos con una breve descripción de cómo trabajan e interactúan las aplicaciones y servicios web con diferentes componentes y escenarios tecnológicos. El uso de aplicaciones web es tan común como tan masificado hoy en día por todo tipo de usuarios, empresas e instituciones. Su uso va desde la simple acción de leer un correo electrónico hasta realizar una compra en línea o una transacción bancaria sin importar el cubrimiento de estas aplicaciones, el tamaño, diseño, código en que estén realizadas, plataformas y arquitecturas en las que estén montadas. Algo en común de estas aplicaciones es que la mayoría son interactivas, agradables para el usuario, con datos en línea que se comparten y que ponen a disposición del usuario. Muchas de ellas soportadas por grandes bases de datos y que usan como canal de distribución Internet. La forma como una aplicación web trabaja, a simple vista es sencilla y práctica. Tal vez por ello y sin ser una afirmación, es que son vulnerables. Po lo general consisten en una base de datos que por decirlo así, está ubicada detrás del sitio web alojado en un servidor y que está escrita en un lenguaje de programación que es capaz de extraer información específica de esa base de datos por solicitudes y peticiones de los usuarios remotos o locales mediante interacciones dinámicas con esos usuarios o clientes. Cuando se usan bases de datos para la gestión de los mismos en aplicaciones web, es común que estas aplicaciones estén compuestas por tres niveles: Un nivel de presentación (un navegador web o motor de búsqueda). Un nivel lógico (un lenguaje de programación, como C #, ASP, NET, PHP, JSP, etc.). Y un nivel de almacenamiento (base de datos como Microsoft SQL Server, MySQL, Oracle, etc.) 18

19 Figura 5: Niveles de comunicación en aplicaciones web. Fuente: El autor En la (figura 5) se identifica la secuencia de peticiones y operación de los tres niveles en donde si el navegador Web (el nivel de presentación, por ejemplo, Internet Explorer, Safari, Firefox, etc) envía peticiones a la capa media (la capa de lógica), que define los servicios, las solicitudes, consultas y actualizaciones de la base de datos (el nivel de almacenamiento). 2.2 UNA ARQUITECTURA MÁS COMPLEJA: En los últimos años, el modelo de tres niveles fue reevaluado y un nuevo concepto basado en la escalabilidad y mantenimiento fue creado. Surge una solución de cuatro niveles que implica el uso de una pieza de middleware, típicamente llamado un servidor de aplicaciones, entre el servidor Web y el servidor de aplicaciones de base de datos. Esta nueva capa de abstracción, consta de un servidor que aloja una interfaz de programación de aplicaciones (API) para exponer la lógica de negocio y procesos de negocio para uso de los servidores Web. Además, el servidor de aplicaciones 19

20 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 (presentación) envía peticiones a la capa intermedia (lógica), que a su vez llama a la API expuesta del servidor de aplicaciones que residen en la capa de aplicación 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 com. El servidor web que reside en la capa de lógica carga una secuencia de comandos del sistema de archivos y se lo pasa a través de su motor de scripting en el que se analiza y se ejecuta El script llama a una API expuesta desde el servidor de aplicación que reside en la capa de aplicación. El servidor de aplicación abre una conexión con el nivel de almacenamiento usando un conector de base de datos y ejecuta una instrucción 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 lógica de aplicación o negocio antes de devolver los datos al servidor Web que aplica un retoque de (lógica final) antes de la presentación de los datos en formato HTML en el navegador Web del usuario. La presentación de la web se hace mediante HTML que le muestra al usuario una representación gráfica de la código Esto sucede de manera instantánea y es transparente para el usuario. Pero por que se dividen las tareas en capas o niveles?: El concepto básico de una arquitectura estratificada implica dividir una aplicación en trozos lógicos, o niveles, cada uno de los cuales se le asignan roles. Las capas se pueden localizar 20

21 (implementar) en diferentes máquinas o en la misma máquina de forma virtualizada o separados el uno del otro. Ventajas: Cuando se dividen las responsabilidades de una aplicación en múltiples capas hace que sea más fácil de escalar la aplicación, permite una mejor distribución de las tareas de desarrollo entre los desarrolladores, y hace una aplicación más fácil de leer dándole incluso enfoque de rehúso y de adaptabilidad a otras aplicaciones existentes o nuevas. Le da características de robustez a las aplicaciones permitiendo eliminar puntos de fallos críticos y únicos que se puedan presentar si la aplicación sufre una caída total o irreparable. Por ejemplo, la decisión de cambiar de proveedor de bases de datos debe requerir nada más que algunos cambios en las porciones aplicables de la capa de aplicación, la presentación y los niveles lógicos. 2.3 EL PROYECTO OWASP Y LAS VULNERABILIDADES EN APLICACIONES WEB Antes de dar inicio y entrar en la temática 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 inglés) 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 temática es amplia y de trabajo continuo. Este módulo académico que se presenta acá, no pretende abarcar la totalidad de las vulnerabilidades, estrategias, escenarios, herramientas y metodología usados tanto para detectar, diseñar, proveer, monitorear y corregir fallos de seguridad en aplicaciones web. Es un referente para que el profesional tome como partida y apoyo para el análisis de las temáticas que acá se presentan. Existen otros proyectos que tratan este tema y de los cuales también se han referenciado lecciones en este módulo, pero con OWASP se pretende que el estudiante lo identifique y derive sus conclusiones, aportes y posiciones con referencia a la temática. 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 académica, objetiva, investigativa y como un ejercicio profesional en el área de la seguridad, así: No sin antes referenciar el OWASP top 21

22 10 de 2013 que lo encuentran acá: 13 y que es de necesaria lectura antes de continuar. Figura 7: OWASP Top Fuente: %20RC1.pdf Con licencia Creative Commons La guía completa del Top 10, es parte del anexo de este módulo: No se detenga en el Top 10. Existen cientos de problemas que pueden afectar la seguridad general de una aplicación web tal como se ha discutido en la Guia de Desarrollo OWASP. 14 Este documento es de lectura esencial para cualquiera desarrollando aplicaciones web hoy en día. Una efectiva orientación en como encontrar vulnerabilidades en aplicaciones web es suministrada en la 13 Disponible en internet con acceso y formato pdf <https://www.owasp.org/index.php/category:owasp_top_ten_project> 14 Disponible en internet desde <https://www.owasp.org/index.php/guide> 22

23 Guia de Testeo OWASP 15 y la Guia de Revision de Codigo OWASP, 16 las cuales han sido significativamente actualizadas desde la última edición del Top 10. Cambio constante. Este Top 10 continuara cambiando. Incluso sin cambiar una línea de código en su aplicación, la misma puede ser vulnerable a algo que nadie haya pensado anteriormente. Por favor revise los consejos detallados al final del Top 10 Próximos pasos para Desarrolladores, Verificadores y Organizaciones para mayor información. Piense positivamente. Cuando se encuentre preparado para dejar de buscar vulnerabilidades y focalizarse en establecer controles seguros de aplicaciones, OWASP ha producido el Application Security Verification Standard (ASVS) 17 como una guía para organizaciones y revisores de aplicaciones que detalla los controles de seguridad a verificar en una aplicación. Utilice herramientas inteligentemente. Las vulnerabilidades de seguridad pueden ser bastante complejas y encontrarse ocultas en montañas de código. En virtualmente todos los casos, el enfoque mas eficiente y económico para encontrar y eliminar estas vulnerabilidades es asignar expertos armados de buenas herramientas para realizar esta tarea. SDLC Seguro. Aplicaciones Web seguras son solo posibles cuando se utiliza un SDLC Seguro. Para orientación sobre como implementar un SDLC Seguro, leer el Open Software Assurance Maturity Model (SAMM), 18 el cual es una actualización significativa al OWASP CLASP Project SNIFFEO Y CODIFICACIÓN DE CABECERAS: La temática que hasta aquí se ha tratado, ha descrito de forma general el protocolo HTTP y las negociaciones entre cliente-servidor que se establecen a través 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 análisis o su modificación. Estas utilidades se denominan sniffers, y funcionan interceptando el tráfico que pasa por el puerto 80 (HTTP). 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 también pueden ser programas independientes propietarios o de 15 Disponible en internet desde <https://www.owasp.org/index.php/category:owasp_testing_project> 16 Disponible en internet desde <https://www.owasp.org/index.php/category:owasp_code_review_project> 17 Disponible en internet desde <https://www.owasp.org/index.php/asvs> 18 Disponible en internet desde <https://www.owasp.org/index.php/category:software_assurance_maturity_model> 19 Disponible en internet desde <https://www.owasp.org/index.php/category:owasp_clasp_project> 23

24 código 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 algún programa que haga negociaciones TCP, como por ejemplo pueden ser Telnet, Putty, o los populares Netcat y CryptCat. 2.5 INYECTANDO CÓDIGO Cuando se hace un proceso de sniffing a las cabeceras HTTP, se puede hacer con dos objetivos: Observar los datos que se envían y de ahí buscar un posible CSRF (Cross Site Request Forguery) o bien para modificar la cabecera y añadirle código malicioso, el cual provoque en una aplicación vulnerable una respuesta que no era la que debía. Se inyecta código a las cabeceras y si se manejan datos procedentes de la cabecera sin realizarles un correcto filtrado, es ahí cuando una aplicación web se vuele más vulnerable y más cuando sin restricciones o controles de acceso, se le permite al front-end (usuarios hackers) la modificación de la cabecera para que la aplicación web maneje códigos 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 detallarán los procedimientos para detectar inyecciones de código como el SQL Injection 2.6 CR/LF INJECTIONS: Esta vulnerabilidad hace referencia a un término común: (HTTP Splitting). Hace referencia al manejo de cabeceras con caracteres especiales que trabajan en conjunto llamados CR (Carriage Retun) y LF (Line Feed) que básicamente traducen un Salto de línea en el momento de una conversación o salto de cabecera. En programación las señales de salto de línea se plasman con los caracteres de escape \r\n. Una aplicación 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 24

25 manipular a su antojo las cabeceras de un servidor y más si es bien conocido que la finalización de una cabecera se señala con un doble salto de línea Es aquí cuando un atacante identificando ese salto de línea final, provocará la partición de la cabecera, permitiendo colocar junto al doble salto de línea el código que él considere oportuno, normalmente será una segunda cabecera. A la técnica de truncar o cortar una cabecera para controlar una respuesta del servidor se la denomina HTTP Splitting. Una técnica derivada del HTTP Splitting puede ser lo que se denomina File Download Injection y consiste en infectar con el código que nosotros deseemos una descarga. 2.7 XSS Y SQL INJECTIONS Las fallas de inyección, ya sea de SQL, LDAP o comandos del sistema operativo, son comunes en aplicaciones Web. La inyección ocurre cuando los datos proporcionados por el usuario son enviados e interpretados como parte de una orden o consulta. Los atacantes interrumpen el intérprete para que ejecute comandos no intencionados proporcionando datos especialmente modificados. Esta técnica es usada para explotar aplicaciones web que no validan la información suministrada por el cliente, para generar consultas SQL maliciosas. El proceso de inyección requiere de verificar cada parámetro que se envía y se recibe, lo que suele no ser sencillo y muchas veces se puede creer que no es vulnerable una aplicación que lo es. Se debe chequear cada parámetro de cada script de cada aplicación. Para el siguiente ejemplo en la que se inyecta el comando (se solicita una información): SELECT id FROM usuarios WHERE user= $f_user AND password= $f_pass ; Si no se identifica un usuario (campo en blanco en la validación) o si se typean los parámetros predeterminados de los usuarios: admin, administrator, guest, invitado entre otros, al modificar la injección de SQL por: $f_user= or 1=1 -- en las que se usa: ; para ejecutar múltiples queries -- para comentar el final del query construcciones del tipo or = construcciones del tipo numero or 1=1 Se podría explotar esta vulnerabilidad de validación de usuario e ingresar al sistema 25

26 Ataques de Cross Site Scripting: Las fallas de XSS ocurren cuando una aplicación toma información originada por un usuario y la envía 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 víctima 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 típicamente se valen de código HTML y de scripts ejecutados en el cliente. Desde la liberación del lenguaje JavaScript, se previeron los riesgos de permitir a un servidor Web enviar código ejecutable al navegador. Un problema se presenta cuando los usuarios tienen abiertos varias ventanas de navegador, en algunos casos un script de una página podría acceder datos en otra página u objeto, observando el peligro de que un sitio malicioso intentara acceder datos sensibles de esta forma. 20 Política same origin: Esencialmente esta política permite la interacción entre objetos y páginas, 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 vía JavaScript. A partir de entonces se han introducido otros mecanismos y políticas 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 técnicas de evasión de las políticas de protección. La mayoría de casos la variable vulnerable (en el caso de los XSS) suele ser alguna que se utiliza para mostrar alguna información tipo IP, User-Agent y demás. Por eso la mayoría 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 sesión 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 aplicación de subir archivos al servidor. Estos ataques funcionan de la siguiente manera: Generalmente PHP almacena los archivos subidos en una carpeta temporal, sin embargo es común en las aplicaciones cambiar la localización del archivo subido a una carpeta permanente y leerlo en la memoria. Al hacer este tipo de 20 Tomado de: UNAM CERT; Aspectos Básicos de la Seguridad en Aplicaciones Web 26

27 procedimientos debemos revisar el parámetro que hará referencia al nombre del archivo, ya que puede ser truqueado a modo de apuntar a archivos de configuración del sistema (como /etc/passwd en sistemas Unix). Las aplicaciones invocan comandos externos a través de un intérprete de comandos. Según 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 información 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 básicamente banner a la información (aplicación, versión, plataforma sobre la que corre) que trasmite un servicio cuando se trabaja sobre en el. Un ejemplo de detección de esta información (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 típico del sitio Figura 8: Banner detección por ftp Fuente: El autor En la figura 9 se aplica un banner grabbing hacia la web Información del tipo de servidor, versión sistema operativo sobre el cual se ejecuta, versión de PHP entre otros. 27

28 Figura 9: Banner grabbing por método HEAD Fuente: El autor El ataque consistiría en obtener los encabezados por HEAD desde un navegador y editaros para reenviar peticiones y modificar comportamientos del sitio HTTP FINGERPRINTING Se trata entonces de obtener información de un sistema concreto y de alguna vulnerabilidad específica. Esto se hace obteniendo su huella identificativa respecto de la pila TCP/IP de los equipos atacados. Esta técnica es la que se conoce como Fingerprinting y la información que puede brindar esta técnica dentro de las muchas opciones que tiene de descubrir datos de la víctima es la de permitir descubrir de forma muy fiable el sistema operativo que se ejecuta en la maquina analizada. La aplicación de esta técnica consiste en la ejecución de 4 tests (orden de campos al hacer un HEAD, respuesta ante un DELETE, respuesta ante una versión del protocolo HTTP incorrecta, y por último, la respuesta que da el servidor ante un protocolo erróneo). 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. Además de las versiones de sistema operativo, puertos abiertos y capas de seguridad implementadas al protocolo HTTP. La información que puede brindar esta técnica dentro de las muchas opciones que tiene de descubrir datos de la víctima son: 28

29 Permitir descubrir de forma muy fiable el sistema operativo que se ejecuta en la maquina analizada. Identificar el tipo de servidor y la versión en la que se soporta el servicio El tipo de servicio que se ejecuta y la versión. Una de las muchas técnicas que existen para levantar este tipo de información 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 información con el número de puertos cerrados que tiene la víctima, en este caso con la dirección IP , los puertos en servicio abiertos, la identificación del sistema Operativo y la dirección física de la interfaz de red. Se ha ejecutado en una consola haciendo uso de nmap como herramienta de exploración. Figura 10: Uso de un Escucha de Red para hallar huellas identificativas de un host en la red Ethernet Fuente: El autor En la Figura 11 se ha realizado la inspección de la huella identificativa de un sistema remoto en la web. Es el caso de haciendo uso de un Sniffer como Ettercap. Se identifica el Sistema Operativo del Servidor, en este caso FreeBSD

30 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 desempeño de la red utilizando diferentes protocolos, tamaños de paquetes, TOS (type of service, o sea, tipo de servicio), y fragmentación; 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; detección remota de OS (`remote OS fingerprinting'); auditar una implementación de TCP/IP (`TCP/IP stack') en particular; etc. hping2 es una buena herramienta para aprender acerca de TCP/IP <RODES, Michael. Pruebas de seguridad con hping. El Baile. Magazine N 38> 30

31 LECCION 3: HERRAMIENTAS PARA LA DETECCION DE VULNERABILIDDES 3.1 FIABILIDAD DE LOS ANALIZADORES AUTOMÁTICOS DE VULNERABILIDADES WEB Se llega al punto de definir qué tan fiables los analizadores automáticos de vulnerabilidades Web. En primera instancia al gran número 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 detección y protección total. Los profesionales informáticos, empresas, administradores de TICS, diseñadores, desarrolladores e incluso usuarios, concentran sus actividades en aspectos de seguridad en emplear, cada vez más, herramientas para facilitar la ardua tarea de verificar el nivel de seguridad real de una aplicación web. Nombres como Appscan, Webinspect, Acunetix y otros tantos son cada vez más conocidos y utilizados por los profesionales en cualquier proyecto de auditoría o de pentest. Las ventajas son innumerables pero también los riesgos, y es necesario conocerlos y valorarlos a la hora de decidir el presupuesto de que se dispone para analizar si una página Web puede ser comprometida, desde el punto de vista de la seguridad, o si, por el contrario, cumplirá con su cometido a la perfección. Por Escáner Web se entiende cualquier programa con la capacidad de analizar la seguridad de una aplicación o página Web, es decir, debe incluir los siguientes complementos: a) Un navegador Web para poder interpretar el código HTML, javascript y demás de la propia página. b) Un "spider" o "crawler" para poder detectar toda la estructura de navegación de la Web (archivos, directorios, ficheros de imágenes, etc.) c) Un escáner propiamente dicho para hallar fallos de configuración y vulnerabilidades a nivel Web. d) Un interface de usuario amigable y fácil de utilizar, que permita configurar de forma sencilla la aplicación y todos los parámetros de análisis. e) Un generador de reportes que incluya las vulnerabilidades y errores encontrados, su posible impacto para la aplicación Web y la forma de corregir los mismos de forma genérica. 31

32 Existen multitud de herramientas así, comerciales de pago y con licencia GNU, para Windows y para Linux, más sencillas y más completas, de desarrolladores conocidos como RedHat, Oracle, Cisco. 3.2 VENTAJAS Y BENEFICIOS 1. Reducción de costes: el precio y el esfuerzo en horas de revisar una aplicación 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 análisis y revisiones para amortizar la herramienta. Además, existen incluso aplicaciones que no son comerciales sino Open Source que también son importantes, es el caso de Wapiti 22, Skipfish, Nikto, etc. 2. Disponibilidad y automatización: al poder programar y automatizar cualquier análisis de seguridad, se puede repetir tantas veces como sea necesario para verificar que se han corregido los errores y vulnerabilidades ya detectados. También se puede definir una frecuencia determinada para que se revise una página Web concreta una vez al mes, por ejemplo, y comprobar así si ha habido cambios en la misma y detectar incluso anomalías que pudieran indicar un ataque a la página en forma de intrusión o Denegación de Servicio (DoS). Si en un escaneo programado la página no está operativa puede ser debido a un ataque de DoS o un problema de disponibilidad no controlado. 3. Constante revisión y mantenimiento de la aplicación: La mayoría de herramientas lo hacen todo, revisan, analizan detectan las vulnerabilidades y errores de configuración, 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 <http://hacktimes.com/vulnerabilidades_en_aplicaciones_web_-_wapiti> 32

33 3.3 INCONVENIENTES Y DESVENTAJAS 1. Gran cantidad de falsos positivos y falsos negativos: dos peticiones iguales en momentos diferentes a la aplicación Web por parte del escáner, pueden generar respuestas distintas que la herramienta puede interpretar de forma errónea y reportar como una vulnerabilidad inexistente. Anuncios, dependencias con otras páginas y aplicaciones, usuarios conectados interactuando con la Web analizada, etc. En multitud de ocasiones la revisión de seguridad se limita a pasar la herramienta automática 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. También, otras veces, la página Web analizada presenta diverso código y contenido inútil para revisar la seguridad de la misma que una persona puede identificar de forma rápida y sencilla, pero que no lo es tanto para un ordenador y la correspondiente aplicación automática. Un ordenador no es capaz de entender la lógica de la aplicación Web, y el escaneo de seguridad se basa en comprobar la respuesta de la página Web ante los controles y tests que tiene predefinidos la herramienta de análisis como vulnerabilidades ya conocidas. 2. Imposibilidad de encontrar 0days y errores de diseño: al basarse el análisis en comprobar la respuesta de la página Web ante los controles y tests que la herramienta tiene predefinidos como vulnerabilidades ya conocidas, es muy difícil detectar la presencia de errores no conocidos (0days) y que no están incluidos en la base de datos del escáner Web con el que se realiza la revisión de seguridad. Además, es complicado que un ordenador pueda entender la lógica de la aplicación, cosa que para un técnico con conocimientos no supone ningún reto. 3. Problemas con vulnerabilidades de aplicación 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 además se encuentran por en medio mecanismos de seguridad como WAF, IPS, firewalls y otros, las herramientas automáticas 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 estándar como Blind SQL y la solución para corregirla es ligeramente distinta. Otro problema es 33

34 que numerosas herramientas automáticas no detectan como ataque de SQLi una vulnerabilidad en "ORDER BY", además es diferente la forma de tratar esta vulnerabilidad en función del motor de base de datos existente, ya sea MS SQL, MySQL, PostgreSQL, etc. 4. Riesgos directos para la aplicación Web: ya no solo por el límite de peticiones que una herramienta automática puede lanzar en paralelo contra la aplicación Web que puede saturar a la misma y dejarla inaccesible para sus usuarios legítimos, sino también 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 petición de "SELECT" no hay problema pero si eso mismo acompaña a una petición de "DELETE" quedaría una cosa parecida a "DELETE FROM users where id=1 or 1=1 --" con lo que esto supondría para la aplicación Web. Un técnico no usaría nunca este método de ataque pero aún existen muchas herramientas que se sirven de ella como patrón de ataque Resumiendo, para entornos productivos, lo más recomendable para disponer de un nivel aceptable de seguridad en las aplicaciones Web es combinar escaneos con herramientas automáticas y detectar aquellas vulnerabilidades de bajo nivel ya conocidas, y disponer también de técnicos de seguridad con amplios conocimientos que puedan realizar pruebas manuales específicas para cada aplicación. No es lo mismo revisar un CMS conocido tipo Wordpress, Joomla, etc. que una página Web sin contenido dinámico ni base de datos detrás. Un técnico puede ajustar las pruebas y los análisis a realizar en función de las necesidades de cada caso, se trata de soluciones no industrializadas 3.4 CRITERIOS DE VALORACIÓN PARA HERRAMIENTAS DE SEGURIDAD WEB Continuación se presenta un análisis de las principales herramientas usadas para detección y gestión de riesgos en seguridad de aplicaciones web. Tanto herramientas de código privado como de código libre. Dentro de los parámetros que se han tenido en cuenta para esta evaluación, se han tenido en cuenta que las vulnerabilidades y las herramientas se han aplicado en sistemas con seguridad perimetral, interna y de entorno básicas, con conexiones de internet libres sin restricciones, como las que tienen la mayoría de usuarios. El criterio de valoración fue la primera serie de características de auditoría de cada herramienta soporta. Una herramienta automatizada no puede detectar una exposición que no puede reconocer (al menos no directamente, y no sin un análisis 34

35 manual), y por lo tanto, el número de características de auditoría afectará la cantidad de exposiciones que la herramienta será capaz para detectar (suponiendo que la función de auditoría 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 aplicación, en cuanto a la detección de los riesgos que se podrían presentar para atacar a la aplicación web, y el ataque a los clientes legítimos Herramientas Comerciales: El número de funciones de auditoría en escáneres de aplicaciones Web - Herramientas Comerciales. Figura 12: Funciones de auditoría en escáneres de aplicaciones web. Herramientas comerciales Fuente: <Proyecto OWASP> Herramientas de código Abierto: El número de funciones de auditoría en escáneres de aplicaciones Web - Herramientas de código abierto. 35

36 Figura 13: Funciones de auditoría en escáneres de aplicaciones web. Herramientas de código abierto Fuente: <Proyecto OWASP> Herramientas de auditoría aplicadas a SQL INJECTION El análisis aplica a las herramientas que pueden detectar de SQL Injection, una de las exposiciones más famosas en ataques comúnmente aplicado en los escáneres de aplicaciones web. El análisis siguiente es producto de la evaluación de que tan buenas son las herramientas en la detección de riesgos de inyección SQL, partiendo de un punto sin ningún tipo de restricciones que pueden impedir que la herramienta funcione correctamente. 36

37 La evaluación se realizó en una aplicación que utiliza MySQL 5.5.x como su repositorio de datos, y por lo tanto, reflejará la exactitud de la detección de la herramienta cuando se escanean los repositorios de datos similares. La barra azul representa el caso vulnerable prueba de precisión de detección, mientras que la barra roja representa falsas categorías positivas detectadas por la herramienta. Herramientas de código privado Herramientas de código abierto Figura 14: Funciones de auditoría en escáneres de aplicaciones web para SQL Injection Fuente: <Proyecto OWASP> 37

38 3.4.4 Herramientas de auditoría aplicadas a XSS (Ataques de Cross Site Scripting) Para el segundo ataque más común implementado en los escáneres de aplicaciones web se aplicó le mismo procedimiento que en los atajes de SQL Injection. Herramientas de código privado Herramientas de código abierto Figura 15: Funciones de auditoría en escáneres de aplicaciones web para XSS Fuente: <Proyecto OWASP> 38

39 Continuando con la evaluación de herramientas y aplicando ciertos criterios de efectividad y de aplicabilidad, se adjunta como ANEXOS de este módulo, los análisis de ciertas variables que son de importancia analizarlas. Todas estas herramientas son tan solo un puñado entre la cantidad de estrategias, métodos y utilidades que se pueden seguir para realizar la explotación de las vulnerabilidades en una aplicación web. El objetivo es obtener información de la aplicación, tratar de realizar una evaluación de la vulnerabilidad con el fin de obtener información 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 aplicación web vulnerable diseñado para ayudar a evaluar las características, la calidad y la precisión de los escáneres de vulnerabilidades de las aplicaciones web. 23 LECCIÓN 4: MITOS EN LA SEGURIDAD WEB Siempre se cree que las vulnerabilidades más comunes como SQL Injection, DDoS y XSS, son las que afectan a las aplicaciones web. También que los errores son por deficiencias en la programación e implementación 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 básicas del sitio y accede a los links que solo le referencia la página 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 aplicación, por ejemplo si la aplicación utiliza campos ocultos para enviar información sensible estos pueden ser fácilmente manipulados desde el cliente. 23 Disponible en internet desde <http://code.google.com/p/wavsep/> 39

40 La validación solo se puede realizarse únicamente del lado del cliente con JavaScript (esto es falso) si no se efectúa ninguna validación del lado del servidor, cualquier atacante que evite esta validación (para nada difícil de lograr) tendrá acceso total a toda la aplicación. 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 aplicación sea accesible al exterior, no podrá hacer nada para detectar entradas maliciosas del cliente, y por supuesto no es protección contra ataques internos. El uso de SSL es una solución suficiente - SSL simplemente cubre el request/response HTTP dificultando la intercepción del tráfico entre cliente y servidor, pero no agrega seguridad al servidor ni evita el envío de código malicioso desde el cliente. Otro Mito es el que los desarrolladores y técnicos encargados de la seguridad enmarcan dentro de solo las supuestas cinco vulnerabilidades más comunes, dejando a un lado las estrategias de prevenir, analizar, detectar y sobre todo diseñar aplicaciones expuestas a otro tipo de vulnerabilidades. Figura 16: Categoría de Vulnerabilidades Fuente: El Autor 40

41 4.1 AUDITORÍA Y CONTROL DE VULNERABILIDADES: Muchas empresas sólo realizan el escaneo de vulnerabilidades para los periodos de las famosas auditoria seguridad informáticas y quizás rara vez, generalmente como una vez al año. Este es un gran error; no sólo se deben realizar las actualizaciones a las redes de forma frecuente, sino 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 análisis de seguridad regular con una mayor cantidad de escaneos, mucho más frecuente (un ejemplo podría ser realizar el escaneo de vulnerabilidades, de forma exhaustiva, cada 4 meses, o sea unas 3 veces al año). 4.2 PUNTOS DÉBILES: Los hackers siempre quieren encontrar el acceso más fácil a las redes de las organizaciones valiéndose de una variedad de técnicas diferentes. Pero una característica que todos los atacantes hackers tienen en común es su deseo de buscar los puntos débiles de una red, cuál de ellos puedan usar para lanzar ataques con el mínimo esfuerzo. Un ladrón normal busca una puerta abierta en una casa, un ladrón de autos busca el vehículo en donde el conductor se haya dejado la llave olvidada, un hacker puede examinar múltiples redes para encontrar la que le proporcione un acceso rápido y simple. Esta situación plantea un desafío 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: Exploración de puertos: El escaneo o exploración de puertos permite determinar las características 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, cómo están organizados los equipos, que sistemas operativos ejecutan y cuál es el propósito de cada uno. Una herramienta de código abierto que sirve para efectuar rastreo de puertos es nmap. Con la herramienta hping2 en el modo SCAN (-8 --scan): Permite realizar análisis de puertos, se pueden especificar distintas opciones para los puertos, rangos, excluir determinados puertos, los puertos incluidos en /etc/services, etc. 41

42 4.3 TIPOS DE ESCANERS: Parte de los mitos que rodean la seguridad en aplicaciones web, está el que aplican los técnicos, administradores de red, desarrolladores y profesionales, que les llevan a pensar que solo se deben implementar escáneres que detecten riesgos en las capas superiores del modelo OSI, La seguridad de la información es un conjunto engranado que enmarca todos los aspectos en comunicación, transferencia, trato de información. Es por ello que se deben aplicar escáner de este tipo para que medianamente se puedan minimizar riesgos y maximizar la seguridad: Escáner de Red: escáner de uso general usado para encontrar vulnerabilidades potenciales en la red de la empresa. (También se podría incluir a los escaners de redes VoIP) Escáner de Puerto: software diseñado para buscar en una red los puertos abiertos que podrían ser usados por los atacantes como puntos de entrada. Escáner para la Seguridad de aplicaciones web: Permite a los negocios realizar evaluaciones de riesgo para identificar las vulnerabilidades en aplicaciones web y así evitar ataques. Este tipo de escaners deben ser utilizados también por el departamento de desarrollo (programación) de una aplicación web, ayudando así a encontrar todos los bugs que puedan generarse durante la creación de la aplicación, antes de poner la aplicación a un entorno de producción. Escáner de Base de datos: permite encontrar puntos débiles en bases de datos, protegiendo así el activo más importante de una empresa. LECCIÓN 5: SISTEMA DE LOGS La auditoría 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 informática se utiliza para registrar datos o información sobre quién, qué, cuándo, dónde y por qué un evento ocurre en un dispositivo en particular o aplicación. 42

43 La mayoría de los logs son almacenados o desplegados en el formato estándar, 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 leído y desplegado en otro diferente. También se le considera como aquel mensaje que genera el programador de un sistema operativo, alguna aplicación o algún proceso, en virtud del cual se muestra un evento del sistema. 24 Los sistemas de los deben garantizar la monitorización de los eventos que se producen en la aplicación y asegurar la información 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 opción para usarlo. El formato Common Log Format es el siguiente: Figura 17: Formato de fichero de Logs Fuente: <MATEU, Carles; Desarrollo de aplicaciones web; UOC> Existen variantes extendidas que se aplican a estos formatos. Variantes que dependen del sistema usado y que generalmente en herramientas de tipo IDS con 24 Disponible en internet dese <http://www.juntadeandalucia.es/servicios/madeja/contenido/subsistemas/desarrollo/auditoria-yregistro> 43

44 código abierto, el administrador de la red puede modificar y parametrizar para obtener la información deseada. 5.2 ANÁLISIS DEL FICHERO DE LOG: Mucha información que suministran estos ficheros de registro, no son claros y requieren que se asocien a otros para poderlos interpretar. Lo más común es encontrar los siguientes datos: Número de peticiones recibidas (hits). Volumen total en bytes de datos y ficheros servidos. Número de peticiones por tipo de fichero (por ejemplo, HTML). Direcciones de clientes diferentes atendidas y peticiones para cada una de ellas. Número de peticiones por dominio (a partir de dirección IP). Número de peticiones por directorio o fichero. Número de peticiones por código de retorno HTTP. Direcciones de procedencia (referrer). Navegadores y versiones de éstos usados. A pesar de que las informaciones que podemos obtener del análisis de los ficheros de log son numerosas, hay unas cuantas que no podemos obtener. De ellas, algunas resultarían de especial interés: Identidad de los usuarios, excepto en aquellos casos en los que el usuario se identifique por petición del servidor. Número de usuarios. A pesar de tener el número de direcciones IP distintas, no podemos saber de forma absoluta el número de usuarios, y más si tenemos en cuenta la existencia de servidores proxy-cache. Datos cualitativos: motivaciones de los usuarios, reacciones al contenido, uso de los datos obtenidos, etc. Ficheros no vistos Qué visitó el usuario al salir de nuestro servidor. Este dato quedará recogido en los log del servidor donde el usuario fue después del nuestro. El análisis de estos ficheros, es específico para cada aplicación de captura que se tenga. 44

45 5.3 PROGRAMAS DE ANÁLISIS DE LOGS Al igual que las herramientas de detección de vulnerabilidades, y escuchas de red; son innumerables las que hay disponibles tanto en código propietario como de código abierto. Los programas de análisis de ficheros de log de código libre y que se pueden usar para obtener información sobre los registros de visitas de nuestro sitio web permiten mayor manipulación de la información y tratamiento de la misma. La mayoría de ellos generan los correspondientes informes en forma de páginas web que podemos publicar incluso en nuestro sitio web. Es de mencionar los más comunes que poseen interfaces gráficas y con características completas en cuanto a registros capturados: Webalizer, Awstats, Analog, CAPITULO 2: PROTOCOLOS DE SEGURIDAD PARA APLICACIONES WEB El análisis de estos protocolos nos ubica especialmente en los procesos que incluyen transacciones e información que se intercambie en sitios web y que por supuesto es manejada por aplicaciones web. A continuación se detalla los principales protocolos de seguridad que se manejan actualmente: 1. Secure Socket Layer (SSL) Secure Sockets Layer (SSL) es el estándar mundial de la seguridad en la Web. La tecnología SSL se enfrenta a potenciales problemas derivados de la visualización no autorizada de información confidencial, la manipulación de datos, la apropiación de datos, el phishing y los demás tipos de amenazas en los sitios Web. Para ello, se cifra la información confidencial a fin de que sólo los destinatarios autorizados puedan leerla. Además de evitar la manipulación de la información confidencial, SSL contribuye a que los usuarios tengan la seguridad de acceder a un sitio Web válido. Los principales sistemas operativos, aplicaciones Web y hardware del servidor son compatibles con SSL, lo que significa que esta poderosa tecnología de cifrado de SSL ayuda a implementar en cada empresa una manta de seguridad que limita la responsabilidad para todo el sistema con el fin de afianzar la seguridad de los clientes, incrementar el porcentaje de transacciones finalizadas y optimizar los resultados finales. Gracias a los avances recientes obtenidos en la tecnología SSL, existe una amplia variedad de tipos de SSL. 45

46 2. Transport Layer Security (TLS) Para intentar corregir las deficiencias observadas en SSL v3 se buscó un nuevo protocolo que permitiera transacciones seguras por Internet, sobre todo teniendo en cuenta que SSL es propiedad de la empresa Nestcape. El resultado de esta búsqueda fue el protocolo TLS, que permite una compatibilidad total con SSL siendo un protocolo público, estandarizado por el IETF. TLS busca integrar en un esquema tipo SSL al sistema operativo, a nivel de la capa TCP/IP, para que el efecto "túnel" que se implementó con SSL sea realmente transparente a las aplicaciones que se están ejecutando. 3. Protocolo S-HTTP El protocolo Secure HTTP fue desarrollado por Enterprise Integration Technologies, EIT, y al igual que SSL permite tanto el cifrado de documentos como la autenticación mediante firma y certificados digitales, pero se diferencia de SSL en que se implementa a nivel de aplicación. Se puede identificar rápidamente a una página web servida con este protocolo porque la extensión de la misma pasa a ser.shtml en vez de.html como las páginas normales. 4. Protocolo SET SET se basa en el uso de certificados digitales para asegurar la perfecta identificación de todas aquellas partes que intervienen en una transacción on-line basada en el uso de tarjetas de pago, y en el uso de sistemas criptográficos de clave pública para proteger el envío de los datos sensibles en su viaje entre los diferentes servidores que participan en el proceso. Con ello se persigue mantener el carácter estrictamente confidencial de los datos, garantizar la integridad de los mismos y autenticar la legitimidad de las entidades o personas que participan en la transacción, creando así un protocolo estándar abierto para la industria que sirva de base a la expansión del comercio electrónico por Internet. 46

47 LECCIÓN 6: TIPOS DE ANÁLISIS: 6.1 METODOLOGÍAS DE ANÁLISIS DE SEGURIDAD WEB: Las aplicaciones web pueden ser analizadas utilizando distintos enfoques, entre ellos, es posible distinguir los siguientes: Análisis estático de código: El analista de seguridad posee acceso al código fuente de la aplicación, y posiblemente a manuales del usuario pero NO POSEE acceso a la aplicación en sí misma. Tiene como desventajas: Suele suceder, sobre todo con sistemas grandes, que la cantidad de información es tanta que puede resultar muy complejo manejarla. No es posible analizar todas las líneas del programa en búsqueda de vulnerabilidades, lo cual hace que sea complejo definir exactamente que secciones analizar. Cuando no es posible acceder a la aplicación, es común que el analista se "pierda" entre tanto código. White box: En este enfoque, el analista de seguridad posee acceso al código fuente de la aplicación, manuales del usuario, credenciales válidas del sistema, configuración del servidor Web, y acceso a la aplicación en sí misma. Tiene como ventajas: Más información disponible, más vulnerabilidades que se pueden descubrir. Es posible descubrir TODAS las vulnerabilidades (si se tiene el tiempo suficiente) y no es necesario suponer nada, todo está en el código. Black box: En este enfoque, el analista de seguridad posee únicamente acceso a la aplicación. Tiene como ventajas la simplicidad, menor tiempo de testing y provee un enfoque real, ya que se posee el mismo nivel de conocimiento sobre la aplicación que un potencial intruso. Como desventajas están: Vulnerabilidades trivialmente detectables con white box testing, no pueden ser detectadas con este enfoque. (if user == tester002 and password == backdoor ) No se aprovecha el código fuente de la aplicación a favor de la seguridad de la misma. Dependiendo del tipo de enfoque, se aplican herramientas de análisis como las vistas en la Lección 2 de este módulo. 47

48 LECCIÓN 7: ESCALACION DE PRIVILEGIOS EN APLICACIONES WEB: Su definición es la obtención de los privilegios del administrador. Por ello, debe existir una política o normativa específica que establezca el uso de mecanismos para impedir intentos de escalado de privilegios en nuestras aplicaciones web. Se considera que un sistema aplica políticas para evitar el escalado de privilegios cuando: No es posible acceder a información del sistema que pueda ser utilizada para la escalada de privilegios, no es posible ejecutar acciones haciéndose pasar por otro usuario, etc. Las pruebas de escalada en aplicaciones web involucran por lo menos dos tipos de autenticación y validación. Un escenario típico para analizar la jerarquía de privilegios es si dada una aplicación web que debe tener al menos dos tipos de credenciales: para un usuario con privilegios elevados y bajos de privilegio. Al iniciar sesión como usuario con privilegios elevados (por ejemplo, admin), obviamente tenemos acceso a mucha más información (más elementos de menú, más funcionalidad, etc.) El punto de análisis crítico es determinar si esos temas (accesos a servicios) se puede acceder directamente por el usuario con pocos privilegios. El desarrollador debe estar seguro que la navegación por toda la aplicación de un usuario con privilegios bajos es confiable y que abarco cada entrada y salida de la aplicación. El manejo de estos privilegios suele ser administrado mediante credenciales de acceso haciendo uso de bases de datos. La exposición de estas credenciales son huecos vulnerables para la aplicación. Los datos de usuario y password son sensibles, por lo que deben tener garantizada una atención especial. Su presencia en el código fuente es un riesgo inevitable. Un caso típico de diseño de software es que sean administradas por un lenguaje de programación de uso general de código del lado del servidor originalmente diseñado para el desarrollo web como es PHP. Por conveniencia, estos datos son almacenados en un archivo como db.inc y suelen tener esta forma: <?php $db_user = 'myuser'; $db_pass = 'mypass'; $db_host = ' '; $db = mysql_connect($db_host, $db_user, $db_pass);?> 48

49 Al analizar el archivo por default http.confg de Apache, encontramos que el tipo default es text/plain. Esto significa un riesgo si el archivo db.inc se localiza en la raíz del directorio. Todo recurso localizado en la raíz tiene una dirección URL y como Apache no tiene un tipo de contenido asociado a los archivos.inc la respuesta del servidor será devolver el contenido en texto plano del archivo, en donde se podrían observar las credenciales del servidor. La mejor solución a este problema es almacenar los archivos a incluir en otro lugar fuera del directorio raíz. No es necesario tenerlos en algún lugar en particular en el sistema de archivos para ser capaces de incluirlos o requerirlos, solo es necesario garantizar que el servidor tenga privilegios de lectura. De hecho únicamente se debe localizar en la raíz los recursos que se deseen sean accesibles, o configurar un directorio público con las respectivas directivas de seguridad. LECCIÓN 8: AUTENTICACIÓN Y AUTORIZACIÓN: Normalmente, casi todas las aplicaciones o sistemas necesitan de los procesos de autentificación y autorización. 8.1 LA AUTENTIFICACIÓN: Es el proceso por el cual un usuario o servicio tiene que autentificarse para poder acceder a ciertos servicios que ofrece nuestro sistema. Existen distintas categorías de autentificación: Qué sabes?: Información que el usuario conoce, ejemplos: contraseñas, respuestas a preguntas de indicio a contraseñas. Qué tienes?: Elementos físicos que el usuario posee, como por ejemplo una determinada tarjeta. Quién eres?: Técnicas biométricas como lectura de retina o huellas dactilares. El control de acceso es el proceso de decidir si el usuario tiene permiso para ejecutar algo o no. HTTP por defecto tiene características de autentificación: autenticación del protocolo que se utiliza para intercambiar mensajes. Para la mayoría de los servicios 49

50 Web XML, esto significa aprovechar las características de autenticación disponibles en HTTP. Los tipos de autenticación típica son: Básica: utilizada para identificación no segura o poco segura de clientes, ya que el nombre de usuario y la contraseña se envían como texto codificado en base 64, que puede ser fácilmente descodificado. En el caso de IIS, autorizará el acceso a los servicios Web XML si las credenciales coinciden con las de una cuenta de usuario válida. Básica sobre SSL: igual que la autenticación básica, excepto que el canal de comunicación está cifrado y protege de ese modo el nombre de usuario y la contraseña. Una buena opción para entornos en Internet; sin embargo, el uso de SSL influye negativamente en el rendimiento. Implícita: utiliza algoritmos hash para transmitir las credenciales del cliente de forma segura. Sin embargo, es posible que no sea compatible con todas las herramientas de desarrollo para generar clientes de servicios Web XML. IIS autorizará el acceso a los servicios Web XML si las credenciales coinciden con las de una cuenta de usuario válida. Autenticación de Windows integrada: resulta útil sobre todo en entornos en Intranet. Utiliza NTLM o Kerberos. El cliente debe pertenecer al mismo dominio que el servidor o a un dominio en el que el dominio del servidor confía. IIS autorizará el acceso a los servicios Web XML si las credenciales coinciden con las de una cuenta de usuario válida. Certificados de cliente a través de SSL: requiere que cada cliente obtenga un certificado. Los certificados se asignan a las cuentas de usuario, que son utilizadas por IIS para autorizar el acceso a los servicios Web XML. Se trata de una solución viable para entornos en Internet, aunque el uso de certificados digitales no está muy extendido actualmente. Es posible que no sea compatible con todas las herramientas de desarrollo para generar clientes de servicios Web XML. Sólo está disponible en conexiones SSL, de modo que el rendimiento puede verse afectado 50

51 8.2 LA AUTORIZACIÓN: 25 Se refiere a la gestión del acceso a los recursos protegidos y al proceso de determinar si un usuario está autorizado a acceder a un recurso particular. Por ejemplo, muchas aplicaciones web cuentan con recursos que sólo están disponibles para los usuarios autenticados, recursos que sólo están disponibles para los administradores, y los recursos que están disponibles para todos. Así, al establecer privilegios de acceso a los usuarios podemos asegurar la confidencialidad y disponibilidad de la información; pero, además, podemos: Que sólo las personas autorizadas podrán acceder a ciertos recursos (sistemas, equipos, programas, aplicaciones, bases de datos, redes, etc.) por sus funciones laborales. Nos permiten identificar y auditar los accesos realizados, estableciendo controles de seguridad internos. Documentar los procedimientos de acceso a las diferentes aplicaciones que tratan datos personales. En definitiva, controlar los accesos desde diferentes vertientes: red, sistemas y aplicaciones. Se presentan dos categorías de Autorización: Autorización declarativa: En este tipo de autorización los privilegios son gestionados un administrador independientemente de manera externa al código de la aplicación Autorización programática: En este tipo de autorización las decisiones de autorización se realizan desde el código fuente de la aplicación. LECCIÓN 9: EJECUCIÓN DE INSTRUCCIONES DE ACCESO: 9.1 CODIFICACIÓN Y LAS VALIDACIONES DE ENTRADA / SALIDA: Indican que la debilidad de seguridad más común en aplicaciones web es la falta de validación apropiada de las entradas del cliente o del entorno. Teniendo en cuenta una serie de indicaciones y consejos a la hora de codificar nuestras aplicaciones podremos evitar problemas como la inyección de código SQL, de comandos, LDAP, XPath, XML o por XSS. 25 Disponible en internet dese <http://www.yiiframework.com/doc/guide/1.1/es/topics.auth> 51

52 Esta debilidad lleva a casi todas las principales vulnerabilidades en las aplicaciones, tales como intérprete de inyección, ataques locale/unicode, ataques al sistema de archivos y desbordamientos de memoria. Nunca se debe confiar en los datos introducidos por el cliente, ya que podría manipularlos. Hay que garantizar que la aplicación sea robusta contra todas las formas de ingreso de datos, ya sea obtenida del usuario, de la infraestructura, de entidades externas o de sistemas de base de datos. Existen vulnerabilidades asociadas a la validación de los datos, Vulnerabilidad de la integridad de los datos: El atacante manipula los datos introduciendo intencionadamente datos erróneos que manipulan la función de negocio. Violación del formato de los datos: Un atacante consigue introducir datos sin la sintaxis correcta, fuera de los límites de longitud, que contenga caracteres no permitidos, con signo incorrecto o fuera de los límites del rango. Esto provoca un mal funcionamiento de la aplicación. Incumplimiento de las reglas de negocio: Se introducen datos que no cumplen con las reglas de negocio. Lo que provoca un comportamiento no esperado de la aplicación. 9.2 GESTIÓN DE SESIONES Y USUARIOS: El manejo de la sesión es uno de los aspectos críticos de la seguridad WEB. Veremos cómo es posible mejorar la seguridad en el control de acceso y la autenticación a través del manejo de las sesiones y de la información de los usuarios de nuestras aplicaciones. Se detectan las siguientes vulnerabilidades significativas. Fijación de sesión que intenta explotar la vulnerabilidad de un sistema que permite a una persona fijar el identificador de sesión de otra persona. La mayoría de ataques de fijación del período de sesiones están basados en la web, y la mayoría depende de los identificadores de sesión que han sido aceptados de URL o datos POST Identificador de la sesión vulnerable, si no se reserva un tamaño adecuado el atacante, mediante técnicas de fuerza bruta atacante puede conocer el identificador de una sesión autenticada y por lo tanto hacerse con el control de la sesión. 52

53 Manejo de la información de sesión errónea, ya sea por estar en un espacio compartido o mal encriptada, el atacante puede obtener datos de la sesión de otro usuario. Ataques de proxys o cachés, las aplicaciones web deben especificar mecanismos para impedir estos ataques de tal manera que no sea posible suplantar sesiones de otros usuarios. 9.3 GESTIÓN DE ERRORES Y EXCEPCIONES: Uno de los focos que originan vulnerabilidades en nuestras aplicaciones se basa en la falta de control sobre los errores que se producen en su ejecución y el tratamiento correcto de las excepciones. Veremos cómo disminuir los riesgos de ser atacados a partir de la generación de un error o excepción en la aplicación. El manejo de errores y excepciones son dos aspectos para realizar un seguimiento de fallos dentro de una aplicación. En términos generales, hay tres situaciones que hacen que las excepciones sean lanzadas: Excepciones que se producen en el código del cliente: El código cliente intenta hacer algo que no está permitido por la API, de esta forma viola el contrato. El cliente puede tomar algún camino alternativo, si hay información útil proporcionada en la excepción. Por ejemplo: una excepción es lanzada cuando se está analizando un documento XML que no está bien formado. La excepción contiene información útil acerca de la localización en el documento XML donde se produce el problema. El cliente puede utilizar esta información para recuperarse del problema. Excepciones por fallos en los recursos mantenidos: Las excepciones se producen si existe un fallo derivado de un recurso. Por ejemplo, el agotamiento de memoria o el fallo de conexión cuando se cae una red. La respuesta del cliente a los recursos que fallan depende del contexto. El cliente puede reintentar la operación después de algún tiempo o simplemente registrar el fallo del recurso y detener la aplicación. Excepciones por errores derivados del código programado: En esta categoría, las excepciones se producen en la ejecución del código. El código cliente usualmente no puede hacer nada con estos errores. 53

54 LECCIÓN 10: CONFIGURACIÓN SEGURA DE SERVIDORES: La mayoría de los servidores web modernos nos permiten controlar desde el programa servidor aquellos aspectos relacionados con la seguridad y la autenticación de los usuarios. El modo más simple de control es el proporcionado por el uso de ficheros.htaccess. Éste es un sistema de seguridad que proviene de uno de los primeros servidores web (del NCSA httpd), que consiste en poner un fichero de nombre.htaccess en cualquier directorio del contenido web que se vaya a servir, indicando en este fichero qué usuarios, máquinas, etc., tienen acceso a los ficheros y subdirectorios del directorio donde está el fichero. Como el servidor de NCSA fue el servidor más usado durante mucho tiempo, la mayoría de servidores modernos permiten utilizar el fichero.htaccess respetando la sintaxis del servidor de NCSA. Otros servidores permiten especificar reglas de servicio de directorios y ficheros en la configuración del servidor web, indicando allí qué usuarios, máquinas, etc., pueden acceder al recurso indicado. Por lo que respecta a la autenticación (validación del nombre de usuario y contraseña proporcionados por el cliente), las prestaciones ofrecidas por los diversos servidores web son de lo más variado. La mayoría permiten, como mínimo, proporcionar al servidor web un fichero con nombres de usuario y contraseñas contra el que se pueda validar lo enviado por el cliente. De todos modos, es frecuente que los servidores proporcionen pasarelas que permitan delegar las tareas de autenticación y validación a otro software (por ejemplo RADIUS, LDAP, etc.). Si usamos un sistema operativo como Linux, que dispone de una infraestructura de autenticación como PAM (pluggable authentication modules), podemos usar esta funcionalidad como modo de autenticación del servidor web, permitiéndonos así usar los múltiples métodos disponibles en PAM para autenticar contra diversos sistemas de seguridad ORGANIZACIÓN DEL SERVIDOR WEB: Una forma de implementar aspecto de seguridad en servidores web es la de administrar procesos y atender peticiones de una manera eficiente y económica, es necesario definir algunos términos. 26 <MATEU, Carles; Desarrollo de aplicaciones web, p 24, 25 > 54

55 Proceso: la unidad más pesada de la planificación de tareas que ofrece el sistema operativo. No comparte espacios de direcciones ni recursos relacionados con ficheros, excepto de manera explícita (heredando referencias a ficheros o segmentos de memoria compartida), y el cambio de tarea lo fuerza el núcleo del sistema operativo (preemptivo). Flujo o thread: la unidad más ligera de planificación de tareas que ofrece el sistema operativo. Como mínimo, hay un flujo por proceso. Si distintos flujos coexisten en un proceso, todos comparten la misma memoria y recursos de archivos. El cambio de tarea en los flujos lo fuerza el núcleo del sistema operativo (preemptivo). Fibra: flujos gestionados por el usuario de manera cooperativa (no preemptivo), con cambios de contexto en operaciones de entrada/salida u otros puntos explícitos: al llamar a ciertas funciones. La acostumbran a implementar librerías fuera del núcleo, y la ofrecen distintos sistemas operativos. En general, los modelos con muchos procesos son costosos de memoria (cada proceso ocupa su parte) y de carga (creación de procesos). En servidores de alto rendimiento, los modelos con flujos parecen mejores, aunque tienen el problema de la portabilidad difícil y la posible necesidad de mecanismos que anticipan el coste de creación de procesos o flujos y, por lo tanto, son muy rápidos atendiendo peticiones. En máquinas uniprocesador, los modelos con un solo flujo funcionan bien. En máquinas multiprocesador, es necesario usar múltiples flujos o procesos para aprovechar el paralelismo del hardware ORGANIZACIÓN DE LAS APLICACIONES WEB: Los servidores web se encargan de atender y servir peticiones HTTP de recursos, que en su forma más simple acostumbran a ser documentos guardados en el sistema de ficheros. Sin embargo, la otra función importante de un servidor web es la de actuar de mediador entre un cliente y un programa que procesa datos. Recibe una petición con algún argumento, la procesa y devuelve un resultado que el servidor web entrega al cliente. La interacción entre el servidor web y los procesos que tiene asociados es otro aspecto que hay que considerar. Existen distintas maneras de organizar una aplicación web. A continuación, por orden cronológico de complejidad y rendimiento creciente, se presentan distintos modelos de organización. 55

56 CGI: es el modelo más antiguo y simple. Para cada petición HTTP se invoca un programa que recibe datos por las variables del entorno y/o de entrada estándar, y devuelve un resultado por la salida estándar. Consumir un proceso por cada petición genera problemas importantes de rendimiento, que el modelo FastCGI intenta mejorar. Servlets: es un modelo diseñado para Java, más eficiente y estructurado, que permite elegir distintos modelos de gestión de flujos o threads, duración de procesos del servidor, etc. Partiendo de este modelo, se han construido servidores de aplicaciones con múltiples funciones adicionales que facilitan el desarrollo de aplicaciones web complejas. CAPITULO 3 DESARROLLO SEGURO DE APLICACIONES: LECCIÓN 11: CONCEPTOS GENERALES PARA EL DESARROLLO SEGURO DE APLICACIONES: La importancia de una metodología de desarrollo seguro en aplicaciones Web inicia cuando el principal problema reside en la falta de controles durante el ciclo de vida del desarrollo de un aplicativo, ya que impera más el hecho que funcione que el hecho de ser seguro, lo cual es un problema para aplicaciones WEB. Qué amenazas tiene una persona que navegue por Internet? Suplantación de identidad, robo de credenciales, alteración de los contenidos de la web, ejecución de acciones sin su conocimiento. Cada uno de ellos está derivado tanto de una mala metodología de desarrollo como de una falta de concienciación de los usuarios, los cuales acceden a cualquier enlace sin identificar su procedencia. Las amenazas, debido a una mala programación, pueden permitir al atacante desde la obtención de las credenciales de un usuario, hasta la modificación del contenido de la página web vulnerable pasando por la realización de acciones sin conocimiento del usuario como compras o transacciones bancarias. Para cada una de estas acciones hay soluciones más o menos sencillas pero hace falta más concienciación por parte del equipo de desarrollo para identificarlas en las diferentes fases del desarrollo. Por ello, hay que hacer hincapié en identificar en las fases de diseño además de los casos de uso, los casos de abuso. Un caso de abuso, es la identificación de las diferentes amenazas que pueden asociarse a un caso de uso. Por ejemplo, en una 56

57 ventana de login (página donde se introduce el usuario y la contraseña) Cuáles son las amenazas principales? autenticarse sin conocer la contraseña, obtención de credenciales, enumeración de usuarios, Una vez identificados los diferentes casos de abuso, el siguiente paso sería implantar y diseñar los controles para evitar estas amenazas. La mayoría de las amenazas se mitigan a través de una validación robusta de los datos de entrada. Cada vez es más importante el posicionamiento en internet para la venta de diferentes productos o servicios. Si una determinada empresa A tiene una vulnerabilidad en su web y está, a su vez, es explotada Cuál es el impacto para la organización? Pérdida de confianza de sus clientes con la consiguiente pérdida económica y de imagen, impacto económico en base a las normativas vigentes de protección de datos si se publican datos de carácter personal. Además hay que añadir el gasto que supone la corrección de las vulnerabilidades, este gasto es superior al gasto económico que hubiera supuesto la realización de pruebas de identificación de vulnerabilidades en el proceso de desarrollo software..no existen páginas webs 100% seguras a pesar de que se les haya implementado un ciclo de desarrollo seguro de aplicaciones. Figura 18: Metodología de desarrollo seguro Fuente: <http://www.consultec.es/> 57

SEGURIDAD EN APLICACIONES WEB CONTENIDO DIDACTICO DEL CURSO. Elaborado por: Ing. Carlos Alberto Amaya Tarazona

SEGURIDAD EN APLICACIONES WEB CONTENIDO DIDACTICO DEL CURSO. Elaborado por: Ing. Carlos Alberto Amaya Tarazona SEGURIDAD EN APLICACIONES WEB 233008 CONTENIDO DIDACTICO DEL CURSO Elaborado por: Ing. Carlos Alberto Amaya Tarazona DUITAMA (Boyacá). Enero de 2013 1 ASPECTOS DE PROPIEDAD INTELECTUAL Y VERSIONAMIENTO

Más detalles

Seguridad en Aplicaciones Web

Seguridad en Aplicaciones Web Seguridad en Aplicaciones Web Leandro Meiners lmeiners@cybsec cybsec.comcom Septiembre de 2005 Buenos Aires - ARGENTINA Temario Temario Introducción al Protocolo HTTP: Arquitectura, carácterísticas, autenticación,

Más detalles

Clase. geniería de la Computación. Departamento de Ciencias e Ing. Diego C. Martínez - DCIC-UNS

Clase. geniería de la Computación. Departamento de Ciencias e Ing. Diego C. Martínez - DCIC-UNS Ingeniería de Ap plicaciones Web Clase 2 Diego C. Martínez Departamento de Ciencias e Ing geniería de la Computación Universidad Nacional del Sur Internet y sus servicios Internet define una forma de conexión

Más detalles

Clase 22 Nivel de Aplicación WWW Tema 6.- Nivel de aplicación en Internet

Clase 22 Nivel de Aplicación WWW Tema 6.- Nivel de aplicación en Internet Clase 22 Nivel de Aplicación WWW Tema 6.- Nivel de aplicación en Internet Dr. Daniel Morató Redes de Computadores Ingeniero Técnico de Telecomunicación Especialidad en Sonido e Imagen 3º curso Temario

Más detalles

Tema 2 El Servicio Web

Tema 2 El Servicio Web Tema 2 El Servicio Web Eduardo Martínez Graciá Humberto Martínez Barberá Departamento de Ingeniería de la Información y las Comunicaciones Universidad de Murcia Introducción Nace en el CERN, en 1989 Surge

Más detalles

5.1. Qué es Internet? controla todo el sistema, pero está conectado de tal manera que hace

5.1. Qué es Internet? controla todo el sistema, pero está conectado de tal manera que hace 5. Internet 5.1. Qué es Internet? Internet es una red mundial de equipos que se comunican usando un lenguaje común. Es similar al sistema telefónico internacional: nadie posee ni controla todo el sistema,

Más detalles

Seminario de SEGURIDAD WEB. Pedro Villena Fernández www.consultoriainnova.com

Seminario de SEGURIDAD WEB. Pedro Villena Fernández www.consultoriainnova.com Seminario de SEGURIDAD WEB Pedro Villena Fernández www.consultoriainnova.com Algunas cosas antes de empezar... Este seminario NO tiene la intención de piratear otras webs. Los ataques que aprenderemos

Más detalles

Capítulo 2.- Vulnerabilidades en aplicaciones web.

Capítulo 2.- Vulnerabilidades en aplicaciones web. Capítulo 2.- Vulnerabilidades en aplicaciones web. En este capítulo se explican algunas vulnerabilidades en aplicaciones web que pueden ser explotadas por software o por personas malintencionadas y como

Más detalles

INTRODUCCION. Tema: Protocolo de la Capa de aplicación. FTP HTTP. Autor: Julio Cesar Morejon Rios

INTRODUCCION. Tema: Protocolo de la Capa de aplicación. FTP HTTP. Autor: Julio Cesar Morejon Rios INTRODUCCION Tema: Protocolo de la Capa de aplicación. FTP HTTP Autor: Julio Cesar Morejon Rios Qué es FTP? FTP (File Transfer Protocol) es un protocolo de transferencia de archivos entre sistemas conectados

Más detalles

Testing de Seguridad de Aplicaciones Web

Testing de Seguridad de Aplicaciones Web Testing de Seguridad de Aplicaciones Web Julio C. Ardita, CISM. jardita@cybsec.com 16 de Noviembre de 2013 Coatzacoalcos - MEXICO Temario - Protocolo HTTP - Herramientas de Testing Web. - Vulnerabilidades

Más detalles

Capítulo 4 Pruebas e implementación de la aplicación CAPÍTULO 4 PRUEBAS E IMPLEMENTACIÓN DE LA APLICACIÓN

Capítulo 4 Pruebas e implementación de la aplicación CAPÍTULO 4 PRUEBAS E IMPLEMENTACIÓN DE LA APLICACIÓN CAPÍTULO 4 PRUEBAS E IMPLEMENTACIÓN DE LA APLICACIÓN CONCEPTOS DE PRUEBAS DE APLICACIÓN El departamento de Testing se encarga de diseñar, planear y aplicar el rol de pruebas a los sistemas que el PROVEEDOR

Más detalles

Capítulo 3 Diseño del Sistema de Administración de Información de Bajo Costo para un Negocio Franquiciable

Capítulo 3 Diseño del Sistema de Administración de Información de Bajo Costo para un Negocio Franquiciable Capítulo 3 Diseño del Sistema de Administración de Información de Bajo Costo para un Negocio Franquiciable 1. Introducción. El Sistema de Administración de Información de un Negocio Franquiciable (SAINF)

Más detalles

Suplemento informativo: aclaración del requisito 6.6 sobre revisiones de códigos y firewalls de aplicaciones

Suplemento informativo: aclaración del requisito 6.6 sobre revisiones de códigos y firewalls de aplicaciones Norma: Normas de Seguridad de Datos (DSS) Requisito: 6.6 Fecha: febrero de 2008 Suplemento informativo: aclaración del requisito 6.6 sobre revisiones de códigos y firewalls de aplicaciones Fecha de publicación:

Más detalles

SERVIDOR WEB MULTIPLATAFORMA CON IMPLEMENTACIÓN CGI

SERVIDOR WEB MULTIPLATAFORMA CON IMPLEMENTACIÓN CGI SERVIDOR WEB MULTIPLATAFORMA CON IMPLEMENTACIÓN CGI C.U. Loraine E. Gimson Saravia a, C.U. Julián J. Fernández b L.I.D.T.I. Universidad Nacional de Salta. Facultad de Ciencias Exactas a E-Mail: saraviag@unsa.edu.ar

Más detalles

DIPLOMADO EN SEGURIDAD INFORMATICA

DIPLOMADO EN SEGURIDAD INFORMATICA DIPLOMADO EN SEGURIDAD INFORMATICA Modulo 9: Soporte Computacional Clase 9_3:Protocolos de comunicación y conectividad de arquitecturas multiplataforma. Director Programa: César Torres A Profesor : Claudio

Más detalles

LABORATORIO DE FTP. PRESENTADO POR: Diana Maritza Aragón Marta Moreno Luis Miguel Pérez. PRESENTADO A: Marcelo Utard Javier Bozzuto

LABORATORIO DE FTP. PRESENTADO POR: Diana Maritza Aragón Marta Moreno Luis Miguel Pérez. PRESENTADO A: Marcelo Utard Javier Bozzuto LABORATORIO DE FTP PRESENTADO POR: Diana Maritza Aragón Marta Moreno Luis Miguel Pérez PRESENTADO A: Marcelo Utard Javier Bozzuto ESCUELA DE GRADUADOS DE ELECTRÓNICA Y TELECOMUNICACIONES LABORATORIO DE

Más detalles

Capa de Aplicación (Parte 2 de 2)

Capa de Aplicación (Parte 2 de 2) Capa de Aplicación (Parte 2 de 2) Redes de Computadoras HTTP (Hypertext Transfer Protocol) 1 Qué es Internet? Internet conecta a un conjunto de redes usando protocolos estándar Protocolos de enrutamiento,

Más detalles

INTRODUCCIÓN AL WEB. Pag. 1 de 10

INTRODUCCIÓN AL WEB. Pag. 1 de 10 INTRODUCCIÓN AL WEB La World Wide Web o simplemente WWW o Web es uno de los métodos más importantes de comunicación que existe en Internet. Consiste en un sistema de información basado en Hipertexto (texto

Más detalles

VÍDEO intypedia007es LECCIÓN 7: SEGURIDAD EN APLICACIONES WEB. INTRODUCCIÓN A LAS TÉCNICAS DE INYECCIÓN SQL. AUTOR: Chema Alonso

VÍDEO intypedia007es LECCIÓN 7: SEGURIDAD EN APLICACIONES WEB. INTRODUCCIÓN A LAS TÉCNICAS DE INYECCIÓN SQL. AUTOR: Chema Alonso VÍDEO intypedia007es LECCIÓN 7: SEGURIDAD EN APLICACIONES WEB. INTRODUCCIÓN A LAS TÉCNICAS DE INYECCIÓN SQL AUTOR: Chema Alonso Consultor de Seguridad en Informática 64. Microsoft MVP Enterprise Security

Más detalles

Modulo I. Introducción a la Programación Web. 1.1 Servidor Web.

Modulo I. Introducción a la Programación Web. 1.1 Servidor Web. Modulo I. Introducción a la Programación Web. 1.1 Servidor Web. Antes de analizar lo que es un servidor Web y llevara a cabo su instalación, es muy importante identificar diferentes elementos involucrados

Más detalles

LOGO. Modulo 2. Carlos Villanueva

LOGO. Modulo 2. Carlos Villanueva SSO5501 Hardening de un Sistema Operativo de Red LOGO Modulo 2 Carlos Villanueva Introduccion Hardering, del ingles Endurecimiento, se refiere al proceso de segurizar un Sistema o Aplicación Objetivos

Más detalles

La Capa de Aplicación Protocolos de Aplicación Básicos

La Capa de Aplicación Protocolos de Aplicación Básicos La Capa de Aplicación Protocolos de Aplicación Básicos mayo de 2008 DNS DNS (RFC 1034 y 1035) Idea básica: Cada nodo tiene un nombre único asignado a una dirección IP. El Sistema de Nombres de Dominio

Más detalles

FUNDAMENTOS DE REDES CONCEPTOS DE LAS CAPAS SUPERIORES

FUNDAMENTOS DE REDES CONCEPTOS DE LAS CAPAS SUPERIORES FUNDAMENTOS DE REDES CONCEPTOS DE LAS CAPAS SUPERIORES Dolly Gómez Santacruz dollygos@univalle.edu.co CAPA DE SESION Conceptos El propósito principal de la capa de sesión en la pila OSI es minimizar los

Más detalles

3-ANÁLISIS DE VULNERABILIDADES

3-ANÁLISIS DE VULNERABILIDADES 3-ANÁLISIS DE VULNERABILIDADES Es la tercera fase del ciclo de auditoria del tipo Hacking Ético, y tiene como objetivo el identificar si un sistema es débil o susceptible de ser afectado o atacado de alguna

Más detalles

Qué significan los errores más habituales que devuelve Apache y cómo solucionarlos?

Qué significan los errores más habituales que devuelve Apache y cómo solucionarlos? Qué significan los errores más habituales que devuelve Apache y cómo solucionarlos? Cardenal Gardoki, 1 48008 BILBAO (Vizcaya) Teléfono: 902 012 199 www.hostalia.com Para que las páginas web puedan estar

Más detalles

Servidores web. Qué es un servidor web? Tipos de servidores. Lic. Lorena Bernis

Servidores web. Qué es un servidor web? Tipos de servidores. Lic. Lorena Bernis Servidores web Qué es un servidor web? Tipos de servidores. Lic. Lorena Bernis Servidores web 2 SERVIDOR En informática, un servidor es un tipo de software que realiza ciertas tareas en nombre de los usuarios.

Más detalles

Tema 5. Tecnologías web. Antonio Sanz ansanz@unizar.es. Comercio Electrónico

Tema 5. Tecnologías web. Antonio Sanz ansanz@unizar.es. Comercio Electrónico Tema 5 Tecnologías web Antonio Sanz ansanz@unizar.es Comercio Electrónico Índice Gestión de un proyecto web Historia i de Internet t y la WWW Arquitecturas cliente/servidor Gestión de un proyecto web Introducción

Más detalles

Ataques XSS en Aplicaciones Web

Ataques XSS en Aplicaciones Web Ataques XSS en Aplicaciones Web Education Project Antonio Rodríguez Romero Consultor de Seguridad Grupo isoluciones antonio.rodriguez@isoluciones.es Copyright 2007 The Foundation Permission is granted

Más detalles

DESARROLLO DE APLICACIONES CON TECNOLOGÍAS WEB PROFESIONAL

DESARROLLO DE APLICACIONES CON TECNOLOGÍAS WEB PROFESIONAL Página 1 de 21 CUALIFICACIÓN DESARROLLO DE APLICACIONES CON TECNOLOGÍAS WEB PROFESIONAL Familia Profesional Informática y Comunicaciones Nivel 3 Código IFC154_3 Versión 5 Situación RD 1087/2005 Actualización

Más detalles

HTTP Introducción. Redes de Datos Ing. Marcelo Utard / Ing. Pablo Ronco FACULTAD DE INGENIERIA UNIVERSIDAD DE BUENOS AIRES

HTTP Introducción. Redes de Datos Ing. Marcelo Utard / Ing. Pablo Ronco FACULTAD DE INGENIERIA UNIVERSIDAD DE BUENOS AIRES Introducción Protocolo de capa de aplicación utilizado para la transferencia de Recursos u objetos. Opera sobre TCP típicamente en el puerto 80 Simple Stateless Genérico Utiliza las extenciones MIME. Transporte

Más detalles

Presentación del Curso Virtual PROGRAMACIÓN WEB PHP CON MYSQL BÁSICO

Presentación del Curso Virtual PROGRAMACIÓN WEB PHP CON MYSQL BÁSICO Presentación del Curso Virtual PROGRAMACIÓN WEB PHP CON MYSQL BÁSICO INNOVATIVA CENTRO DE TRANSFERENCIA Y DESARROLLO TECNOLÓGICO ESPE CECAI Capacitación Virtual La mejor opción para su crecimiento profesional

Más detalles

Redes de Computadores II

Redes de Computadores II Redes de Computadores II Capa de Aplicación HTTP Las siguientes láminas son material de apoyo para el estudio de la materia de Redes II. No son un contenido exhaustivo del material. Se recomienda suplementar

Más detalles

Circular de Tecnología Pautas de seguridad para el desarrollo de aplicaciones Web

Circular de Tecnología Pautas de seguridad para el desarrollo de aplicaciones Web ASIT 20070501 CT Pautas de seguridad para aplicaciones web v1 2007-05-16 Documento de Circular de Tecnología Pautas de seguridad para el desarrollo de aplicaciones Web Versión 01 ARCHIVO: ASIT 20070501

Más detalles

Ingeniero Técnico en Informática - UCA Máster en Ingeniería del Software - US Máster en Seguridad de las TIC - US

Ingeniero Técnico en Informática - UCA Máster en Ingeniería del Software - US Máster en Seguridad de las TIC - US Sobre mi Formación Ingeniero Técnico en Informática - UCA Máster en Ingeniería del Software - US Máster en Seguridad de las TIC - US Experiencia Aficiones 4+ años como desarrollador web, más de 2 en Drupal

Más detalles

Introducción a ataques de tipo inyección: Inyección SQL

Introducción a ataques de tipo inyección: Inyección SQL Introducción a ataques de tipo inyección: Inyección SQL Jorge Peris Cortés - jorpecor@alumni.uv.es Asignatura: Redes Ingeniería Informática - Curso 2011/2012 Universidad de Valencia 1 Índice INTRODUCCIÓN...

Más detalles

Evaluar el rendimiento de los servicios de comunicaciones. ANEXO CLIV

Evaluar el rendimiento de los servicios de comunicaciones. ANEXO CLIV 746 Miércoles 5 octubre 2005 Suplemento del BOE núm. 238 CE2.1 Identificar los distintos sistemas de archivo utilizables en un dispositivo de almacenamiento dado para optimizar los procesos de registro

Más detalles

TEMA 3: La Aplicación World Wide Web

TEMA 3: La Aplicación World Wide Web TEMA 3: La Aplicación World Wide Web 1. Introducción 2. Terminología 3. El protocolo HTTP 4. Conexiones HTTP 5. Mensajes HTTP 6. Interacción Usuario-Servidor 7. El GET condicional 8. Distribución de contenidos

Más detalles

Módulo II Unidad Didáctica 2

Módulo II Unidad Didáctica 2 Módulo II Unidad Didáctica 2 Introducción Una vez que el sitio está desarrollado y hemos cumplido con todas las etapas para su diseño es necesario incorporar algunos conceptos que nos permitan comprender

Más detalles

Catalogo cursos de Seguridad Informática

Catalogo cursos de Seguridad Informática Catalogo cursos de Seguridad Informática 1. Curso de Desarrollo Web Seguro Tema 1 El entorno Web 1.1 Introducción Introducción Arquitectura Web Problemas de seguridad más habituales: Comprensión de las

Más detalles

Seguridad en Sitios Web de Alto Tráfico. Ing. Enrique Hurtarte Juárez

Seguridad en Sitios Web de Alto Tráfico. Ing. Enrique Hurtarte Juárez Seguridad en Sitios Web de Alto Tráfico Ing. Enrique Hurtarte Juárez Guatemala, 24 de Julio de 2014 XumaK Quienes somos XumaK es una empresa que fue fundada en 2003 por Marcos Andres como una de las primeras

Más detalles

CUALIFICACIÓN CONFECCIÓN Y PUBLICACIÓN DE PÁGINAS WEB PROFESIONAL. Nivel 2. Versión 5 Situación RD 1201/2007 Actualización

CUALIFICACIÓN CONFECCIÓN Y PUBLICACIÓN DE PÁGINAS WEB PROFESIONAL. Nivel 2. Versión 5 Situación RD 1201/2007 Actualización Página 1 de 18 CUALIFICACIÓN CONFECCIÓN Y PUBLICACIÓN DE PÁGINAS WEB PROFESIONAL Familia Profesional Informática y Comunicaciones Nivel 2 Código IFC297_2 Versión 5 Situación RD 1201/2007 Actualización

Más detalles

Unidad IV: TCP/IP. 4.4 Protocolos a nivel aplicación

Unidad IV: TCP/IP. 4.4 Protocolos a nivel aplicación 4.4 Protocolos a nivel aplicación Sin embargo, aun en la capa de aplicación se necesitan protocolos de apoyo que permitan el funcionamiento de las aplicaciones reales; veremos tres de ellos antes de comenzar

Más detalles

PRACTICA CAPITULO 2 MODULO 1 PROTOCOLOS Y LA FUNCIONALIDAD DE LA CAPA DE APLICACIÓN

PRACTICA CAPITULO 2 MODULO 1 PROTOCOLOS Y LA FUNCIONALIDAD DE LA CAPA DE APLICACIÓN PRACTICA CAPITULO 2 MODULO 1 PROTOCOLOS Y LA FUNCIONALIDAD DE LA CAPA DE APLICACIÓN Los protocolos de capa de aplicación de TCP/IP más conocidos son aquellos que proporcionan intercambio de la información

Más detalles

Web : Ataque y Defensa. Claudio Salazar Estudiante Ing. Civil Informática UTFSM Pinguinux Team

Web : Ataque y Defensa. Claudio Salazar Estudiante Ing. Civil Informática UTFSM Pinguinux Team Web : Ataque y Defensa. Claudio Salazar Estudiante Ing. Civil Informática UTFSM Pinguinux Team Temario 1. Introducción 2. Cross Site Scripting (XSS) 3. Inyección SQL 4. Nuestro código en el servidor 5.

Más detalles

Proceso de Auditoría de la Seguridad de la Información en las Instituciones Supervisadas por la CNBS

Proceso de Auditoría de la Seguridad de la Información en las Instituciones Supervisadas por la CNBS Proceso de Auditoría de la Seguridad de la Información en las Instituciones Supervisadas por la CNBS Julio 2005 Proceso de Auditoría de la Seguridad de la Información en las Instituciones Supervisadas

Más detalles

MÓDULO: SERVICIOS E RED. Nombre: Curso: 2º SMR (9-6-2011) [Examen Final Junio]

MÓDULO: SERVICIOS E RED. Nombre: Curso: 2º SMR (9-6-2011) [Examen Final Junio] MÓDULO: SERVICIOS E RED Nombre: Curso: 2º SMR (9-6-2011) [Examen Final Junio] PARTE 1: Responde las siguientes preguntas tipo TEST. Solo hay una respuesta correcta. Dos respuestas incorrectas anulan una

Más detalles

Funcionamiento de Servicios Web, FTP

Funcionamiento de Servicios Web, FTP Funcionamiento de Servicios Web, FTP Tema 2.- Nivel de aplicación en Internet Dr. Daniel Morató Redes de Computadores Ingeniero Técnico en Informática de Gestión, 2º curso Material adaptado del libro Computer

Más detalles

HyperText Transfer Protocol

HyperText Transfer Protocol HyperText Transfer Protocol Ing. Carlos A. Barcenilla c.a.barcenilla@ieee.org Basado en HTTP Made Really Easy http://www.jmarshall.com/easy/http/ 1 Qué es HTTP? HTTP significa Hypertext Transfer Protocol.

Más detalles

Seguridad, Web y Java

Seguridad, Web y Java 2 Seguridad, Web y Java Seguridad, Web y Java Daniel López Janáriz d.lopez@uib.es Seguridad, Web y Java 3 1. Introducción: Puntos a tener en cuenta cuando hablamos de seguridad La seguridad al 100% no

Más detalles

Capítulo 5: PRUEBAS.

Capítulo 5: PRUEBAS. Capítulo 5: PRUEBAS. 5.1 Objetivos de las pruebas. Objetivos de las pruebas. Hoy en día el tema de la seguridad en software ya no resulta nada nuevo, en los inicios los desarrolladores de software no procuraban

Más detalles

INSTITUTO POLITECNICO NACIONAL Unidad Profesional Interdisciplonaria de Ingenierìa y Ciencias Sociales y Admonistrativas

INSTITUTO POLITECNICO NACIONAL Unidad Profesional Interdisciplonaria de Ingenierìa y Ciencias Sociales y Admonistrativas INSTITUTO POLITECNICO NACIONAL Unidad Profesional Interdisciplonaria de Ingenierìa y Ciencias Sociales y Admonistrativas W8: wexplor VIROLOGÌA Y CRIPTOLOGÌA 4NM73 W8:INTERNET EXPLORER U5: FILE TRANSFER

Más detalles

Especificaciones de la Interfaz Email para envío de SMS

Especificaciones de la Interfaz Email para envío de SMS Especificaciones de la Interfaz Email para envío de SMS Altiria TIC, S.L.L. Versión: 1.1 Copyright c Altiria TIC 2014 Este documento sólo puede ser reproducido por completo o en parte, almacenado, recuperado

Más detalles

Técnicas y Procedimientos para la realización de Test de Intrusión

Técnicas y Procedimientos para la realización de Test de Intrusión Extrelan 2008 Cáceres. Marzo de 2008 Técnicas y Procedimientos para la realización de Test de Intrusión SG6 Soluciones Globales en Seguridad de la Información http://www.sg6.es INDICE DE CONTENIDOS Primera

Más detalles

Práctica 4: Instalación y Gestión de Servicios en Sistemas 9Distribuidos.

Práctica 4: Instalación y Gestión de Servicios en Sistemas 9Distribuidos. Práctica 4: Instalación y Gestión de Servicios en Sistemas Distribuidos. Programación y Administración de Sistemas Segundo curso de Grado en Ingeniería Informática Javier Sánchez Monedero Dept. de Informática

Más detalles

PRACTICA CAPITULO 2 MODULO 1 PROTOCOLOS Y LA FUNCIONALIDAD DE LA CAPA DE APLICACIÓN

PRACTICA CAPITULO 2 MODULO 1 PROTOCOLOS Y LA FUNCIONALIDAD DE LA CAPA DE APLICACIÓN PRACTICA CAPITULO 2 MODULO 1 PROTOCOLOS Y LA FUNCIONALIDAD DE LA CAPA DE APLICACIÓN Los protocolos de capa de aplicación de TCP/IP más conocidos son aquellos que proporcionan intercambio de la información

Más detalles

Introducción al desarrollo WEB. Tecnologías Web

Introducción al desarrollo WEB. Tecnologías Web Introducción al desarrollo WEB Tecnologías Web Un poco de Historia World Wide Web (WWW) Inventada por Tim Berners Lee en 1989!!! Mientras trabajaba European Organization for Nuclear Research (CERN) http://www.w3.org/consortium/history.html

Más detalles

Poder Judicial de Tucumán Año 2013

Poder Judicial de Tucumán Año 2013 Internet y Correo electrónico El presente instructivo corresponde a una guía básica para el manejo de los programas y para la adquisición de conceptos en relación a estos utilitarios. No obstante ello,

Más detalles

SECURITY DAY PERU. Ataques a las Aplicaciones Web. Explotación de Aplicaciones Web. Technologies SOLUTIONS FOR KEEPING YOUR BUSINESS UP

SECURITY DAY PERU. Ataques a las Aplicaciones Web. Explotación de Aplicaciones Web. Technologies SOLUTIONS FOR KEEPING YOUR BUSINESS UP SOLUTIONS FOR KEEPING YOUR BUSINESS UP Email: info@ximark.com Tel. +(507) 271 5951 Tel. +(1) 928 752 1325 Aptdo. 55-0444, Paitilla. Panama City, Panama SECURITY DAY PERU Ataques a las Aplicaciones Web

Más detalles

Práctica de laboratorio 4.5.2: Protocolos de la capa de Transporte TCP/IP, TCP y UDP Diagrama de topología

Práctica de laboratorio 4.5.2: Protocolos de la capa de Transporte TCP/IP, TCP y UDP Diagrama de topología Práctica de laboratorio 4.5.2: Protocolos de la capa de Transporte TCP/IP, TCP y UDP Diagrama de topología Este documento es información pública de Cisco. Página 1 de 10 Tabla de direccionamiento Dispositivo

Más detalles

CAPITULO 4 DISEÑO DEL IDS

CAPITULO 4 DISEÑO DEL IDS CAPITULO 4 DISEÑO DEL IDS En este capítulo se describe el diseño del IDS presentado para este trabajo de Tesis. Se explican las consideraciones que se tomaron para realizar el diseño del mismo sistema

Más detalles

CUALIFICACIÓN CONFECCIÓN Y PUBLICACIÓN DE PÁGINAS WEB PROFESIONAL. Nivel 2. Versión 6. Actualización

CUALIFICACIÓN CONFECCIÓN Y PUBLICACIÓN DE PÁGINAS WEB PROFESIONAL. Nivel 2. Versión 6. Actualización Página 1 de 19 CUALIFICACIÓN CONFECCIÓN Y PUBLICACIÓN DE PÁGINAS WEB PROFESIONAL Familia Profesional Informática y Comunicaciones Nivel 2 Código IFC297_2 Versión 6 Situación Contraste externo Actualización

Más detalles

HTTP. Redes I. Departamento de Sistemas Telemáticos y Computación (GSyC) Noviembre de 2011. GSyC - 2011 HTTP 1

HTTP. Redes I. Departamento de Sistemas Telemáticos y Computación (GSyC) Noviembre de 2011. GSyC - 2011 HTTP 1 HTTP Redes I Departamento de Sistemas Telemáticos y Computación (GSyC) Noviembre de 2011 GSyC - 2011 HTTP 1 c 2011 Grupo de Sistemas y Comunicaciones. Algunos derechos reservados. Este trabajo se distribuye

Más detalles

Capítulo 4.- Recomendaciones para un Servidor web y de bases de datos seguro.

Capítulo 4.- Recomendaciones para un Servidor web y de bases de datos seguro. Capítulo 4.- Recomendaciones para un Servidor web y de bases de datos seguro. Este capítulo explica las características que un servidor web y de bases de datos seguro debe tener. Esto es esencial para

Más detalles

Especificación de la secuencia de mensajes que se han de intercambiar. Especificación del formato de los datos en los mensajes.

Especificación de la secuencia de mensajes que se han de intercambiar. Especificación del formato de los datos en los mensajes. SISTEMAS DISTRIBUIDOS DE REDES 2.- MODELOS ORIENTADOS A OBJETOS DISTRIBUIDOS 2.1. Tecnologías de sistemas distribuidos Para la implementación de sistemas distribuidos se requiere de tener bien identificados

Más detalles

Ministerio de Educación,Cultura y Deporte. Aulas en Red. Windows. Módulo 4: Servicios de Internet. FTP

Ministerio de Educación,Cultura y Deporte. Aulas en Red. Windows. Módulo 4: Servicios de Internet. FTP Ministerio de Educación,Cultura y Deporte. Aulas en Red. Windows Módulo 4: Servicios de Internet. FTP Aulas en red. Aplicaciones y servicios. Windows Servicio FTP Con anterioridad, en este mismo módulo

Más detalles

Marco Normativo de IT

Marco Normativo de IT Marco Normativo de IT ES0101 Estándar de Arquitectura para los Sistemas de Información e Infraestructura del Data Center Agencia de Sistemas de Información Gobierno de la Ciudad Autónoma de Buenos Aires

Más detalles

El IETF (Internet Ingineering Task Force, Equipo de Trabajo de Ingeniería de Internet)

El IETF (Internet Ingineering Task Force, Equipo de Trabajo de Ingeniería de Internet) ANEXOS Anexo 1: Protocolos de correo electrónico A continuación se presentan de forma resumida y funcional los protocolos de correo electrónico actualmente en vigor. Este análisis se centrará en aspectos

Más detalles

INTRODUCCIÓN A LA SEGURIDAD EN SISTEMAS Y WEBS

INTRODUCCIÓN A LA SEGURIDAD EN SISTEMAS Y WEBS INTRODUCCIÓN A LA SEGURIDAD EN SISTEMAS Y WEBS Marco A. Lozano Merino Mayo 2012 Índice 1.Seguridad a nivel de usuario 1.Amenazas y protección 2.La realidad de la seguridad: hackers 3.Seguridad en redes

Más detalles

GUÍA Nro. 1 TECNOLOGÍA DE INTERNET. TIII PIII

GUÍA Nro. 1 TECNOLOGÍA DE INTERNET. TIII PIII GUÍA Nro. 1 TECNOLOGÍA DE INTERNET. TIII PIII GUIA DISPONIBLE EN: http://preparadorivan.blogspot.com/ - http://preparadormssi.50webs.com/inicio.html La World Wide Web o la Web, es una de las múltiples

Más detalles

Recuperación de Información en Internet Tema 2: La web

Recuperación de Información en Internet Tema 2: La web Recuperación de Información en Internet Tema 2: La web P.O.P. Língua e usos profesionais Miguel A. Alonso Jorge Graña Jesús Vilares Departamento de Computación Facultad de Informática Universidade da Coruña

Más detalles

Curso XHTML/HTML/HTML5

Curso XHTML/HTML/HTML5 Curso XHTML/HTML/HTML5 Curso XHTML/HTML/HTML5 Servidores Web y FTP Desde el inicio del curso hemos estado creando documentos HTML en las máquinas locales. Introduciremos ahora el concepto de los Servidores

Más detalles

PROTOCOLOS HTTP Y HTTPS

PROTOCOLOS HTTP Y HTTPS Universidad Nacional Experimental Del Táchira (UNET) Decanato De Docencia Departamento de Ingeniería Informática Asignatura: Comunicaciones 1 18/7/2014 PROTOCOLOS HTTP Y HTTPS Autores: Jessica Ramírez

Más detalles

WHITEPAPER AUMENTANDO LA SEGURIDAD DE WORDPRESS

WHITEPAPER AUMENTANDO LA SEGURIDAD DE WORDPRESS WHITEPAPER AUMENTANDO LA SEGURIDAD DE WORDPRESS Índice Overview 4 Introducción 5 Qué es un CMS? Quién usa WordPress? Vulnerabilidades en WordPress Medidas de seguridad básicas 6-7 Mantener WordPress y

Más detalles

Telnet. Telnet Operación

Telnet. Telnet Operación Telnet Protocolo utilizado para la ejecución de procesos en sistemas remotos. Emulación de Terminal Utiliza las funcionalidades de TCP Well Known Service, port number 23 Telnet Operación NVT (Network Virtual

Más detalles

FileMaker 13. Guía ODBC y JDBC

FileMaker 13. Guía ODBC y JDBC FileMaker 13 Guía ODBC y JDBC 2004-2013 FileMaker, Inc. Reservados todos los derechos. FileMaker, Inc. 5201 Patrick Henry Drive Santa Clara, California 95054 FileMaker y Bento son marcas comerciales de

Más detalles

2.3.5 Capa de sesión. Protocolos

2.3.5 Capa de sesión. Protocolos 2.3.5 Capa de sesión Protocolos RPC El RPC (del inglés Remote Procedure Call, Llamada a Procedimiento Remoto) es un protocolo que permite a un programa de computadora ejecutar código en otra máquina remota

Más detalles

NOTA. HONEYPOT II Servicios con HoneyBOT. Objetivo: Usar un honeypot con varios servicios de interacción media. Herramientas necesarias:

NOTA. HONEYPOT II Servicios con HoneyBOT. Objetivo: Usar un honeypot con varios servicios de interacción media. Herramientas necesarias: HONEYPOT II Servicios con HoneyBOT Popularidad: 8 Simplicidad: 10 Impacto: 5 Nivel de Riesgo: 2 Objetivo: Usar un honeypot con varios servicios de interacción media Herramientas necesarias: HoneyBOT (http://www.atomicsoftwaresolutions.com/download.php)

Más detalles

Coordinación de Servicios de Cómputo. Sección Servicios CORREO ELECTRÓNICO NECHIKALI

Coordinación de Servicios de Cómputo. Sección Servicios CORREO ELECTRÓNICO NECHIKALI Coordinación de Servicios de Cómputo CORREO ELECTRÓNICO NECHIKALI Correo Nechikali Índice Tabla de contenido I.- Correo Electrónico... 3 1.- Definición de correo electrónico:... 3 2.- Qué es una dirección

Más detalles

MICROSOFT EXCHANGE 2007

MICROSOFT EXCHANGE 2007 MICROSOFT EXCHANGE 2007 En el momento de elaborar este documento en la URL http://technet.microsoft.com/enus/evalcenter/bb736128.aspx podíamos descargar una versión de prueba de Microsoft Exchange 2007.

Más detalles

Crear un servidor Web en IIS

Crear un servidor Web en IIS Crear un servidor Web en IIS Qué es un servidor web? Un servidor web es un programa que se ejecuta continuamente en un computador, manteniéndose a la espera de peticiones de ejecución que le hará un cliente

Más detalles

WAPITI. Escaner de vulnerabilidades de aplicaciones web y auditor de seguridad. VI OWASP Spain Chapter Meeting

WAPITI. Escaner de vulnerabilidades de aplicaciones web y auditor de seguridad. VI OWASP Spain Chapter Meeting ARGENTINA COLOMBIA CHILE ESPAÑA EE.UU. MÉXICO PANAMÁ VENEZUELA David del Pozo González dpozog@grupogesfor.com WAPITI Escaner de vulnerabilidades de aplicaciones web y auditor de seguridad Junio 2010 www.gesfor.es

Más detalles

DESARROLLO WEB EN ENTORNO SERVIDOR

DESARROLLO WEB EN ENTORNO SERVIDOR DESARROLLO WEB EN ENTORNO SERVIDOR CAPÍTULO 7: Programación de servicios Web Marcos López Sanz Juan Manuel Vara Mesa Jenifer Verde Marín Diana Marcela Sánchez Fúquene Jesús Javier Jiménez Hernández Valeria

Más detalles

Ministerio de Educación, Cultura y Deporte. Aulas en Red. Windows. Módulo 5: Servicio Microsoft Exchange

Ministerio de Educación, Cultura y Deporte. Aulas en Red. Windows. Módulo 5: Servicio Microsoft Exchange Ministerio de Educación, Cultura y Deporte. Aulas en Red. Windows Módulo 5: Servicio Microsoft Exchange Aulas en red. Aplicaciones y servicios. Windows Servicio Correo Electrónico En este apartado procederemos

Más detalles

Administración de sitios Web. Capítulo 8. Servidores Web: Internet Information Server

Administración de sitios Web. Capítulo 8. Servidores Web: Internet Information Server 1 of 9 4/15/2010 9:47 PM Anterior Administración de sitios Web Capítulo 8. Servidores Web: Internet Information Server Siguiente En este punto, nos centraremos en las tareas de administración del servidor

Más detalles

Especificación de requisitos de software Proyecto: SIS-WEB (Sistema de Información de Seminarios WEB) Revisión 1.0

Especificación de requisitos de software Proyecto: SIS-WEB (Sistema de Información de Seminarios WEB) Revisión 1.0 Especificación de requisitos de software Proyecto: (Sistema de Información de Seminarios WEB) Revisión 1.0 Tania Isadora Mora Dorance Moreno Luis Yovany Romo Septiembre 2007 Realizado Por: Tania I. Mora

Más detalles

FileMaker 14. Guía ODBC y JDBC

FileMaker 14. Guía ODBC y JDBC FileMaker 14 Guía ODBC y JDBC 2004-2015 FileMaker, Inc. Reservados todos los derechos. FileMaker, Inc. 5201 Patrick Henry Drive Santa Clara, California 95054 FileMaker y FileMaker Go son marcas comerciales

Más detalles

Utilizar los servicios de Index Service para buscar información de forma rápida y segura, ya sea localmente o en la red.

Utilizar los servicios de Index Service para buscar información de forma rápida y segura, ya sea localmente o en la red. Funciones de servidor La familia Windows Server 2003 ofrece varias funciones de servidor. Para configurar una función de servidor, instale dicha función mediante el Asistente para configurar su servidor;

Más detalles

AVG File Server. Manual del usuario. Revisión del documento 2015.08 (22.09.2015)

AVG File Server. Manual del usuario. Revisión del documento 2015.08 (22.09.2015) AVG File Server Manual del usuario Revisión del documento 2015.08 (22.09.2015) C opyright AVG Technologies C Z, s.r.o. Reservados todos los derechos. El resto de marcas comerciales son propiedad de sus

Más detalles

desarrollo. Dentro del desarrollo de la tesis el proceso de modelado del sistema fue hecho con el

desarrollo. Dentro del desarrollo de la tesis el proceso de modelado del sistema fue hecho con el Capitulo II. Análisis de herramientas y tecnologías de desarrollo. Dentro del desarrollo de la tesis el proceso de modelado del sistema fue hecho con el lenguaje de Modelo de Objetos llamado UML (Unified

Más detalles

CUALIFICACIÓN SISTEMAS DE GESTIÓN DE INFORMACIÓN PROFESIONAL. Nivel 3. Versión 5 Situación RD 1201/2007 Actualización

CUALIFICACIÓN SISTEMAS DE GESTIÓN DE INFORMACIÓN PROFESIONAL. Nivel 3. Versión 5 Situación RD 1201/2007 Actualización Página 1 de 16 CUALIFICACIÓN SISTEMAS DE GESTIÓN DE INFORMACIÓN PROFESIONAL Familia Profesional Informática y Comunicaciones Nivel 3 Código IFC304_3 Versión 5 Situación RD 1201/2007 Actualización Competencia

Más detalles

COMO ABORDAR LOS RECURSOS EN EL ENTORNO DE APRENDIZAJE PRACTICO

COMO ABORDAR LOS RECURSOS EN EL ENTORNO DE APRENDIZAJE PRACTICO COMO ABORDAR LOS RECURSOS EN EL ENTORNO DE APRENDIZAJE PRACTICO Debe ubicar el entorno de aprendizaje práctico y en el recurso lección desplegable dar clic (tal como se muestra en la figura). Este recurso

Más detalles

Introducción a Internet

Introducción a Internet Introducción a Internet 1 Índice de contenido Licencia y condiciones de uso...3 Introducción...4 Qué es FTP?...5 Obtención e instalación de Filezilla...6 Qué es Filezilla?...6 Obtención e instalación...7

Más detalles

VISIÓN GENERAL HERRAMIENTAS COMERCIALES

VISIÓN GENERAL HERRAMIENTAS COMERCIALES VISIÓN GENERAL El servidor de MS SQL se ha convertido en un estándar en muchas partes de la América corporativa. Puede manejar volúmenes de datos grandes y se integra bien con otros productos de Microsoft.

Más detalles

FIREWALL ZENTYAL ADELMO ANTONIO NAVARRO DAVILA 115-0028 WENDY DAYANA CARRASCAL VILLAMIZAR 1150458

FIREWALL ZENTYAL ADELMO ANTONIO NAVARRO DAVILA 115-0028 WENDY DAYANA CARRASCAL VILLAMIZAR 1150458 FIREWALL ZENTYAL ADELMO ANTONIO NAVARRO DAVILA 115-0028 WENDY DAYANA CARRASCAL VILLAMIZAR 1150458 PRESENTADO A: JEAN POLO CEQUEDA OLAGO ASIGNATURA: SEGURIDAD INFORMATICA UNIVERSIDAD FRANCISCO DE PAULA

Más detalles

El Hacking Ético y los Grupos Hackitivistas Anonymous y Lulzsec

El Hacking Ético y los Grupos Hackitivistas Anonymous y Lulzsec Metodología. www.dsteamseguridad.com La Metodología de la charla esta guiada por el concepto de cada una de las fases de ataque, con su respectiva demostración Arquitectura de Red (Laboratorio Virtual)

Más detalles

TEMA 37: Arquitecturas Cliente / Servidor. Tipos de cliente. Tipos de Servidor. Clasificación del software.

TEMA 37: Arquitecturas Cliente / Servidor. Tipos de cliente. Tipos de Servidor. Clasificación del software. . TEMA 37: Arquitecturas Cliente / Servidor. Tipos de cliente. Tipos de Servidor. Clasificación del software. Índice 1 INTRODUCCIÓN 2 2 CARACTERÍSTICAS 2 2.1 Características del cliente...2 2.2 Características

Más detalles

INSTRUCTIVO DE INSTALACION EN WINDOWS Y LINUX DE ALFRESCO COMMUNITY 4.2

INSTRUCTIVO DE INSTALACION EN WINDOWS Y LINUX DE ALFRESCO COMMUNITY 4.2 INSTRUCTIVO DE INSTALACION EN WINDOWS Y LINUX DE ALFRESCO COMMUNITY 4.2 Grupo de Innovación y Apropiación de Tecnologías de la Información Archivística Compilador: Pedro Antonio Gómez Guarín Contenido

Más detalles

ESET Remote Administrator 6. Version 6.0 Product Details

ESET Remote Administrator 6. Version 6.0 Product Details ESET Remote Administrator 6 Version 6.0 Product Details A pesar de que ESET Remote Administrator 6.0 es el sucesor de ESET Remote Administrator V5.x, representa un gran adelanto, ya que constituye una

Más detalles

HyperText Transfer Protocol

HyperText Transfer Protocol Qué es HTTP? HTTP significa Hypertext Transfer Protocol. HyperText Transfer Protocol Ing. Carlos A. Barcenilla c.a.barcenilla@ieee.org Es el protocolo de red que se utiliza para transferir los archivos

Más detalles

JOOMLA!, UNA HERRAMIENTA EDUCATIVA Y DE CENTROS

JOOMLA!, UNA HERRAMIENTA EDUCATIVA Y DE CENTROS JOOMLA!, UNA HERRAMIENTA EDUCATIVA Y DE CENTROS Tomás Clemente Carrilero. Profesor de enseñanza secundaria. Introducción. Joomla! es un sistema gestor de contenidos dinámicos (CMS, Content Management System)

Más detalles