Portafolio de evidencias programacion de interfaces web ii by Victor Ibarra

PORTAFOLIO DE EVIDENCIAS PROGRAMACION DE INTERFACES WEB II. VICTOR HUGO IBARRA ORTIZ.I NG. EN SISTEMAS COMPUTACIONALES. MATRICULA: 25113172. PROFESOR: DR. JOSÉ BENITO FRANCO URREA. HORARIO: 1-3 HRS. UNIDAD: CENTRO. CUATRIMESTRE: 8VO.

CD. OBREGON, SONORA A 18 DE MARZO DE 2014.

INDICE. INTRODUCCION. PERFIL DESCRIPTIVO. INFORMACION INSTITUCIONAL. SERVICIOS WEB. ARQUITECTURA BASICA DE PROTOCOLOS DE SERVICIOS WEB. PROTOCOLO SOAP: INTERCAMBIO DE MENSAJES. ESTRUCTURA DE LOS MENSAJES SOAP. PROTOCOLO WSDL: DESCRIPCION DE SERVICIOS. USOS DE WSDL. ELEMENTOS DE UNA ESPECIFICACION WSDL. PROTOCOLO UDDI: PUBLICACION DE SERVICIOS. DISPONIBILIDADES DE LOS WEB SERVICES. VULNERABILIDADES Y ATAQUES. DESAFIOS A LA SEGURIDAD DE LOS WEB SERVICES. PREVENCION Y MITIGACION. PRACTICAS EN CLASE. TRABAJOS DE INVESTIGACION. EXPOSICION EN CLASE. CONCLUSION. BIBLIOGRAFIA.

INTRODUCCION. La definición de Web Service de la W3C (WWW Consortium) [1] es: “Un Web Service es un sistema de software interoperable diseñado para dar apoyo a la interacción máquina a máquina sobre una red”. Esta interacción se realiza por medio de mensajes SOAP (Simple Object Access Protocol) transportados a través del protocolo HTTP mediante una serialización XML en conjunto con otros estándares Web. Un Web Service es descrito utilizando el estándar WSDL (Web Service Description Language) y almacenado en un repositorio UDDI (Universal Description and Discovery Interface). La Figura 1 muestra el esquema de relación de las tres tecnologías que conforman un Web Service: SOAP, WSDL y UDDI. Para que un Web Service funcione como tal, se necesita la interacción de dos entes, un consumidor y un proveedor del servicio. El proveedor pone a disposición un servicio describiéndolo por medio del estándar WSDL y almacenando su descripción en un registro UDDI. El consumidor consulta el registro UDDI buscando el servicio que desea obteniendo la descripción WSDL con el cual puede construir los mensajes SOAP apropiados enviándolos a través de una conexión HTTP(S) 1 para comunicarse con el servicio. El estándar WSDL provee múltiples formas para interactuar con un servicio, por ejemplo, un mismo servicio podría ser descrito para estar disponible por medio de mensajes SOAP enviados a través de HTTP(S) en un servidor y por medio de mensajes RMI/IIOP enviados a través de TCP/IP a otro servidor. Sin perjuicio de lo anterior, en la Figura 1 se describe el caso en el cual se utilizan mensajes SOAP enviados por medio de HTTP(S) ya que representa un modo de acceso abierto y ubicuo a un servicio a través de Internet, y es en éste escenario en donde la seguridad de los Web Services se ve disminuida.

Figura 1: Relación entre WSDL, UDDI y SOAP en un Web Service.

PERFIL DESCRIPTIVO.

UNIVERSIDAD DEL DESARROLLO PROFESIONAL

Perfil Descriptivo de Clase Materia:

PROGRAMACIÓN DE INTERFASES WEB II

Ciclo:

2014 -2

Maestro:

Dr. José Benito Franco Urrea

Horario:

13:00-15:00

Objetivo del Curso:

El alumno Adquirirá las habilidades para integrar los servicios de Web a la operación de una tienda virtual, elaborando una tienda virtual que le permita comercializar productos de manera electrónica, utilizando la Arquitectura orientada a servicios.

Bibliografía:

TIPO

TITULO

AUTOR

EDITORIAL/REVISTA

AÑO

Libro

Java 2 Manual de Programación

Joyanes McGraw-Hill Aguilar, Luis

2001

Libro

Web Standards Programmer's Reference: HTML, CSS, JavaScript, Perl, Python, and PHP Perl, CGI y Java Script

Schafer, Steven M.

Wrox

2005

Anaya Multimedia

2001

Libro

Java and XML

McLaughlin, O'Reilly Brett y Loukides, Mike

2000

Libro

Perl, CGI, and JavaScript Complete

Sybex Inc

2000

Libro

JavaScript: A Beginner's Guide

Pollock, John

McGraw-Hill Osborne Media

2003

Libro

criterios para la Evaluación

CALIFICACIÓN ORDINARIA (PONDERACIÓN) Actividades semanales

30%

Examen primer parcial.

15%

Portafolio reaprendizaje

10%

Examen segundo parcial.

25%

Trabajos independientes

20%

TOTAL

100%

Reglas 1. El alumno es responsable de enterarse de su número de faltas y retardos. 2. El alumno debe contar con un mínimo del 80% de asistencia para tener derecho a su calificación final. 3. El alumno que se sorprenda incurriendo en actos desleales en la elaboración de exámenes, tareas o trabajos, obtendrá cero (0) de calificación en el trabajo, tarea y/o examen 4. Es responsabilidad del estudiante hablar inmediatamente con el maestro cuando tenga problemas con el material de clase, sus calificaciones, etc. De esta manera evitaremos problemas en el fin del ciclo. 5. Sólo se justifican inasistencias si son autorizadas por la coordinación académica bajo el procedimiento correspondiente 6. Se tomara asistencia al iniciar la clase. 7. Prohibido utilizar teléfonos celulares y/o aparatos electrónicos dentro del aula. 8. La clase es de 100 minutos efectivos. 9. La clase inicia a la hora en punto 10. No se permiten alimentos ni bebidas dentro del aula. 11. Deberá presentar su Carnet de Pago, expedido por su coordinador administrativo, para la autorización de recepción de trabajos finales y la aplicación de exámenes en la última semana del módulo. Calendarización

Sesión

Fecha

17/02/2014

Tema

1. Presentación del programa de curso. 2. Inducción a la materia. 3. Formación de equipos y asignación de los temas para exposición de los alumnos. 4. Exposición en PowerPoint de los temas (Maestro). 5. Análisis y reflexión de los temas por parte del alumno, dudas de clase. 6. Directrices para elaborar el portafolio de alumno y el proyecto final. Temas: 1. Servicios Web (Web services) 1.1. Qué son los servicios de Web. 1.2. Utilización en la actualidad de los web services 1.3. Importancia para los negocios de la utilización de estos servicios. Instalación de Apache Instalación de PHP Instalación de una distribución de Apache: XAMPP

18/02/2014

1.4. Descripción del funcionamiento de los servicios de web. 1.5. Comparación entre la orientación a servicio y la orientación a objetos Ejercicios prácticos #1, #2 y #3 Introducción a PHP

19/02/2014

Entornos de desarrollo para PHP Recursos de PHP 1.6. Definición de tienda virtual. 1.7. Que productos pueden ofrecerse de manera electrónica.

20/02/2014

Exposición Artículo 1: Conoce qué es el comercio electrónico y cómo sacarle partido para tu negocio. Artículo 2: Emprender tu propia tienda online es todo un reto que puedes sortear atendiendo a las siguientes siete recomendaciones de nuestros expertos en Internet. 2.

24/02/2014

Programación interpretada (scripting)

2.1. Validación de datos 2.2. Mensajes y confirmaciones

25/02/2014

26/02/2014

27/02/2014

03/03/2014

04/03/2014

2. Eficiencia de los servicios web 2.1. Reducción de costo y aumento de eficiencia. 3. Sintaxis básica PHP Tipos de datos Variables Constantes Expresiones y operadores Estructuras de control Funciones Tablas Bibliotecas de funciones 2.2. Tecnologías base de los servicios web. Acceso a formularios HTML desde PHP El formulario de PHP Exposición artículos: Artículo3: Conéctate con el e-commerce. Artículo 4: -Sigue estos tips para vender tus productos en Facebook y ganar con esta estrategia de comercio electrónico. 3. Seguridad de los servicios Web 3.1. Uso de estándar para reducción de riesgos Programación en PHP Subida de ficheros al servidor Validación de los datos de un formulario Ejercicios Prácticos 3.2. Que hacer que no hacer en cuestión de seguridad 3.3. Análisis de riesgo. Exposición tema:

9 pasos para crear tu tienda online. Bases de datos en la Web Instalación y configuración de MySQL MySQL  Herramientas de administración: phpMyAdmin 11

05/03/2014

06/03/2014



Lenguaje SQL



Funciones de PHP para el acceso a bases de datos MySQL



