Seguridad en WebServices

ESPECIALIZACIÓN EN SEGURIDAD INFORMÁTICA FUNDAMENTOS DE LA SEGURIDAD INFORMÁTICA

Prof. Reinaldo Mayol Arnao, Ph.D.

UNIVERSIDAD PONTIFICIA BOLIVARIANA SISTEMA DE FORMACIÓN AVANZADA

MEDELLÍN 2015

Guía para Asegurar Servicios Web NIST SP 800-95

"World wide web" by Svilen.milev - Own work. Licensed under CC BY-SA 3.0 via Wikimedia Commons - http://commons.wikimedia.org/wiki/File:World_wide_web.jpg#mediaviewer/File:World_wide_web.jpg

ESPECIALIZACIÓN EN SEGURIDAD INFORMÁTICA FUNDAMENTOS DE LA SEGURIDAD INFORMÁTICA

INTEGRANTES Laura Valderrama Luisa Castañeda Andrés Jaramillo

Iván Santa

UNIVERSIDAD PONTIFICIA BOLIVARIANA SISTEMA DE FORMACIÓN AVANZADA

MEDELLÍN 2015

"World wide web" by Svilen.milev - Own work. Licensed under CC BY-SA 3.0 via Wikimedia Commons - http://commons.wikimedia.org/wiki/File:World_wide_web.jpg#mediaviewer/File:World_wide_web.jpg

Servicios Web y su relación con Seguridad 1 Fucionalidades de seguridad de Servicios Web y Tecnologías Relacionadas 2

Human User´s Entry Point Into A Soa: Web Portals 3

Secure Web Service-enablig of Legacy Applications 4

Guía para Servicios Web Seguros Agenda

Implementación segura de herramientas y tecnologías 5

Apéndices 6

Servicios Web y su relación con Seguridad 1

Guía para Servicios Web Seguros

Servicios Web y su relación con Seguridad Introducción a Servicios Web

SOA: Arquitectura Orientada a Servicios Servicio Web: Tecnología que puede ser usada para implementar SOA SOAP: Uno de los protocolos SOA, define como son las solicitudes y las respuestas. XML: Lenguaje en que se estructura los mensajes SOAP. WSDL: Define el formato de cada mensaje SOAP, permitiendo enlace dinámico. UDDI: Estándar de descubrimiento, permite que los servicios web se busquen unos a otros dinámicamente

Servicios Web y su relación con Seguridad Introducción a los Servicios Web

Descubrimiento

Orden Comida

Cocinero Jefe

Mesera

MENÚ Cocineros

Administrador

Lenguaje en Común : Español

Ejemplo

Figura 1. Ejemplo de servicios en la vida real. Autores


Descubrimiento

Solicitud SOAP

Respuesta SOAP

UDDI

WSDL

Servicio Web

Solicitante

Servicio Web Intermediario

Servicio Web Orquestador Servicio

Web Proveedor 2

Servicio Web Proveedor 3

Lenguaje en común: XML

Coreografía

Portal Web

Servicio Web

Proveedor 1

Figura 2. .Componentes y roles, SOA con servicios Web. Autores


¿Cómo podemos verlo mejor? Vamos a “consumir” un Servicio Web que contiene información sobre el pasado mundial de fútbol.

Figura 3. Toma de pantalla de Webservice FOOTBALPOOL. http://footballpool.dataaccess.eu/en/About/Web-Services-137

Servicios Web y su relación con Seguridad Elementos de Seguridad

•  Identificación y autenticación •  Autorización •  Integridad •  No Repudio •  Confidencialidad •  Privacidad

Servicios Web y su relación con Seguridad Dimensiones de Seguridad

•  Mensajería Segura •  HTTPS •  Cifrado XML y firmado XML •  WS-Security

•  Protección de Recursos •  Negociación de Contratos •  Relaciones de confianza •  Requerimientos para software seguro

Servicios Web y su relación con Seguridad Conociendo los Requerimientos

Est

ánda

res

de S

egur

idad

Figura 4. Estándares de seguridad en servicios Web. SINGHAL, Anoop, et al. Guide to Secure Web Services. NIST. 2007

Servicios Web y su relación con Seguridad Dimensiones, requerimientos y Especificaciones

Figura 5. Especificaciones y estándares dirigidos a seguridad de SOAs SINGHAL, Anoop, et al. Guide to Secure Web Services. NIST. 2007

Servicios Web y su relación con Seguridad Dimensiones, requerimientos y Especificaciones

Figura 6. Especificaciones y estándares dirigidos a seguridad de SOAs SINGHAL, Anoop, et al. Guide to Secure Web Services. NIST. 2007

