Servicios w eb

793 views
745 views

Published on

Investigacion sobre Web services

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
793
On SlideShare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
11
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Servicios w eb

  1. 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. 2. ¿Qué es un web service? Un web service es una aplicación que puede ser descripta, publicada, localizada einvocada a través de una red, generalmente Internet. Combinan los mejores aspectos deldesarrollo basado en componentes y la Web.Al igual que los componentes, los web services son funcionalidades que se encuentran dentrode una caja negra, que pueden ser reutilizados sin preocuparse de cómo fueronimplementados. A diferencia de la actual tecnología de componentes, no son accedidos pormedio de protocolos específicos del modelo de objetos como ser RMI, DCOM o IIOP; sino queson 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 mismoacepta y retorna, por lo cual los consumidores de los web services pueden ser implementadosen cualquier plataforma y en cualquier lenguaje de programación, solo tiene que poder crear yconsumir 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 yocasionalmente un corredor (broker). Relacionados con estos agentes están las operacionesde publicar, encontrar y enlazar.La idea básica consiste en que un proveedor publica su servicios en un corredor, luego unconsumidor se conecta el corredor para encontrar los servicios deseados y una vez que lohace 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 webservices:  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. 3. Ventajas y retos.Los web services apuntan a ser la piedra fundamental de la nueva generación de sistemasdistribuidos. 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 quesobrevivir. 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. 4. CARACTERÍSTICAS DE LOS WEB SERVICESLos servicios web son la revolución informática de la nueva generación de aplicaciones quetrabajan 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 diferentesusuarios. Pasaron los años y llego la arquitectura cliente-servidor, que gracias a este modelode desarrollo, la aplicación se dividía en una parte que interaccionaba con el usuario y otraparte destinada al procesamiento de información. En este acercamiento se consiguió que cadauna de las partes que constituían la aplicación pudiera residir en computadoras distintas. Conel paso del tiempo, la computación aumento y llego la era de las aplicaciones distribuidas en lascuales los procesos se realizaban en diferentes unidades. De este paso surgió la tecnologíaInternet para solventar las problemáticas asociadas a fallo de aplicación centralizado.Un desarrollador puede incluir en sus sitios soluciones sentencias, es decir, instrucciones queconsuman Web Services de terceros o propios como por ejemplo aquellos que proporcionanlos datos meteorológicos para una localidad determinada, las cotizaciones de determinadasmonedas, 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 tuprocesador de texto en un idioma para el cual no tienes un corrector ortográfico ni sintácticoinstalado (quizás no exista para instalar), pero deseas realizar la revisión del documento a todacosta? Bien, perfectamente podría haber una opción en el menú de este procesador que dealguna forma localice un Web Service en Internet que brinde esta funcionalidad, y lo másinteresante aún para quien lo haya desarrollado es que puede solicitar al usuario que sesubscriba 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 dela estrategia utilizada por los desarrolladores quienes ahora, al realizar una aplicación, nodeben pensar únicamente en el lugar físico donde la misma va a ejecutarse sino en que esaaplicación deberá estar interconectada con otras computadoras, corriendo otras aplicacionesquizás en otras plataformas y lenguajes, pero usando protocolos y estándares universales. Elintercambio se intensificará muchísimo más y quizás existan por ejemplo “proveedores dedominios de datos” como ser los países, de forma tal que la aplicación que yo realice en lugarde 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 delógica a nivel mundial.Existen algunas consideraciones y conceptos que son necesarios mencionar para comenzar aentender el tema:
  5. 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. 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 GOOGLEPlataforma de desarrolloPara 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 deCocoon utilizada, 2.1.5, incluye todo lo necesario para su puesta en marcha (servidor web ycontenedor de servlets), excepto el entorno de desarrollo de Java (J2SE) que debe estarinstalado previamente. En nuestro caso, utilizamos la versión 1.4.2 de J2SE. El entorno puededesplegarse 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 webbasadas en componentes y en la separación de presentación y contenido. El elemento deconstrucción de las aplicaciones es el pipeline o tubería, el cual realiza una serie detransformaciones a una petición hasta generar un documento de salida. La representaciónintermedia de los datos es en XML. Estos datos atraviesan una serie de elementos deprocesado hasta producir el documento de salida. La salida normalmente será una páginaHTML, aunque también podría ser un archivo PDF o tener otros formatos.
  7. 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. 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. 9. Invocación de operaciones desde JavaGoogle proporciona una API Java formada por una estructura de clases en un archivo .jar ydocumentación en formato HTML. También se incluye un ejemplo de uso que funciona bajolí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 laposibilidad de incluir código Java en páginas XSP de Cocoon, resulta sencillo invocar losmétodos y procesar los resultados. Estos resultados se colocarán en elementos XML para quepuedan 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 arrancarCocoon.Cada una de las clases requeridas por la aplicación XSP debe incluirse una a una medianteelementos <xsp:include>. Los archivos de la aplicación corregir.xsp y vercache.xsp utilizan esteprocedimiento para comprobar la corrección de un término y ver la caché de una URL,respectivamente.Invocación de operaciones desde XSPEl procedimiento descrito en el apartado anterior es válido sólo en el caso del web service deGoogle, puesto que se suministran clases Java que encapsulan todo el diálogo SOAP entre lasmáquinas. Sin embargo, esto no será lo usual en otros web services, por lo que necesitaremosconfeccionar nosotros mismos los mensajes SOAP y procesar sus respuestas, según lacorrespondiente descripción WSDL.Cocoon facilita esta tarea mediante la funcionalidad “SOAP logicsheet” que se invoca enpáginas XSP con el elemento <soap:call>. Este elemento genera el mensaje SOAP enviandolos 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 deestilos XSLT y convertirla así a HTML. Este procedimiento se ha utilizado en el archivobuscar.xsp de la aplicación. En este caso no se utilizan las clases Java contenidas en elarchivo googleapi.jar. De la misma forma, se podrían haber realizado los archivos xsp de lasotras dos operaciones sin necesidad de utilizar las clases Java suministradas por Google, perohemos creído conveniente ofrecer ejemplos de ambos mecanismos para ilustrar lasposibilidades de Cocoon y Google Web API.
  10. 10. SEGURIDADPROYECTO WebScarab OWASPWebscarab es un marco de trabajo para analizar servicios web que se comunica usando losprotocolos 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áscomún es operar WebScarab como un proxy de intercepción, que permite al operador revisar ymodificar las peticiones creadas por el navegador antes de que sean enviados al servidor, ypara revisar y modificar respuestas enviadas por el servidor antes de que sean recibidas por elnavegador. Webscarab es capaz de interceptar comunicación en HTTP y HTTPS. El operadorpuede también revisar las conversaciones (peticiones y respuestas) que hayan pasado porWebScarab.  Consumo.WebScarab, es una herramienta diseñada principalmente para ser usada por personas quepueden escribir código por ellos mismos, o al menos tienen un muy buen conocimiento delprotocolo HTTP.WebScarab está diseñado para ser una herramienta que cualquiera que necesite exponer lafuncionalidad de una aplicación basada en HTTP(S), ya sea para permitir al desarrolladordepurar problemas difíciles o permitir a un especialista en seguridad identificar vulnerabilidadesmientras la aplicación está siendo diseñada o implementada.  CaracterísticasUn marco de trabajo sin ninguna función que no valga la pena, por supuesto, WebScarabprovee un número de plugins, cuyo objetivo principal, por el momento, es agregar funcionalidadde 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 losencabezados 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-SecureConversationEs 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-SecureConversationes establecer contextos de seguridad de varios intercambios de mensajes SOAP, lo que reducela sobrecarga de establecimiento de claves.
  11. 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 sintaxisflexible, con la que se podría poner en práctica diversos mecanismos de seguridad. Nogarantiza por sí sola la seguridad, pero el ejecutor tiene que asegurarse de que el resultado noes vulnerable a cualquier ataque.  Pros / Contras Siguiendo un patrón similar a TLS, WS-SecureConversation establece una especie de clave desesión. La sobrecarga de procesamiento para el establecimiento de claves se reducesignificativamente en comparación con WS-Security en el caso de intercambios de mensajescon 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 laimportancia del desempeño tiene que ser comparado con la complejidad añadida ydependencias.OWASP - WSFuzzerOWASP (Open Web Application Security Project) es una comunidad creada con la finalidad deestablecer métodos de trabajo seguro a la hora de desarrollar aplicaciones web. OWASP poseeun modelo de mecanismos de seguridad ante amenazas incluyendo recomendaciones alrespecto. El proyecto está formado por una amplia colección de guías y herramientas, paraayudar al desarrollo seguro de aplicaciones y auditorias.Dentro de las herramientas de seguridad que engloba OWASP, una de las más interesantes esWSFuzzer. Una herramienta de test de penetración para servicios web basados en HTTPSOAP.  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. 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. MICROSOFTCREACIÓN DE SERVICIOS WEBMicrosoft mantiene su compromiso de fomentar el desarrollo de un rico ecosistema para lacreación y gestión de sistemas interconectados. Microsoft ha realizado cuantiosas inversionesen servicios Web, basando por completo su plataforma de desarrollo de última generación enlos servicios Web con Microsoft .NET..NET FRAMEWORK 3.0.NET Framework pone dentro del sistema operativo soluciones pre-codificadas queanteriormente han sido generadas mediante lenguajes de programación y herramientas dedistintos tipos. .NET Framework proporciona el soporte necesario para los servicios Web, demanera que los desarrolladores puedan codificar, descubrir, depurar, instalar y consumirservicios Web utilizando cualquiera de los más de 20 lenguajes de programación soportadospor este entorno.La versión 3.0 de .NET Framework, aparecida en 2006, amplía las interfaces de programaciónde la versión 2.0 con nuevas tecnologías para la creación de aplicaciones a fin de proporcionarcomunicaciones interoperables y fluidas, la capacidad de modelizar una gran variedad deprocesos de negocio y gestionar la identidad y crear experiencias diferenciadas para losusuarios. Los componentes extendidos de .NET Framework 3.0 para la creación yaprovechamiento de los servicios Web son Windows Communication Foundation (WCF),Windows Workflow Foundation (WF), Windows CardSpace, y Windows PresentationFoundation. Concretamente, WCF y WF incorporan nuevas y muy potentes funcionalidadespara el desarrollo de aplicaciones basadas en servicios web y bien integradas:• Windows Communication Foundation es la tecnología de servicios Web de nuevageneración de Microsoft, que facilitan la interconexión entre sistemas y aplicaciones dentro dela organización y a lo largo de infraestructuras geográficamente dispersas. Es el primer modelode programación creado de principio a fin para facilitar el desarrollo de aplicaciones orientadasa servicios.
  13. 13. • Windows Workflow Foundation es un modelo de programación, un motor y herramientaspara la creación rápida de aplicaciones con gestión de workflow en entornos Windows.BIZTALK SERVERComo complemento a las tecnologías de desarrollo .NET Framework 3.0, BizTalk Server es unproducto de servidor orientado a los profesionales de IT y arquitectos, que permite laintegración de sistemas, empleados y partners de negocio. El núcleo de la arquitectura deBizTalk Server se basa en XML y .NET Framework y es plenamente compatible con todos losestándares abiertos en los que se basan los servicios Web. Una solución BizTalk puedeconsumir los servicios Web actuales y exponer los procesos de negocio (orquestaciones deBizTalk) como servicios Web. BizTalk se posiciona como la capa de gestión que organiza losservicios Web, controlando el flujo y las interacciones entre ellos y agregando los serviciosindividuales dentro de una solución compuesta de nivel superior.BizTalk Server permite también la integración de aplicaciones y sistemas que no soncompatibles con los servicios Web. Mediante el empleo de una gran variedad de adaptadores,BizTalk Server puede hacer que las funcionalidades de sistemas y aplicaciones antiguosqueden disponibles de cara a los procesos internos de las organizaciones.BizTalk Server se integra también con Microsoft Office SharePoint Server. Juntos, BizTalkServer y SharePoint facilitan la creación de soluciones de procesos de negocio “preparadospara las personas” que afectan a los profesionales de la información. SharePoint permite aestos profesionales recopilar y gestionar datos de negocio (mediante la captura de datos enXML, estructurados y no estructurados), aportando la pieza de desktop esencial en el puzle delas soluciones de procesos de negocio. Biztalk Server, en este caso, actúa como el puntocentral de orquestación para los procesos de gran envergadura, que abarcan tanto a sistemasde información como a personas..Microsoft Office SharePoint ServerWindows SharePoint Services 3.0 proporciona servicios Web para interaccionar con casicualquier aspecto de cada servidor, sitio, lista, biblioteca, encuesta o página Web basada enWindows SharePoint Services 3.0. En los procedimientos siguientes se utiliza el servicio WebWebs. El servicio Web Webs proporciona métodos para trabajar con sitios y subsitios deSharePoint. Por ejemplo, puede usar este servicio Web para mostrar y realizar consultas de lostítulos y direcciones URL de todos los sitios contenidos en la colección actual de sitios, de lostítulos y direcciones URL de todos los sitios ubicados directamente debajo del sitio actual, o dela 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 usuariosencilla y consistente, gracias a aplicaciones de cliente muy conocidas y con ello hace que lastareas 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 losprocesos dentro de las organizaciones y a través de ellas. Office SharePoint Server permiteaprovechar las ventajas de los workflows para automatizar y mejorar la visibilidad de lasactividades de negocio más habituales, como son la revisión y aprobación de documentos, elseguimiento de incidencias y la recogida de firmas. Su excelente integración con aplicaciones
  14. 14. muy conocidas de cliente, el correo electrónico y los navegadores Web simplifica la experienciadel usuario. Los usuarios finales pueden definir y modelar con facilidad sus propios procesosaplicando herramientas de Microsoft muy familiares.Office SharePoint Server contribuye a eliminar los procesos manuales de gestión de lainformación, ineficientes en general. Los formularios electrónicos se pueden utilizar pararecoger información que luego se puede integrar en los sistemas de línea de negocio (LOB), enlos archivos documentales, pueden servir para iniciar procesos de workflow o enviarse aservicios Web. Esta automatización permite eliminar las redundancias y errores que afectan ala introducción manual de datos, y garantiza el acceso a datos más exactos y en tiempo real. BIBLIOGRAFIAhttp://translate.google.com.mx/translate?hl=es&langpair=en%7Ces&u=http://en.wikipedia.org/wiki/WS-Securityhttp://vtroger.blogspot.com/2008/09/auditoria-de-seguridad-de-servicios-web.htmlhttps://www.owasp.org/index.php/Proyecto_WebScarab_OWASPhttp://www.blueinfy.com/wsscanner.html

×