Ejercicios



Consulta avanzada de tablas

EXAMEN PRIMER PARCIAL

4. Implementación de los servicios web 13

10/03/2014

11/03/2014

12/03/2014

13/03/2014

4.1. Estándares de mercado Manejo de sesiones Autenticación de usuarios Ejercicios prácticos 4.2. Estrategias de las distintas compañías Ejercicios prácticos Análisis y reflexión de los temas por parte del alumno, dudas de clase. Ejercicios prácticos Análisis y reflexión de los temas por parte del alumno, dudas de clase.

4.3. Modelo de negocio para los servicios web

4.4. Planeación de proyectos para una Arquitectura orientada a Servicios. 17

18 19 20

17/03/2014 18/03/2014 19/03/2014 20/03/2014

Exposición tema: -Aumente las ventas de su tienda virtual. Revisión final del portafolio y proyecto final EXAMEN SEGUNDO PARCIAL ENTREGA DE CALIFICACIONES ORDINARIAS EXAMEN EXTRAORDINARIOS

INFORMACION INSTITUCIONAL. Misión. La misión de UNIDEP es formar profesionales de éxito que cuenten con las actitudes, habilidades y conocimientos que demanda el sector productivo de la región. Visión. La Universidad del Desarrollo Profesional es una institución de educación superior de calidad, que ofrece programas presenciales y semis presenciales de bachillerato, profesional asociado, licenciatura, posgrado, diplomados y cursos en México y en el extranjero. Se distingue por facilitar a sus egresados la incorporación al mercado de trabajo, apoyada en una estrecha vinculación con el sector productivo y en planes de estudio pertinentes y dinámicos. Es reconocida por su modelo educativo profesionalizan te, por la flexibilidad de su oferta académica impartida en ciclos continuos y por horarios y cuotas accesibles, acordes a la disponibilidad de tiempo y recursos económicos del alumno. Cuenta con profesores de amplia experiencia profesional y educativa. Sus instalaciones dentro de la ciudad permiten el fácil acceso. Cuenta con un modelo de administración sistematizado, participativo, operado por personal que es recompensado por su desempeño efectivo que le permite maximizar las aportaciones de sus socios y mantener finanzas sanas. VALORES UNIDEP: Lealtad: Los integrantes de la comunidad universitaria consideramos la fidelidad como un valor excelso que enaltecemos en nuestro quehacer diario. Justicia: Los integrantes de la comunidad universitaria actuamos con la constante y perpetua voluntad de dar a cada cual lo que le corresponde conforme a sus méritos o actos. Honestidad: Los integrantes de la comunidad universitaria actuamos con sinceridad y honradez en nuestras tareas y en congruencia entre los pensamientos, palabras y acciones. Responsabilidad: Los integrantes de la comunidad universitaria llevamos a cabo nuestras actividades con integridad, con sentido del propósito y apegados a los objetivos institucionales.

Esfuerzo: Los integrantes de la comunidad universitaria usamos nuestra mĂĄxima energĂa para cumplir con los objetivos trazados. Creatividad: Los integrantes de la comunidad universitaria resolvemos los problemas con imaginaciĂłn, conocimientos y con un espĂritu.

SERVICIOS WEB. Un Servicio Web es un componente software que puede ser registrado, descubierto e invocado mediante protocolos estándares de Internet. 

Permiten exponer y hacer disponibles funcionalidades (servicios) de los sistemas informáticos de las organizaciones mediante tecnologías y protocolos WEB estándar.



Cada Servicio Web se responsabilidad de realizar un conjunto de funciones concretas y bien deﬁnidas.



Servicios Web actúan como componentes independientes que se pueden integrar para formar sistemas distribuidos complejos

Definición: (del World Wide Web Consortium [W3C]) ”Un Servicio Web (Web Service [WS]) es una aplicación software identificada por un URI (Uniform Resource Identifier ), cuyas interfaces se pueden definir, describir y descubrir mediante documentos XML. Los Servicios Web hacen posible la interacción entre ”agentes” software (aplicaciones) utilizando mensajes XML intercambiados mediante protocolos de Internet.” Puntos clave: interoperabilidad, uso de estándares abiertos, mínimo acoplamiento. Interoperabilidad: distintas aplicaciones, en lenguajes de programación diferentes, ejecutadas sobre cualquier plataforma, pueden utilizar los Servicios Web para intercambiar datos •La interoperabilidad se consigue mediante el uso de estándares abiertos. • Servicios Web se asientan sobre protocolos y estándares ya existentes y muy difundidos (HTTP, XML, etc) • Uso de protocolos específicos extensibles ⇒ no imponen restricciones sobre las aplicaciones a las que dan acceso ni sobre las tecnologías que las implementan (independencia de lenguaje y de plataforma) • OASIS y W3C: organizaciones responsables de definir la arquitectura y estándares para los Servicios Web Pueden verse como una evolución de los mecanismos RPC •Uso de protocolos estándar de internet (HTTP, SMTP) como mecanismo para el transporte de los mensajes (invocación, respuesta, ...) ◦ Mensajes intercambiados se encapsulan dentro de mensajes HTTP (o SMTP) ◦ Evitan problemas con firewalls y filtrado de puertos no privilegiados ◦ Para la red el tráfico de Servicios Web es tráfico HTTP (o SMTP) normal • Uso de lenguajes basados en XML ◦ Los mensajes intercambiados son representados en documentos XML

◦ Servicios y métodos remotos son descritos en documentos XML Escenario típico: Integración de un conjunto de aplicaciones de distintas empresas/organizaciones 

Aplicaciones distribuidas convencionales se basan en el uso de un middleware común y centralizado (ORBs en CORBA, RMI en Java, etc)

Serv. Web permiten superar esa restricción: no exigen middleware único común, middleware abierto y no centralizado Servicios Web ofrecen un punto de entrada a los sistemas de información locales • Encapsulan una o más aplicaciones ofreciendo un interfaz único accesible por la Web • Ofrecen un interfaz público y estable, independiente de su implementación concreta • Facilitan la automatización de las interacciones entre los procesos internos de una organización con el exterior Ejemplo: uso de Servicios Web

Concepto clave: servicio Un servicio es un procedimiento, un método o un objeto con una interfaz estable y pública que puede ser invocado por un cliente •Los Servicios Web amplían esa idea para permitir que esa invocación se realize a través de internet empleando protocolos Web estándar ya existentes Arquitectura Orientada a Servicios (SOA) • Aproximación al diseño de aplicaciones complejas basada en: ◦ la identificació n de los servicios que ofrecerá ◦ la definición de esos servicios ◦ la organización de las interacciones entre esos servicios • Importancia de las interfaces ◦ Descripción rigurosa de las interfaces ◦ Tratamiento automático para generar código de implementación ◦ Idea base: desarrollar el sistema a partir de las interfaces • Los servicios ofrecen operaciones a los clientes que deben ser invocadas en un orden determinado para lograr el objetivo deseado ◦Servicios simples vs. serv. compuestos (implementados invocando otros servicios) ◦Necesidad de especificar reglas que gobiernen el intercambio (conversación) entre servicios ⇒ protocolos de negocio ◦ BPEL: Business Process Execution Language for Web Services ¦ Lenguaje (derivado de XML) que permite especificar las interacciones entre servicios (normalmente Servicios Web) ¦ Soporta la composición de servicios simples para crear servicios compuestos

ARQUITECTURA BASICA DE PROTOCOLOS DE SERVICIOS WEB.

Elementos necesarios para la deﬁnición de Servicios Web 1. Sintaxis común para todas la especiﬁcaciones ⇒ uso de XML

XML: eXtensible Markup Language • Estándar para la definici ón de lenguajes de marcas • Flexible y extensible Metalenguaje usado en Servicios Web para especificar los lenguajes y protocolos necesarios • Permite definición de lenguajes para: describir servicios, representar mensajes intercambiados

2. Mecanismos de interacción entre extremos ⇒uso de SOAP (Simple Object Access Protocol ) Necesidad de un formato de mensajes neutro, abierto y extensible • representación de mensajes de invocación (argumentos) y respuesta (valor retorno) como documentos XML 

Especiﬁcación del modo de interacción: síncrono (RPC: peticiónrespuesta), asíncrono (petición).



Mapeo de los mensajes en el protocolo de transporte (HTTP, SMTP)

3. Lenguaje común para describir los servicios ⇒ uso de WSDL (Web Service Description Language)  Descripción de los servicios y sus interfaces de forma estándar mediante documentos XML

 