Servicios Web y su relación con Seguridad Riesgos Comunes y estándares que los enfrentan

Figura 7. Amenazas controladas por estándares de web services actuales SINGHAL, Anoop, et al. Guide to Secure Web Services. NIST. 2007

Fucionalidades de seguridad de Servicios Web y Tecnologías Rleacionadas 2


Fucionalidades de seguridad de Servicios Web y Tecnologías Rleacionadas

Authentication Service-to-Service

La autenticación es requerida para limitar el acceso a los recursos, las autenticaciones se pueden realizar empleando varios métodos como son entregar Tokens en una conexión http, o pasar certificados SSL/TTS, o pasando Tokens junto con la solicitud SOAP. Los Token de autenticación se realizan generalmente mediante el estándar OASIS WS-Security, el cual permite varios métodos de autenticación como son: usernames, X.509 PKI certificates, Kerberos tickets, o SAML assertions


Service Chaining

A veces, un proveedor de servicios puede no ser capaz de realizar las acciones que un usuario o solicitante desea que éste realice, pero sabe de un servicio Web remoto que si puede. El proveedor de servicios puede invocar otro servicio a distancia para satisfacer la petición del solicitante, que se conoce como encadenamiento de servicios. El proveedor de servicios puede usar una aserción SAML, un mensaje WS-Security o ambos para asegurar la confianza entre los los WS.


WS-Security for Authentication

Muchos servicios Web se basan en los mecanismos de autenticación proporcionadas por HTTP y SSL / TLS. Si un mensaje SOAP viaja entre varios puntos finales SOAP antes de llegar a su destino, no es aceptable que dependa de HTTP y SSL / TLS para la autenticación, confidencialidad e integridad. WS-Security también proporciona mecanismos para el cifrado y la firma de elementos de un mensaje SOAP, incluyendo cualquier tokens WS-Security.


Identity Management Architectures

Hay 3 grandes arquitecturas de identidad disponibles para usar en los WS • Isolated identity management.

• Federated identity management.

• Centralized identity management.

Laws of Identity En mayo de 2005, Kim Cameron, fue el autor de Las Leyes de la identidad.


Establishing Trust between Services

En una SOA, los servicios Web deben ser capaces de confiar entre sí, sin necesidad de una amplia reestructuración del entorno de confianza. Liberty Alliance proporciona aplicaciones Web y asociación de servicios web utilizando SAML.


Liberty Alliance and WS-Trust.

Estos estándares ofrecen características y funcionalidades similares utilizando diferentes técnicas y han sido diseñados con diferentes objetivos en mente. La determinación de qué marco es el mejor para una organización en particular depende en gran medida de lo que está desplegado y en las metas de arquitectura de la organización.


Liberty Alliance

El Liberty Alliance tiene como objetivo desarrollar un marco de alianza de identidades basada en estándares adecuados para las empresas y los gobiernos. Liberty Alliance ha definido el marco de servicios web de identidad, que define cómo los servicios Web pueden interactuar en nombre de un usuario mediante el uso adecuado de SAML mediante la definición de varios servicios, entre ellos los siguientes:


Liberty Alliance (2)

Discovery Services: Permitir a los servicios web buscar dinámicamente proveedores de identidad Interaction Services: Proporcionar un mecanismo para obtener permiso y así poder realizar varias acciones Data Services: Proporcionar la funcionalidad del servicio Web que se utilizará en nombre del principal Identity Services: Proporciona acceso a información del principal que no es posible con aserciones SAML


WS-Federation and WS-Trust

WS-Federation y WS-Trust fueron desarrollados por IBM, Microsoft, RSA, Verisign, BEA, y varios otros proveedores para crear un sistema de alianza de identidades basada en extensiones de WS-Security que utiliza los protocolos de servicios Web básicos: SOAP y WSDL. WS-Trust se utiliza para intercambiar señales de confianza entre los servicios Web. WS-Trust es una extensión WS-security que proporciona métodos para expedir, renovar, y validar los tokens de seguridad.


SAML

SAML (Security Assertions Markup Language) es un entorno basado en XML para servicios Web, permite el intercambio de información de autorización y autenticación entre diferentes sitios Web. SAML es flexible y extensible y está diseñado para ser utilizado por otros estándares. Integra protocolos y entornos de mensajería ya presentes en la industria, como XML Signature, XML Encryption y SOAP. Entre las ventajas que aporta SAML una de las mas importantes es “single sign-on” Consiste en que los usuarios se autentifiquen en un proveedor de identidad “sitio web” y después tengan acceso a servicios/recursos en los proveedores de servicio sin autentificación adicional.


Security SAML

