El documento describe los servicios web, incluyendo su definición, modelo arquitectónico, requisitos y ventajas. Los servicios web permiten la interoperabilidad entre aplicaciones a través de Internet utilizando estándares como XML, SOAP y WSDL.

1. “Excelencia en la educación, fortaleza del país.”
Asignatura:
Programación Web
Alumnas:
Cruz Mendoza Lidia
Remigio Pantaleón Ana Gabriela
Romualdo Osorio Liliana
Servicios Web FECHA:
Diciembre 2011

2. ¿Qué es un web service?
Un web service es una aplicación que puede ser descripta, publicada, localizada e
invocada a través de una red, generalmente Internet. Combinan los mejores aspectos del
desarrollo basado en componentes y la Web.
Al igual que los componentes, los web services son funcionalidades que se encuentran dentro
de una caja negra, que pueden ser reutilizados sin preocuparse de cómo fueron
implementados. A diferencia de la actual tecnología de componentes, no son accedidos por
medio de protocolos específicos del modelo de objetos como ser RMI, DCOM o IIOP; sino que
son accedidos utilizando protocolos web como ser HTTP y XML.
La interface de los web services está definida en términos de los mensajes que el mismo
acepta y retorna, por lo cual los consumidores de los web services pueden ser implementados
en cualquier plataforma y en cualquier lenguaje de programación, solo tiene que poder crear y
consumir los mensajes definidos por la interface de los web services.
El modelo de web services.
La arquitectura básica del modelo de web services describe a un consumidor, un proveedor y
ocasionalmente un corredor (broker). Relacionados con estos agentes están las operaciones
de publicar, encontrar y enlazar.
La idea básica consiste en que un proveedor publica su servicios en un corredor, luego un
consumidor se conecta el corredor para encontrar los servicios deseados y una vez que lo
hace se realiza un lazo entre el consumidor y el proveedor.
Cada entidad puede jugar alguno o todos los roles.
Por todo lo anterior hay ciertos requerimientos a la hora de desarrollar o consumir un web
services:
 Una forma estándar de representar los datos.
XML es la opción obvia para este requerimiento.
 Un formato común y extensible de mensajes.
SOAP es el elegido en este caso; SOAP es un protocolo liviano para el intercambio de
información. Más adelante en este documento lo veremos con más detalle.
 Un lenguaje común y extensible para describir los servicios.
La opción en este caso es WSDL. Es un lenguaje basado en XML desarrollado en
forma conjunta por IBM y Microsoft. Lo veremos con más detalle más adelante en este
documento.
 Una forma de descubrir los servicios en Internet.
UDDI se utiliza en este caso; el mismo especifica un mecanismo para publicar y
localizar los servicios por parte de los proveedores y consumidores respectivamente.
Se verá con más detalle más adelante en este documento.

3. Ventajas y retos.
Los web services apuntan a ser la piedra fundamental de la nueva generación de sistemas
distribuidos. Estos son algunos puntos para fundamentar esta afirmación:
 Interoperabilidad:
Cualquier web service puede interactuar con otro web service. Como los web services
pueden ser implementados en cualquier lenguaje, los desarrolladores no necesitan
cambiar sus ambientes de desarrollo para producir o consumir web services.
 Encapsular reduce la complejidad
Todos los componentes en un modelo de web services son web service. Lo importante
es la interface que el servicio provee y no como esta implementado, por lo cual la
complejidad se reduce.
 Fácil de utilizar:
El concepto detrás de los web services es fácil de entender, incluso existen toolkits de
vendedores como IBM o Microsoft que permiten a los desarrolladores crear web
services en forma rápida y fácil.
 Soporte de la Industria:
Todas las empresas de software importantes soportan SOAP, e incluso están
impulsando el desarrollo de web services. Por ejemplo la nueva plataforma de
Microsoft .NET esta basada en web services, haciendo muy simple el desarrollo de los
mismos que luego podrían ser consumidos por un web service desarrollado utilizando
VisualAge de IBM y viceversa.
A la vez hay ciertos retos técnicos que los web services tienen que sortear para poder tener
éxito. Muchos de estos retos están relacionados con el ambiente abierto en el que tienen que
sobrevivir. Estos son algunos de esos puntos:
· Descubrimiento:
¿Cómo un web service se anuncia para ser descubierto por otro servicio? ¿Qué pasa si
el servicio se cambió o se movió luego de ser anunciado?
WSDL y UDDI son dos nuevos estándares que manejan este punto.
· Confiabilidad:
Algunos web services son más confiables que otros. ¿Cómo puede ser medida esa
confiabilidad y comunicada? ¿Qué pasa cuando un web service esta off-line en forma
temporaria? ¿Localizamos y utilizamos un servicio alternativo brindado por otra
empresa o esperamos a que el servicio este de nuevo on-line?
· Seguridad:
Muchos web services son publicados para ser utilizados sin ninguna restricción, pero
muchos otros van a necesitar autenticación para que los utilicen solo los usuarios
autorizados. ¿Cómo autentifica a los usuarios un web service? ¿Lo hace a nivel del
método que lo implementa o utiliza otro web service para realizar la autenticación?
· Responsabilidad
En caso de que el web service no sea de acceso libre, ¿Cómo puedo definir cuantas
veces un consumidor puede acceder al web service una vez contratado? ¿Cómo se
cobra su uso? ¿Cómo se indica que un servicio ya no está más en línea?

4. CARACTERÍSTICAS DE LOS WEB SERVICES
Los servicios web son la revolución informática de la nueva generación de aplicaciones que
trabajan colaborativamente en las cuales el software está distribuido en diferentes servidores.
La informática se inició con programas monousuarios implantados en grandes ordenadores.
Posteriormente estas primeras aplicaciones alcanzaron la capacidad de atender a diferentes
usuarios. Pasaron los años y llego la arquitectura cliente-servidor, que gracias a este modelo
de desarrollo, la aplicación se dividía en una parte que interaccionaba con el usuario y otra
parte destinada al procesamiento de información. En este acercamiento se consiguió que cada
una de las partes que constituían la aplicación pudiera residir en computadoras distintas. Con
el paso del tiempo, la computación aumento y llego la era de las aplicaciones distribuidas en las
cuales los procesos se realizaban en diferentes unidades. De este paso surgió la tecnología
Internet para solventar las problemáticas asociadas a fallo de aplicación centralizado.
Un desarrollador puede incluir en sus sitios soluciones sentencias, es decir, instrucciones que
consuman Web Services de terceros o propios como por ejemplo aquellos que proporcionan
los datos meteorológicos para una localidad determinada, las cotizaciones de determinadas
monedas, la cartelera de películas, el calendario o agenda de un especialista médico, etc.
Pensando en forma comercial, ¿Qué pasaría si por ejemplo estuvieras trabajando en tu
procesador de texto en un idioma para el cual no tienes un corrector ortográfico ni sintáctico
instalado (quizás no exista para instalar), pero deseas realizar la revisión del documento a toda
costa? Bien, perfectamente podría haber una opción en el menú de este procesador que de
alguna forma localice un Web Service en Internet que brinde esta funcionalidad, y lo más
interesante aún para quien lo haya desarrollado es que puede solicitar al usuario que se
subscriba para su uso. Como ves, todos ganan en esta transacción.
El ejemplo anterior muestra una realidad a la que no podemos estar ajenos. Es un replanteo de
la estrategia utilizada por los desarrolladores quienes ahora, al realizar una aplicación, no
deben pensar únicamente en el lugar físico donde la misma va a ejecutarse sino en que esa
aplicación deberá estar interconectada con otras computadoras, corriendo otras aplicaciones
quizás en otras plataformas y lenguajes, pero usando protocolos y estándares universales. El
intercambio se intensificará muchísimo más y quizás existan por ejemplo “proveedores de
dominios de datos” como ser los países, de forma tal que la aplicación que yo realice en lugar
de crear toda la lógica para manejar las tablas y el cargado de los datos para el concepto PAIS,
se limite a consumir un Web Service que me tome esta información de algún lugar en Internet.
Imagino una reutilización aún mayor de funcionalidades y una colaboración e intercambio de
lógica a nivel mundial.
Existen algunas consideraciones y conceptos que son necesarios mencionar para comenzar a
entender el tema:

5.  Un Web Service puede ser registrado para poder dejarlo a disposición de otros usuarios y para
que los mismos puedan localizarlo. Un mecanismo para registrar estos servicios es por medio
de UDDI, sigla que corresponde a Universal Description , Discovery and Integration, un
“repositorio de Web Services”. Para registrar un servicio tendrás que tener en cuenta que
debes suministrar la información de tu empresa, en qué categorías ubicarías tu servicio y la
interfaz a utilizar para consumir este servicio.
 El mecanismo utilizado por un Web Service para especificar de qué forma hay que
proporcionarle los datos, de manera tal que cualquiera pueda interaccionar con el mismo, es
por medio de lenguaje XML. Esta información se almacena en un archivo llamado WSDL (Web
Services Description Language), el cual contiene un documento XML junto con la descripción
de ciertos mensajes SOAP y cómo deben intercambiarse, así como también dónde está el
recurso del servicio y con qué protocolo debe dialogar quien lo consume.
 El protocolo de comunicación utilizado es el SOAP generalmente, el cual es relativamente
sencillo de utilizar.
 Los Web Services utilizan protocolos comúnmente conocidos y difundidos tales como el
formato XML, TCP/IP como protocolo de transporte y HTTP como protocolo de transferencia de
hipertexto.
Microsoft para conseguir este propósito con su tecnología .NET emplea como protocolo de
comunicación, una aplicación XML, llamada SOAP.
¿Qué es SOAP? Son las siglas de Simple Object Access Protocol. Este protocolo deriva de un
protocolo creado por David Winer, XML-RPC en 1998. En su sitio web, Userland,
http://ww.userland.com se puede encontrar multitud de documentación acerca de este primer
protocolo de comunicación bajo http mediante XML. Con este protocolo se podian realizar RPC
o remote procedure calls, es decir, podiamos bien en cliente o servidor realizar peticiones
mediante http a un servidor web. Los mensajes debían tener un formato determinado
empleando XML para encapsular los parámetros de la petición. Con el paso del tiempo el
proyecto iniciado por David Winer interesó a Importantes multinacionales entre las que se
encuentran IBM y Microsoft y de este interés por XML-RPC se desarrolló SOAP.
SOAP es un protocolo más completo que XML-RPC pero cabe decir que más complejo.
La siguiente tabla comparativa muestra las diferencias entre ambos protocolos:
XML-
Caracteristicas SOAP
RPC
Escalarares básicos. yes yes
Estructuras. yes yes
Arrays. yes yes
Estructuras nombradas y Arrays. no yes
Manejo de fallos. yes yes
Curva de aprendizaje. yes no
yes (US-ASCII, UTF-8, UTF-
Conjunto de caracteres. no
16)
Tipos de datos definidos por usuario. no yes
Requiere entendimiento del cliente. no yes

6. Instrucciones de procesamiento
no yes
Especificas.
A continuación se muestra un ejemplo de SOAP:
POST /StockQuote HTTP/1.1
Host: www.stockquoteserver.com
Content-Type: text/xml; charset="utf-8"
Content-Length: nnnn
SOAPAction: "http://example.org/2001/06/quotes"
env:encodingStyle="http://www.w3.org/2001/06/soap-encoding"
xmlns:m="http://example.org/2001/06/quotes">
DIS
GOOGLE
Plataforma de desarrollo
Para la implementación de la aplicación se ha escogido el entorno de desarrollo web Cocoon.
Cocoon es un producto open source perteneciente al proyecto Apache Cocoon La versión de
Cocoon utilizada, 2.1.5, incluye todo lo necesario para su puesta en marcha (servidor web y
contenedor de servlets), excepto el entorno de desarrollo de Java (J2SE) que debe estar
instalado previamente. En nuestro caso, utilizamos la versión 1.4.2 de J2SE. El entorno puede
desplegarse tanto en una máquina Windows como en un sistema Unix.
Cocoon es un entorno basado en Java enfocado a la construcción de aplicaciones web
basadas en componentes y en la separación de presentación y contenido. El elemento de
construcción de las aplicaciones es el pipeline o tubería, el cual realiza una serie de
transformaciones a una petición hasta generar un documento de salida. La representación
intermedia de los datos es en XML. Estos datos atraviesan una serie de elementos de
procesado hasta producir el documento de salida. La salida normalmente será una página
HTML, aunque también podría ser un archivo PDF o tener otros formatos.