Papel análogo al del IDL en middleware convencional Incluye toda la información necesaria para suplir la falta de un middleware común centralizado • Especifica cada operación disponible, con sus parámetros de entrada y de salida • Puede usarse para generar los stubs/skeleton y las capas intermedias necesarias para escribir: clientes que invoquen los Servicios Web, servidores que los implementen • Especificar información sobre la localización del servicio (URIs) 4. Publicación y localización de servicios ⇒ uso de UDDI (Universal Description, Discovery and Integration) La descripción de los servicios (documentos WSDL) se almacena en un directorio de servicios UDDI especifica cómo : se publican y descubren los servicios, trabajan los directorios de servicios Web Acceso al directorio UDDI mediante Servicios Web ⇒ uso mensajes SOAP • servidor da de alta de servicios (documentos WSDL + descripción) • cliente ”descubre” servicios (documentos WSDL) Algunas implementaciones Java API for XML Web Services: JAX-WS + JAX-RPC • Forman parte de la especificación Java EE 5 (Java Enterprise Edition) ◦ Implementaciones incluidas en los servidores de aplicaciones Java EE • Implementación de referencia METRO (incluida en Java SE 6 [jdk 1.6]) Apache AXIS2 (Java y C) [http://ws.apache.org/axis2] • La versión anterior (AXIS) incluye soporte para C++ •http://ws.apache.org/axis/cpp/index.html Perl: SOAP::Lite [http://www.soaplite.com]

PROTOCOLO SOAP: INTERCAMBIO DE MENSAJES. SOAP: Simple Object Access Protocol   

Objetivo: Especificar como organizar la información de forma estructurada y tipada usado XML para que sea intercambiada entre los extremos de la invocación por Especificado el W3C (versión actual 1.2) http://www.w3.org/2000/xp/Group/ http://www.w3c.es/Traducciones/es/TR/2003/REC-soap12-part0-20030624/ Derivado de protocolo XML-RPC • XMLR-RPC: formato XML para enviar invocaciones de métodos ◦ nombre método + codificació n de la lista de parámetros ◦ limitado en cuanto a tipos de datos soportados

Protocolo SOAP especifica: Formato de mensajes común y extensible: describe cómo se organiza en forma de documentos XML la información a intercambiar Conjunto de normas para implementar RPC mediante mensajes SOAP Reglas a seguir por las entidades (cliente o servidor) que procesen los mensajes SOAP • indica elementos a tratar u omitir, quien debe hacerlo y los tipos de acciones a realizar Descripción del modo en que se envían los mensajes SOAP sobre el protocolo de transporte (HTTP o SMTP) Características SOAP define un intercambio de mensajes sin estado • Posibilidad de soportar comunicaciones con estado añadiendo información adicional (IDs ´únicos) en la cabecera de los mensajes SOAP (≈ cookies) Define una comunicación en una sola dirección • Interacciones más complejas son gestionadas por los extremos • Esquemas síncronos (RPC): mensaje petición + mensaje respuesta • Esquemas asíncronos: sólo mensaje petición SOAP no impone intercambiados

restricciones

sobre

semántica

los

mensajes

• SOAP sólo ofrece la infraestructura para transferir esos mensajes • El signiﬁcado de los mensajes (etiquetas XML) es interpretado por los extremos ◦ SOAP es independiente del modelo de datos de la aplicación SOAP no se encarga de cuestiones de ﬁabilidad, integridad de los mensajes, transacciones, seguridad, etc • La gestión de esos aspectos es responsabilidad de la infraestructura/aplicación que implementa el Servicio Web Nota: La implementación de los Servicios Web es responsabilidad del extremo que lo ofrece y debe encargarse de interpretar el contenido de los mensajes SOAP El extremo contará con un servidor Web que recibirá la petición SOAP y la redirigirá a la implementación del servicio Web La implementación real del Servicio Web puede residir en un CGI (Common Gateway Ieterface), un Servlet, un objeto CORBA, un Componente EJB (enterprise Java Bean), un Procedimiento Almacenado de un SGBD, etc, .

ESTRUCTURA DE LOS MENSAJES SOAP. SOAP ofrece soporte para el envío de datos de aplicación arbitrarios • Deﬁne la estructura de un ”contenedor” de mensajes XML • No establece restricciones sobre el contenido del mensaje ni sobre el procesamiento a realizar con el ◦ XML-RPC usaba etiquetas predeﬁnidas (diferencia con SOAP)

(a) Mensaje SOAP: SOAP envelope (2 partes) Cabecera (etiqueta <Header>): componente opcional • Contiene información sobre el mensaje a usar por la infraestructura de Servicios Web ◦ identificadores de transacciones ◦ información de seguridad (claves, certificados, etc) ◦ otros: prioridades, identificadores de origen y/o destino, etc • Atributos mustUnderstand actor indican que componente debe encargarse de interpretar esa cabecera (extremos de la comunicación, puntos intermedios) • Puede estructurarse en bloques Cuerpo (etiqueta <Body>): componente obligatorio • Contiene información específica a usar por las aplicaciones que usan o implementan el Servicio Web

◦ los extremos son los responsables de acordar el formato de la información intercambiada y de generar y/o procesar su contenido • Puede estructurarse en bloques ◦ Usualmente los bloques mapean una invocación o respuesta RPC en formato XML ¦ Esquema usual: codificación de parámetros y valor de retorno ¦ Suele hacerse uso de los tipos de datos definidos en la especificación XML Schema ¦ XML Schema permite representar en XML tipos simples (enteros, reales,...) tipo compuestos (estructuras, arrays,...) ◦ Bloque especial fault: usado para representar errores en el procesamiento de mensajes SOAP ¦ identificación del error (código de fallo) ¦ explicación legible del fallo ¦ origen del fallo SOAP no establece ninguna restricción en el contenido y estructura de los bloques incluidos en ambas secciones • Aunque sí existen recomendaciones y practicas comúnmente aceptadas (b) Bindings SOAP La especificació n SOAP es independiente del protocolo de transporte usado para transferir los mensajes • SOAP sólo define un contenedor de ”mensajes” y la forma de encapsularlos en el protocolo de transporte que se use binging SOAP: descripción de cómo se envía un mensaje SOAP utilizando un protocolo de transporte determinado • Incluye la forma de especificar las direcciones de origen y destino El binding típico de SOAP hace uso de mensajes HTTP para encapsular mensajes SOAP • Peticiones HTTP POST:se envía el mensaje SOAP en el cuerpo de la petición HTTP, la respuesta HTTP contiene un mensaje SOAP (respuesta o Fault) El estándar también define bindings de SOAP sobre mensajes del protocolo SMTP (e-mail) La dirección de destino toma la forma de una URL en binding sobre HTTP (o el campo to: en bindings SMTP)

Ejemplo mensajes SOAP

Petici贸n SOAP sobre un mensaje POST de HTTP POST /WeatherForecast.asmx HTTP/1.1 Host: www.webservicex.net Content-Type: text/xml; charset=utf-8 Content-Length: 446 SOAPAction: "http://www.webservicex.net/GetWeatherByPlaceName" <?xml version="1.0" encoding="utf-8"?> <soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="htt://www.w3.org/2001/XMLSchema" xmns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Head> <userID>010243</userID> <transactionID>02394800231</transactionID> </soap:Head> <soap:Body> <GetWeatherByPlaceName xmlns="http://www.webservicex.net"> <PlaceName>Las Vegas</PlaceName> </GetWeatherByPlaceName> </soap:Body> </soap:Envelope>

Respuesta SOAP sobre una respuesta HTTP HTTP/1.1 200 OK Content-Type: text/xml; charset=utf-8 Content-Length: 1637 <?xml version="1.0" encoding="utf-8"?> <soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Body> <GetWeatherByPlaceNameResponse xmlns="http://www.webservicex.net"> <GetWeatherByPlaceNameResult> <Latitude>36.17208</Latitude> <Longitude>115.122368</Longitude> <AllocationFactor>0.033507</AllocationFactor> <FipsCode>32</FipsCode> <PlaceName>LAS VEGAS</PlaceName> <StateCode>NV</StateCode> <Details> <WeatherData> <Day>Sunday, December 7, 2008</Day> <WeatherImage> ... </WeatherImage> ... <MaxTemperatureC>9</MaxTemperatureC> <MinTemperatureC>1</MinTemperatureC> </WeatherData> ... <WeatherData> <Day>Thursday, December 11, 2008</Day> <WeatherImage> ... </WeatherImage> ... <MaxTemperatureC>17</MaxTemperatureC> <MinTemperatureC>5</MinTemperatureC> </WeatherData> </Details> </GetWeatherByPlaceNameResult> </GetWeatherByPlaceNameResponse> </soap:Body> </soap:Envelope>

PROTOCOLO WSDL: DESCRIPCION DE SERVICIOS. WSDL: Web Services Description Language Middleware convencional: lenguajes de definición de interfaces (IDL) Servicios Web necesitan una descripción de interfaces más rica e independiente de la plataforma Definición de operaciones: nombre, argumentos (nombre + tipo), valor retorno Definición de mecanismos de interacción (bindings) • Sistemas distribuidos convencionales usan siempre el mismo middleware • En Servicios Web cada servicio se puede servir con distintos protocolos (HTTP, SMTP) Especificación de la localización del servicio (URI del servicio) • Localización a donde enviar los mensajes SOAP Descripción del Servicio Web está basada en documentos XML conforme a la especificación WSDL • http://www.w3.org/2002/ws/desc/

USOS DE WSDL. Como lenguaje de descripción de interfaz del servicio (IDL) Describe el interfaz que implementa el Servicio Web (contrato entre cliente y servidor) Indica cómo interactuar con el servicio: operaciones definidas, datos a enviar y devolver, formato mensajes + protocolo transferencia Como entrada para compiladores/generadores de stubs y/o skeleton Las aplicaciones no escriben ni procesan directamente los mensajes XML SOAP A partir de la definición WSDL del Servicio Web se generan los elementos adicionales necesarios para que: servidor implemente el Servicio Web cliente realice la llamada al Servicio Web • stubs y/ skeletons • Objetos y/o procedimientos para serializar los datos en el formato de los mensajes SOAP usados por cada Servicio Web concreto Ejemplos: wsimport en Java JAX-WS, WSDL2java en Apache Axis También es habitual contar con generadores WSDL que crean la Especificación WSDL a partir de las implementaciones de los Servicios Web wsgen de Java: crea fichero WSDL a partir del código Java de una clase

ELEMENTOS DE UNA ESPECIFICACION WSDL. Documento WSDL describe un servicio Web como una colección de ports (puertos) [extremos de la comunicación (end points)] capaces de intercambiar mensajes • Cada port tiene: una definició n abstracta (port type) [operaciones y mensajes], una definición concreta (binding ) [protocolos] Elemento <definitions>: raíz del documento WSDL • Usado para declarar espacios de nombres (XML namespace) Parte abstracta Equivalente al lenguaje IDL de sistemas distribuidos convencionales • Describe de forma abstracta los servicios Web en términos de operaciones y mensajes elemento <types>: Define los tipos y estructuras de datos de los datos intercambiados elemento <message>: Define los mensajes (datos que van a ser intercambiados), indicando su nombre y su contenido • Un mensaje para un servicio concreto contendrá un conjunto de partes [elemento <part>] • Cada parte está caracterizadas por un nombre y un tipo (definido en la sección types) elemento <portType>: Define grupos de operaciones (ports, puertos) Para cada operación (elemento <operation>) se le asigna un nombre y se especifica el intercambio de mensajes [4 tipos] • one-way: cliente invoca servicio enviando un único mensaje (asíncrono) • notifications: servidor envían un mensaje (asíncrono) • request-response: servidor recibe petición y responde (síncrono) • solicit-response: servidor invoca y espera respuesta (síncrono) Parte concreta Se encarga de definir (concretar) la instancia real del servicio • Especifica aspectos relativos al uso del servicio Web: puertos que implementa, protocolos de transporte usados, dirección donde se ubica, codificació n de mensajes usada

elemento <bindings>: Asocia a un grupo de operaciones (portType) una especificación d e la codificación de mensajes y el protocolo de transporte (atributo transport) a utilizar. • Informa a los usuarios del Servicio Web (clientes o servidores) de los protocolos a usar, de cómo estructurar los mensajes XML y de lo que se espera recibir al enviar un mensaje • WSDL permite bindings para SOAP, HTTP GET, HTTP POST y MIME (SMTP) • En el caso de usar SOAP como mecanismo de intercambio de mensajes el binding contiene toda la información necesaria para construir y procesar automáticamente los mensajes SOAP (atributo encodingStyle) elemento <service>: Especifica una agrupación lógica de puertos (port) • Opcionalmente puede incluir una descripción textual del servicio (elemento <description>) • Cada puerto (elemento <port>) especifica un punto fin al (endpoint) [destino final de la comunicación] ◦ Asocia la información de los bindings (conjuntos de operaciones) a la dirección (URI) donde se accederá a sus implementaciones ◦ port ≈ portType + binding + localización

Ejemplo documento WSDL <wsdl:definitions targetNamespace="http://www.webservicex.net"> <wsdl:types> <s:schema targetNamespace="http://www.webservicex.net"> <s:complexType name="WeatherForecasts"> <s:sequence> <s:element minOccurs="1" maxOccurs="1" name="Latitude" type="s:float"/> <s:element minOccurs="1" maxOccurs="1" name="Longitude" type="s:float"/> ... <s:element minOccurs="0" maxOccurs="1" name="Details" type="tns:ArrayOfWeatherData"/> </s:sequence> </s:complexType> <s:complexType name="ArrayOfWeatherData"> <s:sequence> <s:element minOccurs="0" maxOccurs="unbounded" name="WeatherData" type="tns:WeatherData"/> </s:sequence> </s:complexType> <s:complexType name="WeatherData"> <s:sequence> <s:element minOccurs="0" maxOccurs="1" name="Day" type="s:string"/> ... <s:element minOccurs="0" maxOccurs="1" name="MaxTempC" type="s:string"/> <s:element minOccurs="0" maxOccurs="1" name="MinTempC" type="s:string"/> </s:sequence> </s:complexType> ... <s:element name="GetWeatherByPlaceName"> <s:complexType> <s:sequence> <s:element minOccurs="0" maxOccurs="1" name="PlaceName" type="s:string"/> </s:sequence> </s:complexType> </s:element> <s:element name="GetWeatherByPlaceNameResponse"> <s:complexType> <s:sequence> <s:element minOccurs="1" maxOccurs="1" name="GetWeatherByPlaceNameResult" type="tns:WeatherForecasts"/> </s:sequence> </s:complexType> </s:element> </s:schema> </wsdl:types>

<wsdl:message name="GetWeatherByPlaceNameSoapIn"> <wsdl:part name="parameters" element="tns:GetWeatherByPlaceName"/> </wsdl:message> <wsdl:message name="GetWeatherByPlaceNameSoapOut"> <wsdl:part name="parameters" element="tns:GetWeatherByPlaceNameResponse"/> </wsdl:message> <wsdl:portType name="WeatherForecastSoap"> <wsdl:operation name="GetWeatherByPlaceName"> <wsdl:input message="tns:GetWeatherByPlaceNameSoapIn"/> <wsdl:output message="tns:GetWeatherByPlaceNameSoapOut"/> </wsdl:operation> </wsdl:portType> <wsdl:binding name="WeatherForecastSoap" type="tns:WeatherForecastSoap"> <soap:binding transport="http://schemas.xmlsoap.org/soap/http" style="document"/> <wsdl:operation name="GetWeatherByPlaceName"> <soap:operation soapAction="http://www.webservicex.net/GetWeatherByPlaceName" style="document"/> <wsdl:input> <soap:body use="literal"/> </wsdl:input> <wsdl:output> <soap:body use="literal"/> </wsdl:output> </wsdl:operation> </wsdl:binding> <wsdl:service name="WeatherForecast"> <documentation> Get one week weather forecast for valid zip code or Place name in USA </documentation> <wsdl:port name="WeatherForecastSoap" binding="tns:WeatherForecastSoap"> <soap:address location="http://www.webservicex.net/WeatherForecast.asmx"/> </wsdl:port> </wsdl:service> </wsdl:definitions>

PROTOCOLO UDDI: PUBLICACION DE SERVICIOS. UDDI: (Universal Description, Discovery and Integration) Protocolo para interaccionar con un servidor (registro UDDI) que proporciona operaciones (vía SOAP) para registrar y buscar (descubrir) Servicios Web Cada servicio se registra dando su nombre, una descripción del servicio (URL de su WSDL, una descripción textual, etc.) Uso de UDDI mediante APIs de programación basadas en SOAP • El API de UDDI está especificada con WSDL ⇒ uso de mensajes SOAP • Alta (publicación) de Servicios Web por parte de los servidores • Localización (descubrimiento) de Servicios Web por parte de los cliente Finalidad: • Ofrecer soporte para encontrar información sobre servicios web y poder construir clientes • Facilitar el enlace dinámico, permitiendo consultar referencias y acceder a servicios de interés en tiempo de ejecución (descubrir servicios e invocarlos ”al vuelo”) Especificación: http://uddi.xml.org Tipos de información ofrecida Páginas blancas : Identificador y dirección de contacto de la empresa/organización que publica el Servicio Web Páginas amarillas : Descripciones de los Servicios Web ofrecidos usando diferentes tipos de categorizaciones (taxonomías)  NAICS-North American Industry Classification System, UNSPSC-Universal Standard Products and Services Classification, etc Páginas verdes : Info. técnica sobre los servicios web (URL de descarga del WSDL)

DEBILIDAD DE LOS WEB SERVICES. La debilidad principal de los Web Services está dada por el modelo de interacción entre el consumidor y el proveedor del servicio. De la Figura 1 se puede observar lo siguiente: El proveedor debe describir el servicio utilizando el estándar WSDL dando los detalles de cómo comunicarse con él. Esta descripción da bastante y preciada información a un consumidor malicioso para reunir antecedentes fácilmente al consultar el registro UDDI. Lo anterior da una ventaja al consumidor malicioso de Web Services por sobre un usuario malicioso de Aplicaciones Web ya que para este último es menos fácil saber qué tipo de parámetros espera la aplicación y qué contenido devolverá al navegador (browser) para ser desplegadas al usuario. Por otra parte, podemos descubrir otras debilidades al realizar un paralelo entre las Aplicaciones Web y Web Services ya que comparten características similares: • Los Web Services pertenecen a la capa de Aplicación del modelo OSI al igual que las Aplicaciones Web. Las organizaciones se han preocupado de mitigar las vulnerabilidades de las capas inferiores utilizando Firewalls, IDS, HIDS y Antivirus (Figura 2), pero han dejado desprotegida la capa donde residen las aplicaciones con las cuales realizan transacciones con sus clientes y usuarios, en particular, los Web Services son una tecnología que permite implementar una Arquitectura Orientada a los Servicios (SOA, Service Oriented Architecture) con un énfasis en las transacciones entre empresas (B2B, Business to Business) donde no siempre es necesaria una relación previa. Esto representa un atractivo económico bastante mayor para un usuario malicioso ya que en las Aplicaciones Web generalmente se realizan transacciones con personas (B2C Business to Consumer y C2C Consumer to Consumer). Los Web Services utilizan HTTP(S) para el envío de mensajes SOAP. Por lo general para el protocolo HTTP(S) se utilizan los puertos de conexión estándares 80 y 443 los cuales son permitidos en la mayoría de los Firewalls de Red de la mayoría de las organizaciones (Figura 3). Estos Firewalls no poseen la capacidad de analizar el tráfico HTTP(S) y menos aún las sentencias XML de los mensajes SOAP que circulan por este protocolo. Por otra parte, HTTPS provee seguridad en la comunicación mientras los mensajes son transportados, no cuando los mensajes son emitidos y/o recibidos por los participantes, además no permite intermediarios y no provee norepudiación. 

Los Web Services son accesibles desde Internet por cualquier usuario conectado a la red. Debido a la diversidad de formas de acceso a Internet que hay en la actualidad (PDAs, Notebooks, Teléfono, Wi-Fi, Bluetooth) y a la ubicuidad que dan a un usuario, el nivel de exposición de la organización aumenta y por ende su clasificación de riesgo. Este riesgo variará entre una organización y otra ya que una puede proveer servicios que sólo entreguen



información, mientras que otra puede proveer servicios que realicen transacciones críticas para su negocio. Los Web Services acceden al back-end de la organización. El diseño en tres capas de las Aplicaciones Web (Capa de presentación, Capa de Control, Capa de Aplicación) también se aplica a Web Services ya que éstos son aplicaciones Web que interactúan máquina a máquina los cuales pueden acceder al back-end de la organización. Los Web Services son una aplicación de software y por lo tanto pueden tener debilidades en su diseño, en su etapa de desarrollo y de pruebas. En general, el diseño y desarrollo de toda aplicación de software considera un comportamiento esperado de un usuario y un flujo de datos de entrada y salida, pero no se lleva a cabo un adecuado control de comportamientos inesperados de un usuario. La interacción de un usuario con las aplicaciones Web es estática, en cambio la interacción entre máquinas en Web Services es dinámica.

VULNERABILIDADES Y ATAQUES. De acuerdo a las debilidades anteriormente expuestas aparecen una serie de vulnerabilidades que afectan a los tres pilares de la seguridad de la Información: Confidencialidad, Integridad y Disponibilidad. Las vulnerabilidades actualmente reconocidas en Web Services son similares a las identificadas en las Aplicaciones Web, pero con la diferencia que todo el tráfico de datos se realiza utilizando estándares basados en el lenguaje XML. Las vulnerabilidades de los Web Services se pueden clasificar de la siguiente forma: I. II.

Vulnerabilidades estructurales Vulnerabilidades semánticas

I. Vulnerabilidades estructurales Las vulnerabilidades estructurales son aquellas que pueden ser atacadas interviniendo las líneas de comunicación de los participantes (consumidor, intermediarios, servidor) que intercambian mensajes SOAP. En esta clasificación podemos identificar las siguientes vulnerabilidades:

1. Interceptación de mensajes. El envío de mensajes por medio del protocolo HTTP permite a un atacante interceptar y leer los mensajes SOAP dando lugar a otros posibles ataques: • Alteración de mensajes: La información del mensaje es alterada al modificar, remover o reemplazar información del encabezado o del cuerpo5 del mensaje. • Confidencialidad: La información del mensaje es leída por un agente no autorizado. • Mensajes Falsificados: Se construyen mensajes falsos a partir de la copia de algunos o todos los mensajes interceptados para iniciar una nueva comunicación con el servidor. • Spoofing6 del servidor: Es una variación del anterior en el cual se impersona al servidor. • Seguridad forzada: Las sentencias de seguridad de un mensaje son forzadas para obtener información no autorizada. • Repetición de partes de mensajes: Se envían mensajes con porciones de otros mensajes para ganar acceso a información no autorizada o para causar que el receptor efectúe alguna acción.

2. Man-in-the-middle Los mensajes SOAP pueden ser transportados por intermediarios los cuales pueden ser comprometidos por un atacante para engañar al consumidor y al proveedor enviándoles mensajes impersonando a ambos, aun cuando se utilice encriptación ya que el atacante puede ser capaz de obtener la clave de sesión. 3. Spoofing Un atacante puede impersonal a uno o varios participantes confiables (autenticados) de la comunicación de mensajes SOAP para obtener información no autorizada o causar que una de las partes ejecute una acción no autorizada. 4. Repetición de mensajes Los mensajes SOAP son interceptados por un atacante y luego repetidos hacia el destino. Este ataque se utiliza para reunir información confidencial para eventuales ataques futuros o transacciones fraudulentas. 5. Denegación de Servicio Un atacante puede interceptar un mensaje, eventualmente modificar el encabezado y el cuerpo (rutas y/o sentencias XML) y enviarlo repetidamente para sobrecargar el servicio del intermediario o del destino final con lo cual logra que el servidor o el intermediario no pueda atender a un consumidor legítimo. II. Vulnerabilidades semánticas Las vulnerabilidades semánticas son aquellas que son atacadas por debilidades en la codificación y procesamiento de los mensajes SOAP. Los Web Services están basados en el lenguaje XML el cual entrega un alto nivel de detalle para realizar la descripción del servicio (utilizando WSDL), su publicación (en el registro UDDI) y ejecución (por medio de mensajes SOAP). Este nivel de detalle conlleva una etapa de procesamiento de las sentencias con un alto consumo de recursos computacionales (CPU, Memoria y Red) por parte de los participantes de la comunicación (consumidor, intermediarios, proveedor). Las vulnerabilidades más comunes dentro de esta clasificación son las siguientes:

1. Entradas inválidas Los parámetros enviados al servidor en un mensaje SOAP no son debidamente validados por el Web Service con lo cual un atacante puede enviar mensajes con código malicioso tanto en el encabezado como en el cuerpo del mensaje para ejecutar una acción no autorizada. 2. Control de acceso débil

El control de acceso para los consumidores de un servicio no tiene las restricciones adecuadas para evitar que un atacante acceda al servicio con permisos de consumidores válidos para obtener información y realizar acciones autorizadas. 3. Autenticación y manejo de sesión débiles Una política débil de contraseñas del proveedor de un Web Service puede permitir que un atacante descubra las contraseñas por medio de ataques de diccionario y de fuerza bruta. Lo anterior también se cumple para claves de sesión cuya encriptación no es el mejor debido a debilidades del algoritmo de encriptación o por el largo de las claves. Esta vulnerabilidad permitiría a un atacante utilizar la identidad de consumidores autorizados para obtener información o efectuar alguna acción autorizada por el servicio. 4. Cross Site Scripting Esta vulnerabilidad también se conoce como XML Encapsulation y se basa en un débil control de los elementos XML de un mensaje SOAP. El lenguaje XML puede permitir a un atacante embeber código malicioso dentro de los elementos de un mensaje SOAP para ganar acceso no autorizado en el servicio, obtener información de sesiones de consumidores que acceden el servicio, o para engañar a otros consumidores. 5. Buffer Overflows El diseño y desarrollo de un Web Service debe considerar el manejo de entradas en los elementos del código XML con un largo máximo de caracteres, de lo contrario permitiría a un atacante enviar mensajes al servicio con un largo inesperado provocando que el servicio sea comprometido debido a una falla o accediendo a información o procesos de sistema. 6. Injection Flaws Dado que un atacante puede embeber código malicioso en los mensajes SOAP, es posible enviar mensajes con fragmentos de sentencias SQL utilizando caracteres especiales u otros comandos de sistema para obtener información no autorizada del servicio. El atacante debe tener un conocimiento previo de cuál es la tecnología detrás del Web Service para embeber (o inyectar) las sentencias y comandos necesarios para efectuar el ataque. 7. Manejo inapropiado de errores Un manejo inapropiado de las condiciones de error mientras el Web Service está operando normalmente puede entregar información valiosa del sistema a un atacante que envía mensajes inválidos ya que puede utilizarla para inferir más

información para un posterior ataque que pueda causar la falla del servicio u obtener más información por medio de inyección de código. Esta vulnerabilidad va asociada a un débil diseño, desarrollo y pruebas del Web Service. 8. Contenido Malicioso Un Web Service que necesita intercambiar datos binarios (imágenes, audio, video, archivos ejecutables) utiliza mensajes SOAP con archivos adjuntos. Estos archivos deben ser enviados como parámetro de un elemento XML del mensaje y para ello se codifican con Base 64 o MIME. Dada esta característica, un atacante podría enviar virus o troyanos para causar alguna falla en el Web Service y el sistema subyacente. 9. Denegación de servicio Este tipo de vulnerabilidad es una de las más difíciles de mitigar debido a que las organizaciones no están preparadas para la variedad de amenazas existentes. Los ataques están asociados principalmente a un mal manejo de las entradas para un Web Service y a la débil configuración de los sistemas. Los ataques más comunes son: i. Envío de ráfagas de mensajes SOAP inválidos para que el servidor utilice toda su capacidad de procesamiento en condiciones de error y con ello no pueda atender ningún requerimiento de los demás consumidores, o incluso causar la falla del sistema. Este ataque aprovecha el débil manejo de las condiciones de error de un Web Service. ii. Envío de ráfagas de mensajes SOAP de gran tamaño provocando que el servidor quede totalmente ocupado o fuera de línea para atender a los consumidores. Este ataque aprovecha la vulnerabilidad de Buffer Overflow. iii. Envío de ráfagas de mensajes SOAP cuyo cuerpo (payload) es excesivamente grande para que un servidor los procese quedando fuera de línea. iv. External Entity: Los mensajes SOAP pueden referenciar entidades externas para entradas XML que son procesadas (interpretadas) por el proveedor del servicio. Si una de estas entidades está comprometida por un atacante, puede causar que el Web Service abra archivos arbitrarios y/o conexiones TCP provocando una denegación del servicio. v. Schema Poisoning: Un esquema XML describe instrucciones pre-procesadas para la interpretación de un documento XML. Un atacante podría comprometer (alterar) un esquema para que en el momento de la interpretación de los elementos XML del mensaje SOAP provoque un alto uso de recursos computacionales en el servidor. Por otra parte, el atacante podría alterar el esquema para obtener información y ejecutar acciones no autorizadas.

vi. Envío de ráfagas de mensajes SOAP con archivos adjuntos de gran tamaño para provocar una falla en el servidor para que no responda a los requerimientos de otros consumidores. vii. Envío de mensajes SOAP con archivos adjuntos de código malicioso (virus, troyanos, macros) para causar una falla en el servicio y/o en el sistema del proveedor.

10. Configuración Insegura La seguridad de la plataforma sobre la cual funcionan los Web Services de una organización es primordial. Un atacante podría afectar las instalaciones y sistemas de la organización si no se mantiene un fuerte control de acceso de las aplicaciones y Web Services al back-end utilizando un ataque o una combinación de los ataques antes enumerados. Según Gartner Group los Web Services reabrirán el 70% de los caminos de ataque cerrados por los Firewalls de red.

DESAFIOS A LA SEGURIDAD DE LOS WEB SERVICES. En la actualidad existen recomendaciones para abordar la seguridad de los Web Services a través de marcos de trabajo definidos por OASIS a cual es una organización para la estandarización de Web Services con la cooperación de las empresas tecnológicas más grandes del mundo. OASIS define WS-Security (Web Services Security) para tratar las siguientes consideraciones: •

Las relaciones de confianza entre las organizaciones podrían necesitar la definición de contratos legales y responsabilidades. • Los requerimientos a un Web Service deberían ser autenticados y autorizados apropiadamente. • Los mensajes hacia y desde un Web Service deberían ser protegidos de accesos y modificación no autorizados. WS-I (Web Services Interoperability Organization) es una organización apoyada por las empresas tecnológicas más grandes del mundo, y que define cómo se deberían cumplir los requerimientos de interoperabilidad al utilizar un conjunto de tecnologías que aseguran la transmisión de los mensajes SOAP. Según la WS-I los desafíos de seguridad en la transmisión mensajes SOAP son los siguientes: • • • •

Identificación y Autenticación de las partes. Identificación y Autenticación de los datos de origen. Integridad de los datos: Integridad en el transporte y del mensaje SOAP. Confidencialidad de los datos: Confidencialidad en el transporte y del mensaje SOAP. • Unicidad del mensaje SOAP. Los estándares que permiten abordar estos desafíos son los siguientes: • • • • • • •

WS-Security (Web Services Security), provee un marco de trabajo para el transporte seguro de mensajes SOAP. WS-Trust, describe un modelo conceptual de confianza que permite que los Web Services interoperen en forma segura. WS-Policy, describe un marco de trabajo para definir permisos y restricciones de las políticas de seguridad entre los participantes de la transmisión de los mensajes SOAP. WS-SecureConversation, define un marco de trabajo para manejar y autenticar el intercambio de mensajes SOAP incluyendo su contexto de seguridad. WS-Federation, define cómo establecer relaciones de confianza entre dominios de seguridad. WS-Privacy, describe la sintaxis y semántica para la comunicación privada de políticas de seguridad para Web Services e instancias de datos en mensajes. WS-Authorization, describe cómo las políticas de acceso para un Web Service son especificadas y gestionadas.

• • • • •

SAML (Security Assertion Markup Language), provee un marco de trabajo para intercambiar información en forma segura. XACML (eXtensible Access Control Markup Language), es un lenguaje para escribir políticas de control de acceso. XKMS (XML Key Management Specification), es un mecanismo basado en XML para la gestión de una Infraestructura de Clave Pública (PKI). XML Encryption, es un mecanismo para encriptar partes de un documento XML. XML Signature, es un mecanismo para firmar partes de un documento XML.

PREVENCION Y MITIGACION. Los Web Services han ampliado el campo de acción de los usuarios maliciosos para cometer sus delitos. Una buena política de seguridad de la información en las organizaciones es un buen punto de partida para disminuir el riesgo al cual están expuestos. Existe una variedad de amenazas y cada una de ellas con un alto impacto en la seguridad de la información de una organización, y es aún mayor si su modelo de negocios se basa principalmente en Internet. Es por ello que es necesario definir nuevos modelos de evaluación del riesgo de la seguridad de la información para aquellas organizaciones que están inmersas en una arquitectura orientada a los servicios (SOA, Service Oriented Architecture). Estos modelos deben considerar lo siguiente: •

La política de seguridad de la Información de la organización y su aplicabilidad. • La evaluación de riesgo de la organización antes de implementar Web Services. • Las medidas de mitigación existentes antes de implementar Web Services. • Indicadores del riesgo basados en la interacción con sus clientes y con las otras organizaciones. A partir de la evaluación basada en estos modelos se puede tener claridad para saber en qué áreas poner mayor énfasis y definir un camino para iniciar un plan de seguridad de la información cuyo objetivo final será el nivel de seguridad deseado por la organización. Este camino es largo, de mejora continua, pero flexible y con hitos específicos a corto y mediano plazo. Los hitos que se pueden definir a mediano plazo se refieren a metas específicas para la seguridad de los Web Services, entre ellos: • •

Aumentar la seguridad de la plataforma tecnológica de la organización. Mitigar las vulnerabilidades descubiertas en los Web Services existentes en producción y en desarrollo. • Utilizar las mejores prácticas para las etapas de diseño, desarrollo y prueba de los Web Services. Si la organización utiliza outsourcing de esta área, debe verificar que quien le presta el servicio cumpla con estos requisitos. Un modelo de desarrollo seguro de software es el definido por SSE-CMM [5]. • Definir controles para la operación y mantenimiento de los Web Services. • Definir un plan de recuperación ante desastres. • Definir un plan de continuidad del negocio. Los hitos definidos a corto plazo son metas específicas derivadas de la evaluación para cumplir con las medidas de mediano plazo. Algunos ejemplos son: •

Mitigar las vulnerabilidades de la red.

• •

Aumentar los controles de acceso al back-end. Definir controles de autenticación y autorización para los consumidores de un servicio. • Utilizar comunicación segura para el intercambio de mensajes SOAP. • Definir un sistema de control de cambios para el desarrollo de los Web Services. Dado que este modelo de prevención y mitigación involucra a toda la organización, un cambio en sus procesos y en la mentalidad organizacional, la puesta en marcha de este plan y el logro de las metas a corto plazo pueden retrasarse. Sin embargo, la organización puede tomar medidas preventivas y de mitigación a priori que deben estar asesoradas por especialistas de la seguridad de la información con el objetivo que estas medidas apunten a establecer un paso previo a la puesta en marcha de un modelo de prevención y mitigación. Por ejemplo, una organización puede tomar las siguientes medidas: •

Utilizar un Firewall para la capa de Aplicaciones que sea capaz de analizar el tráfico HTML para las aplicaciones Web, y XML para los Web Services. • Validar el uso de los esquemas XML en los Web Services. • Monitorear los eventos registrados por el Firewall de Aplicaciones y obtener estadísticas para la definición de métricas que sirvan para establecer medidas de riesgo. • Establecer políticas de comunicación comunes con las organizaciones que utilicen sus Web Services. Las medidas anteriores disminuyen el riesgo al cual está expuesta la organización en un mediano plazo y de ninguna forma constituyen medidas suficientes para quedar protegidos de todas las amenazas existentes y de las aún no conocidas.

PRACTICAS EN CLASE. Uno.php <html> <head> <html> <body> <form action="dos.php" method="post"> Introduzca su Nombre: <input type="text" name="cadena" size="20"><br><br> Edad: <input type="text" name="edad"><br><br> Sexo: <input type="radio" name="sexo" value="M" checked=>Mujer <input type="radio" name="sexo" value="H">Hombre <input type="submit" value="aceptar"> </form> </body> </html> Variable_variables.php <html> <head> <title>Variables variables en Php</title> </head> <body> <?Php print ("<p>Hola Mundo</p>"); $a = "hola"; $$a = "Mundo"; print "$a $hola\n"; print "$a ${$a}"; ?> </body> </html> Tablasyfunciones.php <html> <head> <title>Funcion Fecha</title> <?php function nombreMes ($mes) { $meses = array("enero","febrero","marzo","abril","mayo", "junio","julio","agosto","septiembre", "octubre","noviembre","diciembre"); $i=0; $enc=false; while ($i<12 and !$enc)

{ if($i==$mes-1) $enc=true; else $i++; } return($meses[$i]); } ?> </head> <body> <h1>Tablas Funciones</h1> <?php $dia=date("j"); $mes=date("n"); $anyo=date("Y"); print(" Hoy es " . $dia . " de " . nombreMes($mes) . " de " . $anyo . "<br>\n"); ?> </body> </html> Tablademultiplicar.php <html> <head> <title>Tabla de Multiplicar</title> </head> <body> <?php print("<ul>\n"); $i=1; $a=2; $b=2; while ( $i <= 10 and $b <= 10) { $a = $b * $i; print("<li> $b * $i = $a</li>\n"); $i++; } print("</ul>\n"); ?> </body> </html> Struc_while.php <html> <head> <title>Estructura While</title>

</head> <body> <?Php

print("<ul>\n"); $i=1; while ( $i <= 5) { print("<li>Elemento $i</li>\n"); $i++; } print("</ul>\n"); ?> </body> </html> Sintaxis Basica.php <HTML> <HEAD> <TITLE>Mi primer programa en PHP</TITLE> </HEAD> <BODY> <?PHP print ("<p>Hola mundo</p>"); ?> </BODY> </HTML> Practica2_1.php <html lang="es"> <head> <title>Prรกctica 2</title> </head> <body> <?PHP print ("<h1>Prรกctica 2</h1>\n"); print ("<p>Este cรณdigo HTML ha sido generado mediante\n"); print ("instrucciones escritas en lenguaje PHP.</p>\n"); print("<hr>\n\n"); require ("ej.php"); include ("Ejemplo1.html"); $valor = 5; print ("<p>El valor es:" . $valor . "</p>\n"); print ("<p>El valor es: $valor</p>\n"); //ojo: comillas dobles ?>

</body> </html> Practica2.php <htmllang="es"> <head> <title>Practica 2</title> </head> <body> <?PHP print ("<h1>Pr谩ctica 2</h1>\n"); print ("<p>Este c贸digo HTML ha sido generado mediante\n"); print (" instrucciones escritas en lenguaje PHP.</p>\n"); print ("<hr>\n\n"); ?> </body> </html> Paginter.php <html> <head> <title>Variables variables en Php</title> </head> <body> <?Php $mensaje_es="Hola"; $mensaje_en="Hello"; $idioma = "es"; $mensaje="mensaje_" . $idioma; print $$mensaje; define("cons1", " Papishulo"); print cons1; ?> </body> </html> Index.php <?php if (!empty($_SERVER['HTTPS']) && ('on' == $_SERVER['HTTPS'])) { $uri = 'https://'; } else { $uri = 'http://'; } $uri .= $_SERVER['HTTP_HOST']; header('Location: '.$uri.'/xampp/'); exit; ?>

Something is wrong with the XAMPP installation :-( Funcionfecha.php <html> <head> <title>Funcion Fecha</title> </head> <body> <?php $fecha = date("j/n/Y H:i"); print("$fecha"); $fecha1 = date ("j/n/Y", strtotime(" 5 april 2001")); print("$fecha1"); ?> </body> </html Funciones.php <html> <head> <title>Suma</title> </head> <body> <h1>Suma</h1> <?php function suma ($x, $y) { $s = $x + $y; return $s; } $a=1; $b=2; $c=suma ($a, $b); print ("es: $c"); ?> </body> </html> funcion3.php <html> <head> <title>A Quien Corresponda:</title> </head> <body> <?php function muestranombre ($nombre, $titulo = "Sr.") {

print("Estimado $titulo $nombre:<br>\n"); } muestranombre ("Fernandez"); muestranombre ("Fernandez", "Prof."); ?> </body> </html funcion2.php <html> <head> <title>A Quien Corresponda:</title> </head> <body> <h1>A Quien Corresponda:</h1> <?php function muestranombre ($titulo = "Sr.") { print("Estimado $titulo:<br>\n"); } muestranombre (); muestranombre ("Prof."); ?> </body> </html> Formtext.php <html> <body> Introduzca la cadena a buscar: <input type="text" name="cadena" value="valor por defecto" size="20"> <?php $cadena = $_REQUEST['cadena']; print($cadena); ?> </body> </html> Estructurasw.php <html> <head> <title>Variables variables en Php</title> </head> <body> <?Php

$extension = "HTML"; switch ($extension) { case ("PDF"): $tipo = "Documento Adobe PDF"; break; case ("TXT"): $tipo = "Documento de texto"; break; case ("HTML"): case ("HTM"): $tipo = "Documento HTML"; break; default: $tipo = "Archivo" . $extension; } print($tipo); ?> </body> </html> Estructura_if.php <html> <head> <title>Variables variables en Php</title> </head> <body> <?Php $nombre = "Papishulo"; $sexo = "M"; if ($sexo == 'F') $saludo ="Bienvenida, "; else $saludo ="Bienvenido, "; $saludo = $saludo . $nombre; print($saludo); ?> </body> </html> Struc_for.php <html> <head> <title>Estructura For</title> </head> <body> <?Php

print("<ul>\n"); for ($i=1; $i<=5; $i++) print("<li>Elemento $i</li>\n"); print("</ul>\n"); ?> </body> </html> Ejm_array_foreach.php <htmllang="es"> <head> <title>Arreglos</title> </head> <body> <h1>Manejo de arreglos</h1> <?php $color= array( 'rojo', 'azul', 'negro'); $medidas=array( 10, 25, 15); foreach ($medidas as $medida) { print $medida; } print $medida[1]; foreach ($color as $colores) { print("$colores<br>\n"); } print $color[2]; ?> </body> </html> Ejm_array.php <htmllang="es"> <head> <title>Arreglos</title> </head> <body> <h1>Manejo de arreglos</h1> <?php $color= array( 'rojo', 'azul', 'negro'); $medidas=array( 10, 25, 15); print $medidas[1]; print $color[2]; ?> </body>

</html Ejercicio1-resultados.php <html lang="es"> <head> <title>Formulario Simple. Resultado del formulario</title> <link rel="stylesheet" type="text/css" href="estilo.css"> </head> <body> <H1>Formulario Simple. Resultados del formulario</H1> <p>Estos son los datos introducidos: </p> <?php $texto = $_REQUEST['texto']; $donde = $_REQUEST['donde']; $genero = $_REQUEST['genero']; print("<ul>\n"); print(" <li>Texto de busqueda: $texto\n"); print(" <li>Buscar en: $donde\n"); print(" <li>Genero: $genero\n"); print("</ul>\n"); ?> [ <a href='ejercicio1.php'>Nueva busqueda</a>] </body> </html> Ejercicio1.php <html lang="es"> <head> <title>Formulario Simple</title> <link rel="stylesheet" type="text/css" href="estilo.css"> </head> <body> <H1>Formulario Simple</H1> <H2>Busqueda de Canciones</H2> <form class ="borde" action="ejercicio1-resultados.php" method="post">

<P><label>Texto a buscar:</label> <input type="text" size="40" name="texto"></P> <P><label>Buscar en: </label> <input type="RADIO" name="donde" value="titulo">Titulos de canci贸n <input type="RADIO" name="donde" value="album">Nombres de album <input type="RADIO" name="donde" value="ambos" checked>Ambos campos</P> <P><label>Genero musical:</label> <select name="genero"> <option selected>Todos <option>Ac煤stica <option>Banda Sonora <option>Blues <option>Electr贸nica <option>Folk <option>Jazz <option>New Age <option>Pop <option>Rock </select></P> <P><input type="submit" name="buscar" value="Buscar"></P> </form> </body> </html> Dos.php <html> <body> <?php $cadena = $_REQUEST['cadena']; print(" Nombre :$cadena<br>\n"); $laedad = $_REQUEST['edad']; print (" La edad es: $laedad <br>\n"); $sexo = $_REQUEST['sexo']; print(" Sexo : $sexo<br>\n"); ?> </body> </html>

TRABAJOS DE INVESTIGACION. PUERTO FTP. (PUERTO 23) FTP (File Transfer Protocol) es un protocolo de transferencia de archivos entre sistemas conectados a una red TCP basado en la arquitectura cliente-servidor, de manera que desde un equipo cliente nos podemos conectar a un servidor para descargar archivos desde él o para enviarle nuestros propios archivos independientemente del sistema operativo utilizado en cada equipo. El Servicio FTP es ofrecido por la capa de Aplicación del modelo de capas de red TCP/IP al usuario, utilizando normalmente el puerto de red 20 y el 21. Un problema básico de FTP es que está pensado para ofrecer la máxima velocidad en la conexión, pero no la máxima seguridad, ya que todo el intercambio de información, desde el login y password del usuario en el servidor hasta la transferencia de cualquier archivo, se realiza en texto plano sin ningún tipo de cifrado, con lo que un posible atacante lo tiene muy fácil para capturar este tráfico, acceder al servidor, o apropiarse de los archivos transferidos. Para solucionar este problema son de gran utilidad aplicaciones como scp y sftp, incluidas en el paquete SSH, que permiten transferir archivos pero cifrando todo el tráfico. ¿QUÉ SON LOS WEB SERVICES? El término Web Services describe una forma estandarizada de integrar aplicaciones WEB mediante el uso de XML, SOAP, WSDL y UDDI sobre los protocolos de la Internet. XML es usado para describir los datos, SOAP se ocupa para la transferencia de los datos, WSDL se emplea para describir los servicios disponibles y UDDI se ocupa para conocer cuáles son los servicios disponibles. Uno de los usos principales es permitir la comunicación entre las empresas y entre las empresas y sus clientes. Los Web Services permiten a las organizaciones intercambiar datos sin necesidad de conocer los detalles de sus respectivos Sistemas de Información.

A diferencia de los modelos Cliente/Servidor, tales como un servidor de páginas Web, los Web Services no proveen al usuario una interfaz gráfica (GUI). En vez de ello, los Web Services comparten la lógica del negocio, los datos y los procesos, por medio de una interfaz de programas a través de la red. Es decir conectan programas, por tanto son programas que no interactúan directamente con los usuarios. Los desarrolladores pueden por consiguiente agregar a los Web Services la interfaz para usuarios, por ejemplo mediante una página Web o un

programa ejecutable, tal de entregarle a los usuarios un funcionalidad específica que provee un determinado Web Service. Los Web Services permiten a distintas aplicaciones, de diferentes orígenes, comunicarse entre ellos sin necesidad de escribir programas costosos, esto porque la comunicación se hace con XML. Los Web Services no están ligados a ningún Sistema Operativo o Lenguaje de Programación. Por ejemplo, un programa escrito en Java puede conversar con otro escrito en Pearl; Aplicaciones Windows puede conversar con aplicaciones Unix. Por otra parte los Web Services no necesitan usar browsers (Explorer) ni el lenguaje de especificación HTML.

El modelo de computación distribuida de los Web Services permite la comunicación de aplicación a aplicación. Por ejemplo, la aplicación que procesa las órdenes de compra se puede comunicar con el sistema de inventarios, tal que este último le puede informar a la aplicación de compras cuales ítems deben comprarse por estar bajo su nivel mínimo. Dado el nivel integración que proveen para las aplicaciones, Los Web Services han crecido en popularidad y han comenzado a mejorar los procesos de negocios. De hecho, algunos postulan que los Web Services están generando la próxima evolución de la Web.

Tecnología Web Services. Los Web Services están construidos con varias tecnologías que trabajan conjuntamente con los estándares que están emergiendo para asegurar la seguridad y operatividad, de modo de hacer realidad que el uso combinado de varios Web Services, independiente de la o las empresas que los proveen, este garantizado. A continuación se describen brevemente los estándares que están ocupando los Web Services. XML Abreviación de Extensible Markup Language. El XML es una especificación desarrollada por W3C[1]. Permite a los desarrolladores crear sus propios tags[2], que les permiten habilitar definiciones, transmiciones, validaciones, e interpretación de los datos entre aplicaciones y entre organizaciones.

SOAP Abreviación de Simple Object Access Protocol , es un protocolo de mensajería construido en XML que se usa para codificar información de los requerimientos de los Web Services y para responder los mensajes “antes��? de enviarlos por la red. Los mensajes SOAP son independientes de los sistemas operativos y pueden ser transportados por los protocolos que funcionan en la Internet, como ser: SMTP, MIME y HTTP.

WSDL Abreviación de Web Services Description Language, es un lenguaje especificado en XML que se ocupa para definir los Web Service como colecciones de punto de comunicación capaces de intercambiar mensajes. El WSDL es parte integral de UDDI y parte del registro global de XML, en otras palabras es un estándar de uso público (no se requiere pagar licencias ni royalties para usarlo).

UDDI Abreviación de Universal Description, Discovery and Integration. Es un directorio distribuido que opera en la Web que permite a las empresas publicar sus Web Services, para que otras empresas conozcan y utilicen los Web Services que publican, opera de manera análoga a las páginas amarillas.

TIENDA VIRTUAL. Las tiendas virtuales son páginas webs, utilizadas para publicar productos y vender a través de la misma. De esta manera, los clientes pueden consultar, comparar y adquirir los productos de una manera mucho más rápida, y lo más importante es que pueden hacerlo desde cualquier parte del mundo, utilizando una computadora. ¿A quién le sirve tener una tienda virtual? A cualquier persona o empresa que tenga uno o varios productos y quiera extender sus fronteras, vendiendo sus productos en cualquier parte del mundo a través de la red.

Una tienda virtual permite tambiĂŠn brindarle a nuestros clientes una herramienta para conocer nuestros productos antes de visitarnos personalmente, en una tienda tradicional un cliente no siempre tiene a la vista todos nuestros productos, en cambio con un tienda virtual sĂ. Otro punto importante es que el cliente puede tomarse todo el tiempo que quiera en conocer y evaluar nuestros productos.

EXPOSICION EN CLASE.

CONCLUSION. Los Web Services permiten la comunicación entre plataformas heterogéneas por medio del protocolo HTTP(S) el cual es permitido por la mayoría de los Firewalls de red. Por otra parte, para utilizar Web Services se debe publicar una descripción completa del servicio en un registro público. Estas dos características representan una brecha de seguridad que puede ser aprovechada por usuarios maliciosos para cometer ataques a una organización para obtener información confidencial para realizar operaciones fraudulentas, y para degradar el nivel de servicio. Para prevenir y mitigar el riesgo de estas amenazas se recomienda utilizar un modelo de prevención y mitigación, o tomar medidas preventivas a priori para implementarlas en un corto plazo. La tendencia mundial en el uso de Web Services es creciente y los desafíos inherentes a la seguridad de la información son cada vez mayores. Sin embargo, existen tecnologías y estándares para abordar estos desafíos, la dificultad está en llevarlos a la práctica de la mejor forma.

BIBLIOGRAFIA. TIPO

TITULO

AUTOR

EDITORIAL/REVISTA

Libro

Java 2 Manual de Programaciﾃｳn

Libro

Schafer, Steven Wrox Web Standards M. Programmer's Reference: HTML, CSS, JavaScript, Perl, Python, and PHP Anaya Multimedia Perl, CGI y Java Script Anaya Multimedia

Libro

Joyanes Aguilar, McGraw-Hill Luis

Aﾃ前

2001 2005

2001

Libro

Java and XML

McLaughlin, Brett y Loukides, Mike

O'Reilly

2000

Libro

Perl, CGI, and JavaScript Complete

Sybex Inc

2000

Libro

JavaScript: A Beginner's Pollock, John Guide

McGraw-Hill Osborne Media

2003