Es importante reconocer que una vez que una aserción SAML se ha emitido, no es posible controlar su difusión. Una entidad que recibe una aserción SAML puede dárselo a otras entidades, potencialmente maliciosos como parte del sistema. Hay una serie de técnicas que pueden mitigar esta amenaza, incluyendo: •  Cifrado de la aserción, para impedir a un tercero vea lo que se está tratando de enviar. •  La firma de todo el mensaje, utilizando WS-Security en una respuesta de SOAP o SSL / TLS en una respuesta HTTP. De esta manera, un atacante debe reenviar el mensaje completo para tener éxito. •  La aplicación de los períodos de validez, esto reducirá al mínimo la cantidad de tiempo durante el cual un atacante puede ejecutar con éxito un ataque de repetición.


Audit in the SOA Environment

La mayoría de los servidores COTS web incluyen un servicio de registro de auditoría o de eventos de seguridad. Los datos de registro de eventos de auditoría / seguridad deben ser almacenados de forma segura para evitar la manipulación no autorizada o la divulgación de los datos de registro. NIST SP 800-9250 proporciona orientación sobre la gestión de los registros de seguridad en toda la organización. Si bien esta guía no es específico para SOA, muchos de los conceptos introducidos en la guía se puede aplicar a los servicios Web.

Fucionalidades de seguridad de Servicios Web y Tecnologías Rleacionadas Availability of Web Services

Para lograr la disponibilidad, un servicio Web no sólo debe ser diseñada e implementada para lograr calidad de servicio y fiabilidad, sino también para: •  Reconocer y reaccionar a los patrones de ataque asociados con DoS. •  Cuando ya no es posible mantener el servicio arriba, limitar y aislar los WS afectados. Esto significa que el ataque DoS no se propaguen más allá del punto en el que se detectaron por primera vez por el servicio Web. •  Recuperar y reanudar el funcionamiento seguro tan pronto como sea posible después de una denegación de servicio. •  Si el ataque DoS se vuelve demasiado persistente, o su propagación no se puede prevenir, todo el servicio web debe cerrar de forma segura. A menos que un servicio sea de misión crítica definida por el reglamento de la organización, nunca se debe permitir que continúen operando sin funciones de seguridad totalmente operativos y de auto-protección.


Non-Repudiation of Web Service Transactions

WS-Security proporciona servicios de no repudio a través de su uso del estándar XML Signature. Las firmas digitales pueden proporcionar el nivel necesario de garantía exigido por el no repudio. A través de cifrado asimétrico, cada servicio Web tiene una clave única que se puede utilizar para firmar elementos de SOAP.

Fucionalidades de seguridad de Servicios Web y Tecnologías Rleacionadas Availability of Web Services

Existe una estrecha relación entre la disponibilidad, calidad de servicio y confiabilidad, es necesario implementar políticas de QoS. Entre las políticas de QoS que se deben tener en cuenta están: •  El servicio web seguirá funcionando correctamente y de manera previsible así se tenga un ataque DoS que no va dirigido al WS directamente siempre y cuando no se vea afectado por daños colaterales.

•  Si el servicio Web no puede evitar su defecto, no se dejará en un estado de inseguridad (es decir, su fracaso no dejará el servicio mismo, sus datos, o su entorno vulnerable a ser comprometida, subvertida o explotada para comprometer algo más) a menos que por política de la organización se requiera el servicio para seguir operando.

Human User´s Entry Point Into A SOA: Web Portals 3


Human User´s entry point into A SOA: Web Portals

Intro

Who is sending this message? Is the authen1cated subject

en1tled to access?

Can it be proved that this transac1on occurred?

Was the message, or the system,

tampered with?

Can the informa1on be read while it is in transit? In storage?

Can personally iden1fiable

informa1on be released to the public?

Is it vulnerable to a denial of service a?ack (brute force or

otherwise)?

Can it be proven that the sender and the recipient did in fact send

and receive the message?

How easy is it to apply or change a security policy rule or

configura1on parameter?

Figura 8. Interacciones entre Servicios Web. MIR, Hasan. https://www.youtube.com/watch?v=jL1oVENiYT8

Human User´s entry point into A SOA: Web Portals

Proxy Agents

Figura 9. Amenazas controladas por estándares de web services actuales SINGHAL, Anoop, et al. Guide to Secure Web Services. NIST. 2007

Secure Web Service-enablig of Legacy Applications 4


Secure Web Service-enablig of Legacy Applications

Intro

Au t h e n1 c a 1on , authoriza1on and access control are need to migrate a legacy applica1on to a Web service architecture


Legacy Authentication

IPsec or SSL/TLS

AUTHENTICATION

WS-‐SECURITY OWN PROPIERTY AUTHENTICATION