7. Interfaz WSDL de Google
Google proporciona un archivo WSDL que describe las operaciones soportadas. Este fichero se
encuentra entre los archivos descargados de la API, aunque también se ofrece de forma online.
La descripción WSDL indica que se soportan tres operaciones: doSpellingSuggestion,
doGetCachedPage y doGoogleSearch. La primera permite solicitar a Google una sugerencia
de escritura correcta para un término mal tecleado. La segunda devuelve la caché almacenada
de Google para una URL dada. Por último, doGoogleSearch, se corresponde con el servicio
tradicional de búsquedas en la Web.
Cierto es que Google podría ofrecer un mayor número de operaciones, como el acceso a
grupos de noticias o búsqueda de imágenes. Sin embargo, la API está fechada en 2002 y no
parece que haya más interés que el de ofrecer un número limitado de operaciones como
demostración del sistema.
Operación doSpellingSuggestion
Su manejo es el más sencillo de las tres. Para su invocación requiere dos entradas:
 key. Es el número de licencia proporcionado al usuario de la API.
 phrase. Término o términos que deseamos verificar su corrección.
Su salida es:
 return. Término o términos corregidos. O nada, si no ha habido cambios.
Operación doGetCachedPage
Su interfaz también es muy sencilla. Requiere dos entradas (key y url) y devuelve como salida
la caché almacenada para la URL indicada. Entradas:
 key. Es el número de licencia proporcionado al usuario de la API.
 url. URL de la página o documento.
Su salida es:
 return. Contenido de la caché para la URL solicitada.
Operación doGoogleSearch
Esta operación es la que admite un mayor número de opciones de configuración. Entre las
entradas, las más importantes son la clave y la consulta solicitada, pero también hay otras que
debemos conocer:
 key. Es el número de licencia proporcionado al usuario de la API.
 q. Consulta formada por uno o varios términos de búsqueda.
 start. Posición (índice) del primer elemento a partir del cual solicitamos la búsqueda.
 maxResults. Número máximo de elementos que solicitamos a partir del indicado en la entrada
anterior. El número devuelto podrá ser menor si no hay suficientes resultados encontrados.
 filter. Tipo lógico que indica si realizamos la búsqueda filtrando los elementos similares a otros
mostrados o no.
 restrict. Permite restringir la búsqueda a un almacén de búsqueda determinado como, por
ejemplo, “linux”.

8.  safeSearch. Permite filtrar contenidos no aptos para menores.
 lr. Restringe a un idioma determinado.
 ie. Codificación de entrada (obsoleto).
 oe. Codificación de salida (obsoleto).
La salida se devuelve mediante el elemento return del tipo complejo GoogleSearchResult. Este
tipo está formado por los siguientes elementos:
 documentFiltering. Indica si la búsqueda se realizó con el filtro activo o no.
 searchComments. Comentarios de la búsqueda como, por ejemplo, cuando se indica que
ciertas palabras no se incluyeron en la búsqueda por ser poco relevantes.
 estimatedTotalResultsCount. Número de resultados totales.
 estimateIsExact. Indica si la cantidad devuelta en el elemento anterior es un número exacto o
aproximado.
 resultElements. Array construido con el tipo complejo ResultElement. Este array contiene un
elemento por cada resultado encontrado según las opciones de búsqueda.
 searchQuery. Consulta que se ha buscado.
 startIndex. Índice del primer resultado devuelto.
 endIndex. Índice del último resultado devuelto. Obsérvese que los resultados comprendidos
entre startIndex y endIndex serán un subconjunto del total de resultados,
estimatedTotalResultsCount, sin exceder el número máximo de resultados que se solicitó,
maxResults.
 searchTips. Consejos de búsqueda como, por ejemplo, “elimine las comillas de la búsqueda
para obtener más resultados”.
 directoryCategories. Array construido con el tipo complejo DirectoryCategory. Se incluyen las
