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

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

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 WebService es un sistema de software interoperable diseñado para dar apoyo a lainteracción máquina a máquina sobre una red”. Esta interacción se realiza pormedio de mensajes SOAP (Simple Object Access Protocol) transportados a travésdel protocolo HTTP mediante una serialización XML en conjunto con otrosestándares Web. Un Web Service es descrito utilizando el estándar WSDL (WebService Description Language) y almacenado en un repositorio UDDI (UniversalDescription and Discovery Interface). La Figura 1 muestra el esquema de relaciónde 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 dosentes, un consumidor y un proveedor del servicio. El proveedor pone a disposiciónun servicio describiéndolo por medio del estándar WSDL y almacenando sudescripción en un registro UDDI. El consumidor consulta el registro UDDIbuscando el servicio que desea obteniendo la descripción WSDL con el cualpuede construir los mensajes SOAP apropiados enviándolos a través de unaconexión HTTP(S) 1 para comunicarse con el servicio. El estándar WSDL proveemúltiples formas para interactuar con un servicio, por ejemplo, un mismo serviciopodría ser descrito para estar disponible por medio de mensajes SOAP enviados através de HTTP(S) en un servidor y por medio de mensajes RMI/IIOP enviados através de TCP/IP a otro servidor. Sin perjuicio de lo anterior, en la Figura 1 sedescribe el caso en el cual se utilizan mensajes SOAP enviados por medio deHTTP(S) ya que representa un modo de acceso abierto y ubicuo a un servicio através de Internet, y es en éste escenario en donde la seguridad de los WebServices se ve disminuida.

Figura 1: Relación entre WSDL, UDDI ySOAP 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 delCurso:

El alumno Adquirirá las habilidades para integrar los servicios de Web a laoperación de una tienda virtual, elaborando una tienda virtual que le permitacomercializar productos de manera electrónica, utilizando la Arquitecturaorientada a servicios.

Bibliografía:TIPO TITULO AUTOR EDITORIAL/REVISTA AÑO

.

Libro Java 2 Manual deProgramación

JoyanesAguilar, Luis

McGraw-Hill 2001

Libro Web StandardsProgrammer'sReference: HTML,CSS, JavaScript,Perl, Python, andPHP

Schafer,Steven M.

Wrox 2005

Libro Perl, CGI y JavaScript

AnayaMultimedia

Anaya Multimedia 2001

Libro Java and XML McLaughlin,Brett yLoukides,Mike

O'Reilly 2000

Libro Perl, CGI, andJavaScriptComplete

Sybex Inc Sybex Inc 2000

Libro JavaScript: ABeginner's Guide

Pollock,John

McGraw-HillOsborne Media

2003

criterios parala Evaluación

CALIFICACIÓN ORDINARIA (PONDERACIÓN)

Actividadessemanales

30% Examen primer parcial. 15%

Portafolioreaprendizaje

10%Examen segundo

parcial.25%

Trabajosindependientes

20% T O T A L100%

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) decalificació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, suscalificaciones, 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 detrabajos finales y la aplicación de exámenes en la última semana del módulo.

Calendarización

Sesión Fecha Tema

1 17/02/2014

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 losalumnos.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 services1.3. Importancia para los negocios de la utilización de estos servicios.

Instalación de ApacheInstalación de PHPInstalación de una distribución de Apache: XAMPP

2 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 aobjetos

Ejercicios prácticos #1, #2 y #3Introducción a PHP

3 19/02/2014Entornos de desarrollo para PHPRecursos de PHP

4 20/02/2014

1.6. Definición de tienda virtual.

1.7. Que productos pueden ofrecerse de manera electrónica.

Exposición Artículo 1: Conoce qué es el comercio electrónico y cómo sacarlepartido para tu negocio.

Artículo 2: Emprender tu propia tienda online es todo un reto que puedes sortearatendiendo a las siguientes siete recomendaciones de nuestros expertos enInternet.

5 24/02/2014

2. Programación interpretada (scripting)

2.1. Validación de datos

2.2. Mensajes y confirmaciones

6 25/02/2014

2. Eficiencia de los servicios web2.1. Reducción de costo y aumento de eficiencia.3. Sintaxis básica PHPTipos de datosVariablesConstantes

7 26/02/2014

Expresiones y operadoresEstructuras de controlFuncionesTablasBibliotecas de funciones

8 27/02/2014

2.2. Tecnologías base de los servicios web.Acceso a formularios HTML desde PHPEl formulario de PHPExposició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 conesta estrategia de comercio electrónico.