SSO(IDEALLY)

Figura 11. .Legacy Authentication. Autores


Autorization And Access Control

Figura 12. .Authorization and access control. Autores


Autorization And Access Control (2)

•  Perform only the ac1ons explicitly defined •  Strictly enforce the processing order defined

•  Call only those other processes and libraries absolutely needed to invoke •  Execute only one task at a 1me

•  Ini1ate a new task only aTer the previous task has completed •  Access only data absolutely needed to successfully perform tasks.

SEPARATION: DUTIES, ROLES AND PRIVILEGES NO RETAIN PRIVILEGES



Autorization And Access Control (3)

SOAP messages PKI Cer1ficates

Legacy Applica1ons

Rely on

Authentication

Transition: APPI

USERNAME PASSWORDS

Cer1ficates (privileges)

Migrate

Requests Data

SECURITY OF THE APPLICATION

SECURITY DATABASE

Filter

Rely on



Integrity of Data

•  End-‐to-‐end user authen1ca1on •  End-‐to-‐end encrypted data channel •  Public Key security end-‐to-‐end

Risk enviroments Sta1c Passwords

Dynamic Passwords Biometric

Figura 15. .Integrity of Data. Autores

Implementación segura de herramientas y tecnologías 5


Al implementar un servicio web seguro, los desarrolladores deben ser conscientes de cómo utilizar las herramientas de desarrollo, técnicas y lenguajes disponibles de una manera segura, ya que la funcionalidad de seguridad puede verse comprometida por software mal implementado.

Implementación segura de herramientas y tecnologías

Intro

•  El aspecto más importante de un conjunto de herramientas de desarrollo de servicios Web es su capacidad para interoperar con servicios web desarrollados utilizando otras herramientas.

•  Las especificaciones de SOAP y WSDL dejaron algunas opciones de diseño individuales para los conjuntos de herramientas de desarrollo de servicios web haciéndolos menos interoperables. En particular, los servicios web Java y .NET por defecto pueden no estar habilitados para comunicarse con otros servicios web. Con este fin, WS-I desarrolló WS-I Basic Profile 1.1, que especifica exactamente cómo deberían aplicarse las especificaciones WSDL y SOAP para lograr la plena interoperabilidad


Juego de herramientas para el desarrollo de servicios web

Un analizador XML mal configurado es susceptible a varios ataques: •  Grandes documentos XML pueden sobrecargar el

analizador XML y conducir a una denegación de servicio.

•  Los documentos XML pueden configurarse para referirse y utilizar los archivos locales. Esto puede llevar a un atacante a obtener conocimiento sobre el sistema local.


Analizadores XML

• C y C++ • Java • Microsoft’s .NET languages: C#

and VB.NET • XML


Procedural languages

Las pruebas de seguridad en el ámbito de los servicios Web deben ser incluidas en el plan de pruebas en general, y se debe realizar de forma iterativa a lo largo del ciclo de vida del servicio Web, no sólo después de la aplicación o implementación. Categorías: •  Web service Security Protocol Conformance Testing. •  Correctness Testing of web service security

Functionality. •  Security Focused Unit Testing. •  Whole aplication Vulnerability Assessment. •  Web Services Software Security Assessment.


Pruebas de seguridad: Herramientas y Técnicas

Electronic Business using eXtensible Markup Language Fue desarrollado en 1999 por el Centro de las Naciones Unidas para la Facilitación del Comercio Electrónico (UN / CEFACT) y OASIS. Al igual que los servicios Web, ebXML fue diseñado para utilizar las normas existentes para permitir mult iplataforma y transacciones interoperables de negocio a negocio. El objetivo de ebXML es triunfar en el Intercambio Electrónico de Datos.


ebXML

•  Privilege Escalation Attacks. •  Diccionary attack. •  Buffer Overflow Exploits.

ü  Safe programming. ü  Memory allocation countermeasures. ü  Compiler-Based countermeasures.

•  Symlink Attacks. •  Explotating Unprotected Administrator Interfaces.

ü Incorrectly configured access control security levels. ü Incorrectly configured SSL security levels. ü Autentication of administrators. ü Internal, informative application error messages returned to users.

•  Attacks on Confidentiality. •  Sniffing.


Ataques Comunes


Attacks

DENIAL OF SERVICE ATTACK Flooding Attack COMAND INJECTION


Attacks (2)

MALICIOUS CODE ATTACKS

•  COMAND INJECTION •  LOGIC BOMBS, TRAPDOORS, AND

BACKDOORS

Preguntas


¡ GRACIAS !


Seguridad en WebServices

Documents

Transcript of Seguridad en WebServices