distintas categorías del directorio ODP (Open Directory Project) que tienen relación con la
consulta de búsqueda.
 searchTime. Tiempo que se ha tardado en ejecutar la búsqueda.
Los elementos anteriores proporcionan información general de toda la búsqueda. Pasamos
ahora a describir los elementos del tipo complejo ResultElement, con información relativa a un
resultado concreto.
 summary. Resumen escrito por un editor del directorio, en caso de que el sitio esté incluido en
el directorio.
 URL. Identificador del documento.
 snippet. Fragmento de texto del documento donde normalmente aparecerán los términos
buscados.
 title. Título del documento.
 cachedSize. Tamaño de la página almacenada en caché. Si no está almacenada, no devuelve
nada.
 relatedInformationPresent. Indica si está soportada la búsqueda de documentos similares para
la URL de este resultado.
 hostName. Indica el nombre del host en caso de que se haya mostrado ya al menos 1 resultado
de ese mismo host.
 directoryCategory. Tipo complejo que indica la categoría del directorio donde está incluido el
sitio.
 directoryTitle. Título de la categoría del directorio.

9. Invocación de operaciones desde Java
Google proporciona una API Java formada por una estructura de clases en un archivo .jar y
documentación en formato HTML. También se incluye un ejemplo de uso que funciona bajo
línea de comando.
Las clases Java encapsulan en métodos todo el procesamiento del web service. Por ejemplo,
para comprobar la corrección de un término basta con invocar el método doSpellingSuggestion
(phrase) que recibe un String y devuelve un String con el término corregido. Debido a la
posibilidad de incluir código Java en páginas XSP de Cocoon, resulta sencillo invocar los
métodos y procesar los resultados. Estos resultados se colocarán en elementos XML para que
puedan ser presentados en HTML después de convertirlos mediante una hoja de estilos XSLT.
El archivo googleapi.jar debe ubicarse en un directorio visible por Cocoon. En nuestro caso,
bastó con que estuviese presente en el directorio java/j2sdk/jre/ lib/ext antes de arrancar
Cocoon.
Cada una de las clases requeridas por la aplicación XSP debe incluirse una a una mediante
elementos <xsp:include>. Los archivos de la aplicación corregir.xsp y vercache.xsp utilizan este
procedimiento para comprobar la corrección de un término y ver la caché de una URL,
respectivamente.
Invocación de operaciones desde XSP
El procedimiento descrito en el apartado anterior es válido sólo en el caso del web service de
Google, puesto que se suministran clases Java que encapsulan todo el diálogo SOAP entre las
máquinas. Sin embargo, esto no será lo usual en otros web services, por lo que necesitaremos
confeccionar nosotros mismos los mensajes SOAP y procesar sus respuestas, según la
correspondiente descripción WSDL.
Cocoon facilita esta tarea mediante la funcionalidad “SOAP logicsheet” que se invoca en
páginas XSP con el elemento <soap:call>. Este elemento genera el mensaje SOAP enviando
los elementos que contiene, lo ejecuta e incluye la respuesta en su lugar.
Una vez tenemos la respuesta en formato XML, se puede procesar mediante una hoja de
estilos XSLT y convertirla así a HTML. Este procedimiento se ha utilizado en el archivo
buscar.xsp de la aplicación. En este caso no se utilizan las clases Java contenidas en el
archivo googleapi.jar. De la misma forma, se podrían haber realizado los archivos xsp de las
otras dos operaciones sin necesidad de utilizar las clases Java suministradas por Google, pero
hemos creído conveniente ofrecer ejemplos de ambos mecanismos para ilustrar las
posibilidades de Cocoon y Google Web API.

10. SEGURIDAD
PROYECTO WebScarab OWASP
Webscarab es un marco de trabajo para analizar servicios web que se comunica usando los
protocolos HTTP y HTTPS. Está escrito en Java, por lo que es portable a muchas plataformas.
WebScarab tiene muchos modos de operación, implementados por varios plugins. Su uso más
común es operar WebScarab como un proxy de intercepción, que permite al operador revisar y
modificar las peticiones creadas por el navegador antes de que sean enviados al servidor, y
para revisar y modificar respuestas enviadas por el servidor antes de que sean recibidas por el
navegador. Webscarab es capaz de interceptar comunicación en HTTP y HTTPS. El operador
puede también revisar las conversaciones (peticiones y respuestas) que hayan pasado por
WebScarab.
 Consumo.