9 03/03/2014

3. Seguridad de los servicios Web3.1. Uso de estándar para reducción de riesgosProgramación en PHPSubida de ficheros al servidorValidación de los datos de un formularioEjercicios Prácticos

10 04/03/20143.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.

11 05/03/2014

Bases de datos en la WebInstalación y configuración de MySQLMySQL

Herramientas de administración: phpMyAdmin

Lenguaje SQL

Funciones de PHP para el acceso a bases de datos MySQL

Ejercicios

Consulta avanzada de tablas12 06/03/2014 EXAMEN PRIMER PARCIAL

13 10/03/2014

4. Implementación de los servicios web

4.1. Estándares de mercado

14 11/03/2014Manejo de sesionesAutenticación de usuariosEjercicios prácticos

15 12/03/20144.2. Estrategias de las distintas compañíasEjercicios prácticosAnálisis y reflexión de los temas por parte del alumno, dudas de clase.

16 13/03/2014

Ejercicios prácticosAnálisis y reflexión de los temas por parte del alumno, dudas de clase.4.3. Modelo de negocio para los servicios web

17 17/03/2014

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

Exposición tema: -Aumente las ventas de su tienda virtual.

1818/03/2014

Revisión final del portafolio y proyecto final

1919/03/2014

EXAMEN SEGUNDO PARCIAL

2020/03/2014

ENTREGA DE CALIFICACIONES ORDINARIAS

EXAMEN EXTRAORDINARIOS

INFORMACION INSTITUCIONAL.

Misión.

La misión de UNIDEP es formar profesionales de éxito que cuenten con lasactitudes, habilidades y conocimientos que demanda el sector productivo de laregión.

Visión.

La Universidad del Desarrollo Profesional es una institución de educación superiorde calidad, que ofrece programas presenciales y semis presenciales debachillerato, profesional asociado, licenciatura, posgrado, diplomados y cursos enMé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 deestudio pertinentes y dinámicos.

Es reconocida por su modelo educativo profesionalizan te, por la flexibilidad de suoferta 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. Susinstalaciones dentro de la ciudad permiten el fácil acceso.

Cuenta con un modelo de administración sistematizado, participativo, operado porpersonal que es recompensado por su desempeño efectivo que le permitemaximizar las aportaciones de sus socios y mantener finanzas sanas.

VALORES UNIDEP:

Lealtad: Los integrantes de la comunidad universitaria consideramos la fidelidadcomo un valor excelso que enaltecemos en nuestro quehacer diario.Justicia: Los integrantes de la comunidad universitaria actuamos con la constantey perpetua voluntad de dar a cada cual lo que le corresponde conforme a susméritos o actos.

Honestidad: Los integrantes de la comunidad universitaria actuamos consinceridad y honradez en nuestras tareas y en congruencia entre lospensamientos, palabras y acciones.

Responsabilidad: Los integrantes de la comunidad universitaria llevamos a cabonuestras actividades con integridad, con sentido del propósito y apegados a losobjetivos institucionales.

Esfuerzo: Los integrantes de la comunidad universitaria usamos nuestra máximaenergía para cumplir con los objetivos trazados.

Creatividad: Los integrantes de la comunidad universitaria resolvemos losproblemas 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 lossistemas informáticos de las organizaciones mediante tecnologías yprotocolos WEB estándar.

Cada Servicio Web se responsabilidad de realizar un conjunto de funcionesconcretas y bien definidas.

Servicios Web actúan como componentes independientes que se puedenintegrar 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 porun URI (Uniform Resource Identifier ), cuyas interfaces se pueden definir, describiry descubrir mediante documentos XML. Los Servicios Web hacen posible lainteracción entre ”agentes” software (aplicaciones) utilizando mensajes XMLintercambiados 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 paraintercambiar datos

•La interoperabilidad se consigue mediante el uso de estándares abiertos.• Servicios Web se asientan sobre protocolos y estándares ya existentes ymuy difundidos (HTTP, XML, etc)• Uso de protocolos específicos extensibles ⇒ no imponen restriccionessobre las aplicaciones a las que dan acceso ni sobre las tecnologías que lasimplementan (independencia de lenguaje y de plataforma)• OASIS y W3C: organizaciones responsables de definir la arquitectura yestá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 mecanismopara el transporte de los mensajes (invocación, respuesta, ...)◦ Mensajes intercambiados se encapsulan dentro de mensajes HTTP (oSMTP)◦ 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 distintasempresas/organizaciones

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