WebScarab, es una herramienta diseñada principalmente para ser usada por personas que
pueden escribir código por ellos mismos, o al menos tienen un muy buen conocimiento del
protocolo HTTP.
WebScarab está diseñado para ser una herramienta que cualquiera que necesite exponer la
funcionalidad de una aplicación basada en HTTP(S), ya sea para permitir al desarrollador
depurar problemas difíciles o permitir a un especialista en seguridad identificar vulnerabilidades
mientras la aplicación está siendo diseñada o implementada.
 Características
Un marco de trabajo sin ninguna función que no valga la pena, por supuesto, WebScarab
provee un número de plugins, cuyo objetivo principal, por el momento, es agregar funcionalidad
de seguridad. Estos plugins incluyen:
 Proxy - Observa el tráfico entre el navegador y el servidor Web. El proxy de WebScarab
es capaz de observar tanto HTTP como trafico HTTPS cifrado al negociar una conexión
SSL entre WebScarab y el navegador en vez de simplemente conectar el navegador al
servidor y permitir que un flujo de datos cifrado pase por él.
 Intercepción Manual - permite al usuario modificar peticiones y respuestas HTTP y
HTTPS "al vuelo", antes de que ellas alcancen el servidor o el navegador.
 SOAP - hay un plugin que interpreta WSDL, y presenta las varias funciones y los
parámetros requeridos, permitiendo que sean editadas antes de que sean enviadas a el
servidor.
XSS/CRLF - este plugin de análisis pasivo busca datos controlados por el usuario en los
encabezados y cuerpo de las respuestas HTTP para identificar posibles inyecciones CRLF
(partición de respuesta HTTP) y vulnerabilidades de secuencia de comandos en sitios cruzados
(XSS).
WS-SecureConversation
Es un Web Services, creado por IBM y otros, que trabaja en conjunto con WS-Security, WS-
Trust y WS-Policy para permitir la creación y el intercambio de contextos de seguridad.
Ampliación de los casos de uso de WS-Security, con el propósito de WS-SecureConversation
es establecer contextos de seguridad de varios intercambios de mensajes SOAP, lo que reduce
la sobrecarga de establecimiento de claves.

11.  Características
 Establecer un nuevo contexto de seguridad en los modos siguientes:
o Token de seguridad contexto creado por un servicio de token de seguridad (WS-
Trust STS)
o Token de seguridad contexto creado por una de las partes que se comunican y
se propaga con un mensaje
o Token de seguridad contexto creado a través de la negociación / intercambios
 Renovar el contexto de seguridad
 Modificar el contexto de seguridad (agregar notificaciones)
 Cancelar el contexto de seguridad
 Derivar clave: las partes pueden usar claves diferentes a cada lado y la función (firmar /
cifrar), y las teclas cambian con frecuencia para evitar los ataques criptográficos
WS-SecureConversation tiene por objeto proporcionar un marco extensible y una sintaxis
flexible, con la que se podría poner en práctica diversos mecanismos de seguridad. No
garantiza por sí sola la seguridad, pero el ejecutor tiene que asegurarse de que el resultado no
es vulnerable a cualquier ataque.
 Pros / Contras
Siguiendo un patrón similar a TLS, WS-SecureConversation establece una especie de clave de
sesión. La sobrecarga de procesamiento para el establecimiento de claves se reduce
significativamente en comparación con WS-Security en el caso de intercambios de mensajes
con frecuencia. Sin embargo, una nueva capa se coloca en la parte superior de WS-Security,
que implica otros protocolos WS-* como WS-Addressing y WS-Trust. Por lo tanto la
importancia del desempeño tiene que ser comparado con la complejidad añadida y
dependencias.
OWASP - WSFuzzer
OWASP (Open Web Application Security Project) es una comunidad creada con la finalidad de
establecer métodos de trabajo seguro a la hora de desarrollar aplicaciones web. OWASP posee
un modelo de mecanismos de seguridad ante amenazas incluyendo recomendaciones al
respecto. El proyecto está formado por una amplia colección de guías y herramientas, para
ayudar al desarrollo seguro de aplicaciones y auditorias.
Dentro de las herramientas de seguridad que engloba OWASP, una de las más interesantes es
WSFuzzer. Una herramienta de test de penetración para servicios web basados en HTTP
SOAP.
 Características:
 Hace pruebas de intrusión en un servicio Web basado en HTTP SOAP ya sea en un
WSDL, un punto final (endpoint) o un nombre (namespace).
 Puede detectar inteligentemente WSDL.
 Incluye un scanner de puertos TCP simple.
 WSFuzzer tiene la habilidad de manipular métodos con múltiples parámetros. Hay 2
modos de ataque: "individual" y "simultaneo". Cada parámetro puede ser tratado como
una entidad única (modo individual), o múltiples parámetros son atacados
simultáneamente.

12.  La generación de ataques consiste en: una combinación de un archivo de diccionario,
algunos grandes patrones de inyección dinámicos opcionales y algunos ataques
específicos incluyendo generación de ataques automáticos de XXE y WSSE.
 La herramienta también proporciona la opción de usar algunas técnicas de evasión de
IDS, lo que lo hace una poderosa experiencia de pruebas de seguridad de
infraestructura (IDS/IPS). Realiza una medida de tiempo entre cada petición y respuesta
para ayudar potencialmente en el análisis de resultados.
 Para cualquier ejecución del programa los vectores de ataque generados son guardados
en un archivo XML. El archivo XML es ubicado en el mismo directorio donde se guardan
el archivo de resultados HTML.
 Un archivo XML previamente generado de vectores de ataque puede ser utilizado en
lugar de la combinación de diccionario/automatizado. Esto sirve para cuando se
necesitan los mismos vectores para ser usados una y otra vez.
MICROSOFT
CREACIÓN DE SERVICIOS WEB
Microsoft mantiene su compromiso de fomentar el desarrollo de un rico ecosistema para la
creación y gestión de sistemas interconectados. Microsoft ha realizado cuantiosas inversiones
en servicios Web, basando por completo su plataforma de desarrollo de última generación en
los servicios Web con Microsoft .NET.
.NET FRAMEWORK 3.0
.NET Framework pone dentro del sistema operativo soluciones pre-codificadas que
anteriormente han sido generadas mediante lenguajes de programación y herramientas de
distintos tipos. .NET Framework proporciona el soporte necesario para los servicios Web, de
manera que los desarrolladores puedan codificar, descubrir, depurar, instalar y consumir
servicios Web utilizando cualquiera de los más de 20 lenguajes de programación soportados
por este entorno.
La versión 3.0 de .NET Framework, aparecida en 2006, amplía las interfaces de programación
de la versión 2.0 con nuevas tecnologías para la creación de aplicaciones a fin de proporcionar
comunicaciones interoperables y fluidas, la capacidad de modelizar una gran variedad de
procesos de negocio y gestionar la identidad y crear experiencias diferenciadas para los
usuarios. Los componentes extendidos de .NET Framework 3.0 para la creación y
aprovechamiento de los servicios Web son Windows Communication Foundation (WCF),
Windows Workflow Foundation (WF), Windows CardSpace, y Windows Presentation
Foundation. Concretamente, WCF y WF incorporan nuevas y muy potentes funcionalidades
para el desarrollo de aplicaciones basadas en servicios web y bien integradas:
• Windows Communication Foundation es la tecnología de servicios Web de nueva
generación de Microsoft, que facilitan la interconexión entre sistemas y aplicaciones dentro de
la organización y a lo largo de infraestructuras geográficamente dispersas. Es el primer modelo
de programación creado de principio a fin para facilitar el desarrollo de aplicaciones orientadas
a servicios.