Serv. Web permiten superar esa restricción: no exigen middleware únicocomún, middleware abierto y no centralizado

Servicios Web ofrecen un punto de entrada a los sistemas de informaciónlocales• Encapsulan una o más aplicaciones ofreciendo un interfaz único accesiblepor la Web• Ofrecen un interfaz público y estable, independiente de su implementaciónconcreta• Facilitan la automatización de las interacciones entre los procesos internosde 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 ypública que puede ser invocado por un cliente

•Los Servicios Web amplían esa idea para permitir que esa invocación serealize a través de internet empleando protocolos Web estándar yaexistentes

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 invocadasen un orden determinado para lograr el objetivo deseado

◦Servicios simples vs. serv. compuestos (implementados invocando otrosservicios)◦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 lasinteraccionesentre servicios (normalmente Servicios Web)¦ Soporta la composición de servicios simples para crear servicioscompuestos

ARQUITECTURA BASICA DE PROTOCOLOS DE SERVICIOS WEB.

Elementos necesarios para la definición de Servicios Web1. Sintaxis común para todas la especificaciones ⇒ uso de XML

XML: eXtensible Markup Language• Estándar para la definición de lenguajes de marcas• Flexible y extensibleMetalenguaje usado en Servicios Web para especificar los lenguajes yprotocolos necesarios• Permite definición de lenguajes para: describir servicios, representarmensajes intercambiados

2. Mecanismos de interacción entre extremos ⇒uso de SOAP (Simple ObjectAccess 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

Especificación del modo de interacción: síncrono (RPC: petición-respuesta), 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 ServiceDescription Language)

Descripción de los servicios y sus interfaces de forma estándarmediante 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 desalida• Puede usarse para generar los stubs/skeleton y las capas intermediasnecesarias 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 (UniversalDescription, Discovery and Integration)

La descripción de los servicios (documentos WSDL) se almacena en undirectorio de servicios

UDDI especifica cómo: se publican y descubren los servicios, trabajan losdirectorios 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 ytipada usado XML para que sea intercambiada entre los extremos de lainvocación

Especificado por 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 dedocumentos 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 mensajesSOAP

• indica elementos a tratar u omitir, quien debe hacerlo y los tipos de acciones arealizar

Descripción del modo en que se envían los mensajes SOAP sobre el protocolo detransporte (HTTP o SMTP)

Características

SOAP define un intercambio de mensajes sin estado

• Posibilidad de soportar comunicaciones con estado añadiendo informaciónadicional (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 restricciones sobre la semántica de los mensajesintercambiados

• SOAP sólo ofrece la infraestructura para transferir esos mensajes• El significado 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 fiabilidad, integridad de los mensajes,transacciones, seguridad, etc

• La gestión de esos aspectos es responsabilidad de la infraestructura/aplicaciónque implementa el Servicio Web

Nota: La implementación de los Servicios Web es responsabilidad del extremoque 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 laredirigirá a la implementación del servicio Web

La implementación real del Servicio Web puede residir en un CGI (CommonGateway 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

• Define la estructura de un ”contenedor” de mensajes XML• No establece restricciones sobre el contenido del mensaje ni sobre elprocesamiento a realizar con el

◦ XML-RPC usaba etiquetas predefinidas (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 ServiciosWeb

◦ 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 deinterpretar 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 oimplementan el Servicio Web

◦ los extremos son los responsables de acordar el formato de la informaciónintercambiada y de generar y/o procesar su contenido

• Puede estructurarse en bloques

◦ Usualmente los bloques mapean una invocación o respuesta RPC en formatoXML

¦ Esquema usual: codificación de parámetros y valor de retorno¦ Suele hacerse uso de los tipos de datos definidos en la especificación XMLSchema¦ XML Schema permite representar en XML tipos simples (enteros, reales,...) tipocompuestos (estructuras, arrays,...) ◦ Bloque especial fault: usado para representarerrores 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 bloquesincluidos 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 paratransferir los mensajes

• SOAP sólo define un contenedor de ”mensajes” y la forma de encapsularlos en elprotocolo de transporte que se use

binging SOAP: descripción de cómo se envía un mensaje SOAP utilizando unprotocolo 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 mensajesSOAP

• Peticiones HTTP POST:se envía el mensaje SOAP en el cuerpo de la peticiónHTTP, 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 elcampo to: en bindings SMTP)

Ejemplo mensajes SOAP

Petición SOAP sobre un mensaje POST de HTTP POST

/WeatherForecast.asmx HTTP/1.1Host: www.webservicex.netContent-Type: text/xml; charset=utf-8Content-Length: 446SOAPAction: "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 HTTPHTTP/1.1 200 OKContent-Type: text/xml; charset=utf-8Content-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 independientede la plataforma

Definici´on de operaciones: nombre, argumentos (nombre + tipo), valor retornoDefinici´on 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´on 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 laespecificació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 yservidor)

Indica cómo interactuar con el servicio: operaciones definidas, datos a enviar ydevolver, formato mensajes + protocolo transferencia

Como entrada para compiladores/generadores de stubs y/o skeleton Lasaplicaciones no escriben ni procesan directamente los mensajes XML SOAP

A partir de la definición WSDL del Servicio Web se generan los elementosadicionales necesarios para que: servidor implemente el Servicio Web clienterealice la llamada al Servicio Web

• stubs y/ skeletons• Objetos y/o procedimientos para serializar los datos en el formato de losmensajes 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ónWSDL a partir de las implementaciones de los Servicios Webwsgen 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 intercambiarmensajes

• 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 ymensajes

elemento <types>: Define los tipos y estructuras de datos de los datosintercambiados

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óntypes)