13. • Windows Workflow Foundation es un modelo de programación, un motor y herramientas
para la creación rápida de aplicaciones con gestión de workflow en entornos Windows.
BIZTALK SERVER
Como complemento a las tecnologías de desarrollo .NET Framework 3.0, BizTalk Server es un
producto de servidor orientado a los profesionales de IT y arquitectos, que permite la
integración de sistemas, empleados y partners de negocio. El núcleo de la arquitectura de
BizTalk Server se basa en XML y .NET Framework y es plenamente compatible con todos los
estándares abiertos en los que se basan los servicios Web. Una solución BizTalk puede
consumir los servicios Web actuales y exponer los procesos de negocio (orquestaciones de
BizTalk) como servicios Web. BizTalk se posiciona como la capa de gestión que organiza los
servicios Web, controlando el flujo y las interacciones entre ellos y agregando los servicios
individuales dentro de una solución compuesta de nivel superior.
BizTalk Server permite también la integración de aplicaciones y sistemas que no son
compatibles con los servicios Web. Mediante el empleo de una gran variedad de adaptadores,
BizTalk Server puede hacer que las funcionalidades de sistemas y aplicaciones antiguos
queden disponibles de cara a los procesos internos de las organizaciones.
BizTalk Server se integra también con Microsoft Office SharePoint Server. Juntos, BizTalk
Server y SharePoint facilitan la creación de soluciones de procesos de negocio “preparados
para las personas” que afectan a los profesionales de la información. SharePoint permite a
estos profesionales recopilar y gestionar datos de negocio (mediante la captura de datos en
XML, estructurados y no estructurados), aportando la pieza de desktop esencial en el puzle de
las soluciones de procesos de negocio. Biztalk Server, en este caso, actúa como el punto
central de orquestación para los procesos de gran envergadura, que abarcan tanto a sistemas
de información como a personas.
.
Microsoft Office SharePoint Server
Windows SharePoint Services 3.0 proporciona servicios Web para interaccionar con casi
cualquier aspecto de cada servidor, sitio, lista, biblioteca, encuesta o página Web basada en
Windows SharePoint Services 3.0. En los procedimientos siguientes se utiliza el servicio Web
Webs. El servicio Web Webs proporciona métodos para trabajar con sitios y subsitios de
SharePoint. Por ejemplo, puede usar este servicio Web para mostrar y realizar consultas de los
títulos y direcciones URL de todos los sitios contenidos en la colección actual de sitios, de los
títulos y direcciones URL de todos los sitios ubicados directamente debajo del sitio actual, o de
la dirección URL del sitio principal de la dirección URL de la página especificada.
También Microsoft Office SharePoint Server 2007 proporciona una experiencia de usuario
sencilla y consistente, gracias a aplicaciones de cliente muy conocidas y con ello hace que las
tareas de iniciación de procesos de negocio de tipo manual, la participación en estos procesos,
su seguimiento y la elaboración de informes sea mucho más sencilla y flexible.
Está diseñado para optimizar la forma en que las personas interactúan con los contenidos y los
procesos dentro de las organizaciones y a través de ellas. Office SharePoint Server permite
aprovechar las ventajas de los workflows para automatizar y mejorar la visibilidad de las
actividades de negocio más habituales, como son la revisión y aprobación de documentos, el
seguimiento de incidencias y la recogida de firmas. Su excelente integración con aplicaciones

14. muy conocidas de cliente, el correo electrónico y los navegadores Web simplifica la experiencia
del usuario. Los usuarios finales pueden definir y modelar con facilidad sus propios procesos
aplicando herramientas de Microsoft muy familiares.
Office SharePoint Server contribuye a eliminar los procesos manuales de gestión de la
información, ineficientes en general. Los formularios electrónicos se pueden utilizar para
recoger información que luego se puede integrar en los sistemas de línea de negocio (LOB), en
los archivos documentales, pueden servir para iniciar procesos de workflow o enviarse a
servicios Web. Esta automatización permite eliminar las redundancias y errores que afectan a
la introducción manual de datos, y garantiza el acceso a datos más exactos y en tiempo real.
BIBLIOGRAFIA
http://translate.google.com.mx/translate?hl=es&langpair=en%7Ces&u=http://en.wikipedia.org/wiki/WS-Security
http://vtroger.blogspot.com/2008/09/auditoria-de-seguridad-de-servicios-web.html
https://www.owasp.org/index.php/Proyecto_WebScarab_OWASP
http://www.blueinfy.com/wsscanner.html