elemento <portType>: Define grupos de operaciones (ports, puertos) Para cadaoperación (elemento <operation>) se le asigna un nombre y se especifica elintercambio 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 demensajes usada

elemento <bindings>: Asocia a un grupo de operaciones (portType) unaespecificación de la codificación de mensajes y el protocolo de transporte (atributotransport) a utilizar.

• Informa a los usuarios del Servicio Web (clientes o servidores) de los protocolosa usar, de cómo estructurar los mensajes XML y de lo que se espera recibir alenviar 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 elbinding contiene toda la información necesaria para construir y procesarautomá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 final (endpoint)[destino final de la comunicación]

◦ Asocia la información de los bindings (conjuntos de operaciones) a ladirecció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:operationsoapAction="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 proporcionaoperaciones (vía SOAP) para registrar y buscar (descubrir) Servicios Web

Cada servicio se registra dando su nombre, una descripción del servicio (URL desu WSDL, una descripci´on 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 construirclientes• Facilitar el enlace dinámico, permitiendo consultar referencias y acceder aservicios de interés en tiempo de ejecución (descubrir servicios e invocarlos ”alvuelo”)

Especificación: http://uddi.xml.org

Tipos de información ofrecida

Páginas blancas : Identificador y dirección de contacto de la empresa/organizaciónque publica el Servicio Web

Páginas amarillas : Descripciones de los Servicios Web ofrecidos usandodiferentes tipos de categorizaciones (taxonomías)

NAICS-North American Industry Classification System, UNSPSC-UniversalStandard Products and Services Classification, etc

Páginas verdes : Info. técnica sobre los servicios web (URL de descarga delWSDL)

DEBILIDAD DE LOS WEB SERVICES.

La debilidad principal de los Web Services está dada por el modelo de interacciónentre el consumidor y el proveedor del servicio. De la Figura 1 se puede observarlo siguiente: El proveedor debe describir el servicio utilizando el estándar WSDLdando los detalles de cómo comunicarse con él. Esta descripción da bastante ypreciada información a un consumidor malicioso para reunir antecedentesfácilmente al consultar el registro UDDI. Lo anterior da una ventaja al consumidormalicioso de Web Services por sobre un usuario malicioso de Aplicaciones Webya que para este último es menos fácil saber qué tipo de parámetros espera laaplicación y qué contenido devolverá al navegador (browser) para serdesplegadas al usuario. Por otra parte, podemos descubrir otras debilidades alrealizar un paralelo entre las Aplicaciones Web y Web Services ya que compartencaracterísticas similares: • Los Web Services pertenecen a la capa de Aplicacióndel modelo OSI al igual que las Aplicaciones Web. Las organizaciones se hanpreocupado de mitigar las vulnerabilidades de las capas inferiores utilizandoFirewalls, IDS, HIDS y Antivirus (Figura 2), pero han dejado desprotegida la capadonde residen las aplicaciones con las cuales realizan transacciones con susclientes y usuarios, en particular, los Web Services son una tecnología quepermite implementar una Arquitectura Orientada a los Servicios (SOA, ServiceOriented Architecture) con un énfasis en las transacciones entre empresas (B2B,Business to Business) donde no siempre es necesaria una relación previa. Estorepresenta un atractivo económico bastante mayor para un usuario malicioso yaque en las Aplicaciones Web generalmente se realizan transacciones conpersonas (B2C Business to Consumer y C2C Consumer to Consumer).

Los Web Services utilizan HTTP(S) para el envío de mensajes SOAP. Por logeneral para el protocolo HTTP(S) se utilizan los puertos de conexión estándares80 y 443 los cuales son permitidos en la mayoría de los Firewalls de Red de lamayoría de las organizaciones (Figura 3). Estos Firewalls no poseen la capacidadde analizar el tráfico HTTP(S) y menos aún las sentencias XML de los mensajesSOAP que circulan por este protocolo. Por otra parte, HTTPS provee seguridad enla comunicación mientras los mensajes son transportados, no cuando losmensajes son emitidos y/o recibidos por los participantes, además no permiteintermediarios y no provee norepudiación.

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

información, mientras que otra puede proveer servicios que realicentransacciones críticas para su negocio.

Los Web Services acceden al back-end de la organización. El diseño entres capas de las Aplicaciones Web (Capa de presentación, Capa deControl, 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 cualespueden acceder al back-end de la organización.

Los Web Services son una aplicación de software y por lo tanto puedentener debilidades en su diseño, en su etapa de desarrollo y de pruebas. Engeneral, el diseño y desarrollo de toda aplicación de software considera uncomportamiento esperado de un usuario y un flujo de datos de entrada ysalida, pero no se lleva a cabo un adecuado control de comportamientosinesperados de un usuario. La interacción de un usuario con lasaplicaciones Web es estática, en cambio la interacción entre máquinas enWeb Services es dinámica.

VULNERABILIDADES Y ATAQUES.

De acuerdo a las debilidades anteriormente expuestas aparecen una serie devulnerabilidades que afectan a los tres pilares de la seguridad de la Información:Confidencialidad, Integridad y Disponibilidad. Las vulnerabilidades actualmentereconocidas en Web Services son similares a las identificadas en las AplicacionesWeb, pero con la diferencia que todo el tráfico de datos se realiza utilizandoestándares basados en el lenguaje XML.

Las vulnerabilidades de los Web Services se pueden clasificar de la siguienteforma:

I. Vulnerabilidades estructuralesII. Vulnerabilidades semánticas

I. Vulnerabilidades estructurales

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

1. Interceptación de mensajes.

El envío de mensajes por medio del protocolo HTTP permite a un atacanteinterceptar 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 noautorizado.

• Mensajes Falsificados: Se construyen mensajes falsos a partir de la copia dealgunos o todos los mensajes interceptados para iniciar una nueva comunicacióncon el servidor.

• Spoofing6 del servidor: Es una variación del anterior en el cual se impersona alservidor.

• Seguridad forzada: Las sentencias de seguridad de un mensaje son forzadaspara obtener información no autorizada.

• Repetición de partes de mensajes: Se envían mensajes con porciones de otrosmensajes para ganar acceso a información no autorizada o para causar que elreceptor efectúe alguna acción.

2. Man-in-the-middle

Los mensajes SOAP pueden ser transportados por intermediarios los cualespueden ser comprometidos por un atacante para engañar al consumidor y alproveedor enviándoles mensajes impersonando a ambos, aun cuando se utiliceencriptació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ónno 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 eldestino. Este ataque se utiliza para reunir información confidencial para eventualesataques futuros o transacciones fraudulentas.

5. Denegación de Servicio

Un atacante puede interceptar un mensaje, eventualmente modificar elencabezado y el cuerpo (rutas y/o sentencias XML) y enviarlo repetidamente parasobrecargar el servicio del intermediario o del destino final con lo cual logra que elservidor 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 debilidadesen la codificación y procesamiento de los mensajes SOAP. Los Web Servicesestán basados en el lenguaje XML el cual entrega un alto nivel de detalle pararealizar la descripción del servicio (utilizando WSDL), su publicación (en el registroUDDI) y ejecución (por medio de mensajes SOAP). Este nivel de detalle conllevauna etapa de procesamiento de las sentencias con un alto consumo de recursoscomputacionales (CPU, Memoria y Red) por parte de los participantes de lacomunicación (consumidor, intermediarios, proveedor). Las vulnerabilidades máscomunes dentro de esta clasificación son las siguientes:

1. Entradas inválidas

Los parámetros enviados al servidor en un mensaje SOAP no son debidamentevalidados por el Web Service con lo cual un atacante puede enviar mensajes concódigo malicioso tanto en el encabezado como en el cuerpo del mensaje paraejecutar una acción no autorizada.

2. Control de acceso débil

El control de acceso para los consumidores de un servicio no tiene lasrestricciones adecuadas para evitar que un atacante acceda al servicio conpermisos de consumidores válidos para obtener información y realizar accionesautorizadas.

3. Autenticación y manejo de sesión débiles

Una política débil de contraseñas del proveedor de un Web Service puedepermitir que un atacante descubra las contraseñas por medio de ataques dediccionario y de fuerza bruta. Lo anterior también se cumple para claves de sesióncuya encriptación no es el mejor debido a debilidades del algoritmo deencriptación o por el largo de las claves.

Esta vulnerabilidad permitiría a un atacante utilizar la identidad de consumidoresautorizados para obtener información o efectuar alguna acción autorizada por elservicio.

4. Cross Site Scripting

Esta vulnerabilidad también se conoce como XML Encapsulation y se basa en undébil control de los elementos XML de un mensaje SOAP. El lenguaje XML puedepermitir a un atacante embeber código malicioso dentro de los elementos de unmensaje SOAP para ganar acceso no autorizado en el servicio, obtenerinformación de sesiones de consumidores que acceden el servicio, o para engañara otros consumidores.

5. Buffer Overflows

El diseño y desarrollo de un Web Service debe considerar el manejo de entradasen los elementos del código XML con un largo máximo de caracteres, de locontrario permitiría a un atacante enviar mensajes al servicio con un largoinesperado provocando que el servicio sea comprometido debido a una falla oaccediendo 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 utilizandocaracteres especiales u otros comandos de sistema para obtener información noautorizada del servicio. El atacante debe tener un conocimiento previo de cuál esla tecnología detrás del Web Service para embeber (o inyectar) las sentencias ycomandos 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 unatacante 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 uobtener más información por medio de inyección de código. Esta vulnerabilidad vaasociada 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. Estosarchivos deben ser enviados como parámetro de un elemento XML del mensaje ypara ello se codifican con Base 64 o MIME. Dada esta característica, un atacantepodría enviar virus o troyanos para causar alguna falla en el Web Service y elsistema subyacente.

9. Denegación de servicio

Este tipo de vulnerabilidad es una de las más difíciles de mitigar debido a que lasorganizaciones no están preparadas para la variedad de amenazas existentes.

Los ataques están asociados principalmente a un mal manejo de las entradas paraun Web Service y a la débil configuración de los sistemas. Los ataques máscomunes son:

i. Envío de ráfagas de mensajes SOAP inválidos para que el servidor utilice todasu capacidad de procesamiento en condiciones de error y con ello no puedaatender ningún requerimiento de los demás consumidores, o incluso causar la falladel sistema. Este ataque aprovecha el débil manejo de las condiciones de error deun Web Service.

ii. Envío de ráfagas de mensajes SOAP de gran tamaño provocando que elservidor quede totalmente ocupado o fuera de línea para atender a losconsumidores. Este ataque aprovecha la vulnerabilidad de Buffer Overflow.

iii. Envío de ráfagas de mensajes SOAP cuyo cuerpo (payload) es excesivamentegrande para que un servidor los procese quedando fuera de línea.

iv. External Entity: Los mensajes SOAP pueden referenciar entidades externaspara entradas XML que son procesadas (interpretadas) por el proveedor delservicio. Si una de estas entidades está comprometida por un atacante, puedecausar que el Web Service abra archivos arbitrarios y/o conexiones TCPprovocando una denegación del servicio.

v. Schema Poisoning: Un esquema XML describe instrucciones pre-procesadaspara 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 loselementos XML del mensaje SOAP provoque un alto uso de recursoscomputacionales en el servidor. Por otra parte, el atacante podría alterar elesquema para obtener información y ejecutar acciones no autorizadas.

vi. Envío de ráfagas de mensajes SOAP con archivos adjuntos de gran tamañopara provocar una falla en el servidor para que no responda a los requerimientosde 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 delproveedor.

10. Configuración Insegura

La seguridad de la plataforma sobre la cual funcionan los Web Services de unaorganización es primordial. Un atacante podría afectar las instalaciones y sistemasde la organización si no se mantiene un fuerte control de acceso de lasaplicaciones y Web Services al back-end utilizando un ataque o una combinaciónde los ataques antes enumerados. Según Gartner Group los Web Servicesreabrirá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 WebServices a través de marcos de trabajo definidos por OASIS a cual es unaorganización para la estandarización de Web Services con la cooperación de lasempresas tecnológicas más grandes del mundo. OASIS define WS-Security (WebServices Security) para tratar las siguientes consideraciones:

• Las relaciones de confianza entre las organizaciones podrían necesitar ladefinición de contratos legales y responsabilidades.

• Los requerimientos a un Web Service deberían ser autenticados yautorizados apropiadamente.

• Los mensajes hacia y desde un Web Service deberían ser protegidos deaccesos y modificación no autorizados.

WS-I (Web Services Interoperability Organization) es una organización apoyadapor las empresas tecnológicas más grandes del mundo, y que define cómo sedeberían cumplir los requerimientos de interoperabilidad al utilizar un conjunto detecnologías que aseguran la transmisión de los mensajes SOAP. Según la WS-Ilos 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 eltransporte seguro de mensajes SOAP.

• WS-Trust, describe un modelo conceptual de confianza que permite que losWeb Services interoperen en forma segura.

• WS-Policy, describe un marco de trabajo para definir permisos yrestricciones de las políticas de seguridad entre los participantes de latransmisión de los mensajes SOAP.

• WS-SecureConversation, define un marco de trabajo para manejar yautenticar el intercambio de mensajes SOAP incluyendo su contexto deseguridad.

• WS-Federation, define cómo establecer relaciones de confianza entredominios de seguridad.

• WS-Privacy, describe la sintaxis y semántica para la comunicación privadade políticas de seguridad para Web Services e instancias de datos enmensajes.

• WS-Authorization, describe cómo las políticas de acceso para un WebService son especificadas y gestionadas.

• SAML (Security Assertion Markup Language), provee un marco de trabajopara intercambiar información en forma segura.

• XACML (eXtensible Access Control Markup Language), es un lenguaje paraescribir políticas de control de acceso.

• XKMS (XML Key Management Specification), es un mecanismo basado enXML para la gestión de una Infraestructura de Clave Pública (PKI).

• XML Encryption, es un mecanismo para encriptar partes de un documentoXML.

• 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 maliciosospara cometer sus delitos. Una buena política de seguridad de la información en lasorganizaciones es un buen punto de partida para disminuir el riesgo al cual estánexpuestos.

Existe una variedad de amenazas y cada una de ellas con un alto impacto en laseguridad de la información de una organización, y es aún mayor si su modelo denegocios se basa principalmente en Internet. Es por ello que es necesario definirnuevos modelos de evaluación del riesgo de la seguridad de la información paraaquellas organizaciones que están inmersas en una arquitectura orientada a losservicios (SOA, Service Oriented Architecture). Estos modelos deben considerar losiguiente:

• La política de seguridad de la Información de la organización y suaplicabilidad.

• La evaluación de riesgo de la organización antes de implementar WebServices.

• 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 parasaber en qué áreas poner mayor énfasis y definir un camino para iniciar un plan deseguridad de la información cuyo objetivo final será el nivel de seguridad deseadopor la organización. Este camino es largo, de mejora continua, pero flexible y conhitos específicos a corto y mediano plazo. Los hitos que se pueden definir amediano plazo se refieren a metas específicas para la seguridad de los WebServices, 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ónpara 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 enmarcha de este plan y el logro de las metas a corto plazo pueden retrasarse. Sinembargo, la organización puede tomar medidas preventivas y de mitigación apriori que deben estar asesoradas por especialistas de la seguridad de lainformación con el objetivo que estas medidas apunten a establecer un pasoprevio a la puesta en marcha de un modelo de prevención y mitigación. Porejemplo, una organización puede tomar las siguientes medidas:

• Utilizar un Firewall para la capa de Aplicaciones que sea capaz de analizarel 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 establecermedidas de riesgo.

• Establecer políticas de comunicación comunes con las organizaciones queutilicen sus Web Services.

Las medidas anteriores disminuyen el riesgo al cual está expuesta la organizaciónen un mediano plazo y de ninguna forma constituyen medidas suficientes paraquedar 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>

<?Phpprint ("<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><?phpfunction 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 entresistemas conectados a una red TCP basado en la arquitectura cliente-servidor, demanera que desde un equipo cliente nos podemos conectar a un servidor paradescargar archivos desde él o para enviarle nuestros propios archivosindependientemente del sistema operativo utilizado en cada equipo.

El Servicio FTP es ofrecido por la capa de Aplicación del modelo de capas de redTCP/IP al usuario, utilizando normalmente el puerto de red 20 y el 21. Unproblema básico de FTP es que está pensado para ofrecer la máxima velocidaden la conexión, pero no la máxima seguridad, ya que todo el intercambio deinformación, desde el login y password del usuario en el servidor hasta latransferencia de cualquier archivo, se realiza en texto plano sin ningún tipo decifrado, 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 eltráfico.

¿QUÉ SON LOS WEB SERVICES?

El término Web Services describe una forma estandarizada de integraraplicaciones WEB mediante el uso de XML, SOAP, WSDL y UDDI sobre losprotocolos de la Internet. XML es usado para describir los datos, SOAP se ocupapara la transferencia de los datos, WSDL se emplea para describir los serviciosdisponibles 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 entrelas empresas y sus clientes. Los Web Services permiten a las organizacionesintercambiar datos sin necesidad de conocer los detalles de sus respectivosSistemas de Información.

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

programa ejecutable, tal de entregarle a los usuarios un funcionalidad específicaque 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, estoporque la comunicación se hace con XML. Los Web Services no están ligados aningún Sistema Operativo o Lenguaje de Programación. Por ejemplo, un programaescrito en Java puede conversar con otro escrito en Pearl; Aplicaciones Windowspuede conversar con aplicaciones Unix. Por otra parte los Web Services nonecesitan usar browsers (Explorer) ni el lenguaje de especificación HTML.

El modelo de computación distribuida de los Web Services permite lacomunicación de aplicación a aplicación. Por ejemplo, la aplicación que procesalas órdenes de compra se puede comunicar con el sistema de inventarios, tal queeste último le puede informar a la aplicación de compras cuales ítems debencomprarse por estar bajo su nivel mínimo. Dado el nivel integración que proveenpara las aplicaciones, Los Web Services han crecido en popularidad y hancomenzado a mejorar los procesos de negocios. De hecho, algunos postulan quelos 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 trabajanconjuntamente con los estándares que están emergiendo para asegurar laseguridad y operatividad, de modo de hacer realidad que el uso combinado devarios Web Services, independiente de la o las empresas que los proveen, estegarantizado. A continuación se describen brevemente los estándares que estánocupando los Web Services.

XMLAbreviación de Extensible Markup Language. El XML es una especificacióndesarrollada por W3C[1]. Permite a los desarrolladores crear sus propios tags[2],que les permiten habilitar definiciones, transmiciones, validaciones, einterpretación de los datos entre aplicaciones y entre organizaciones.

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

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

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

TIENDA VIRTUAL.Las tiendas virtuales son páginas webs, utilizadas para publicar productos yvender 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ásimportante es que pueden hacerlo desde cualquier parte del mundo, utilizando unacomputadora.

¿A quién le sirve tener una tienda virtual?A cualquier persona o empresa que tenga uno o varios productos y quieraextender sus fronteras, vendiendo sus productos en cualquier parte del mundo através de la red.

Una tienda virtual permite también brindarle a nuestros clientes una herramientapara conocer nuestros productos antes de visitarnos personalmente, en una tiendatradicional un cliente no siempre tiene a la vista todos nuestros productos, encambio con un tienda virtual sí. Otro punto importante es que el cliente puedetomarse 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 pormedio del protocolo HTTP(S) el cual es permitido por la mayoría de los Firewallsde red. Por otra parte, para utilizar Web Services se debe publicar una descripcióncompleta del servicio en un registro público. Estas dos características representanuna brecha de seguridad que puede ser aprovechada por usuarios maliciosos paracometer ataques a una organización para obtener información confidencial pararealizar operaciones fraudulentas, y para degradar el nivel de servicio. Paraprevenir y mitigar el riesgo de estas amenazas se recomienda utilizar un modelode prevención y mitigación, o tomar medidas preventivas a priori paraimplementarlas en un corto plazo. La tendencia mundial en el uso de WebServices es creciente y los desafíos inherentes a la seguridad de la informaciónson cada vez mayores. Sin embargo, existen tecnologías y estándares paraabordar estos desafíos, la dificultad está en llevarlos a la práctica de la mejorforma.

BIBLIOGRAFIA.

TIPO TITULO AUTOR EDITORIAL/REVISTA AÑO

Libro Java 2 Manual deProgramación

Joyanes Aguilar,Luis

McGraw-Hill 2001

Libro Web StandardsProgrammer'sReference: HTML, CSS,JavaScript, Perl,Python, and PHP

Schafer, StevenM.

Wrox 2005

Libro Perl, CGI y Java Script AnayaMultimedia

Anaya Multimedia 2001

Libro Java and XML McLaughlin,Brett yLoukides, Mike

O'Reilly 2000

Libro Perl, CGI, andJavaScript Complete

Sybex Inc Sybex Inc 2000

Libro JavaScript: A Beginner'sGuide

Pollock, John McGraw-Hill OsborneMedia

2003