Seguridad

Siguiendo el modelo W3C, vamos a realizar un pequeño estudio sobre los requisitos de seguridad que se encuentran enumerados dentro de la arquitectura de referencia de los servicios web y señalando las diferentes tentativas de ataque que también aparecen dentro de la especificación. Se ofrecerán soluciones para las mismas.

Servicios de seguridad básicos

La seguridad es un concepto considerado clave dentro de los que comprenden el aseguramiento de calidad dentro del servicio Web. Si se realiza una catalogación básica de los servicios de seguridad son la confidencialidad, integridad, autenticidad de origen, no repudio y control de acceso. A continuación se explica brevemente cada uno de ellos:

Autenticación de los participantes. Los servicios Web por definición tienen mucha heterogeneidad, lo que provoca que los sistema de autenticación tengan que ser flexibles. Si imaginamos un servicio Web que necesita comunicarse con otro servicio, este podría solicitar al demandante credenciales junto a una demostración de que es el propietario de las mismas. Resulta necesario conseguir un estandarización de los protocolos y en los formatos a utilizar. Otro problema remanente es definir un modelo de autenticación Single Sign-On de forma que un servicio que necesita comunicarse con otros servicios Web,no tenga la necesidad de estar continuamente autenticándose y logre completar el proceso de negocio en un tiempo de respuesta aceptable.

Autorización. Con frecuencia , es necesario aplicar unos criterios que permitan controlar el acceso a los diferentes recursos. Es necesario definir los usuarios que pueden realizar diversas acciones sobre los diferentes recursos. En combinación con la autenticación, permite a las identidades conocidas realizar las acciones para las que tienen permisos. Con frecuencia se definen políticas de acceso en base a jerarquías.

Confidencialidad. Es necesario asegurar que el contenido incluido en los mensajes que se intercambian se mantiene como información confidencial. Es muy habitual emplear técnicas de cifrado, ya muy extendidas. Obviamente, la confidencialidad del mensaje va más allá que el canal por el que es transmitido.

Integridad. Esta propiedad garantiza que la información que se ha recibido , es exactamente la misma que se envió desde el cliente.

No repudio. En una comunicación que se realizan transacciones, es necesario registrar que las mismas se han producido y registrar el autor que lo ejecutó. En el caso de los servicios Web, trasladamos esta política la uso del servicio. Se comprueba que cierto cliente hizo uso de un servicio a pesar de que éste lo niegue (no repudio del solicitante) así como probar la ejecución se llevó a cabo (no repudio del receptor).

Disponibilidad. Uno de los ataques mas frecuentes a las aplicaciones se basa en la denegación de servicios. Se lanzan múltiples solicitudes falsas para inundar el servicio y provocar su caída. Es necesario contemplar la disponibilidad, como punto muy importante en el diseño de servicio web, ya que permiten cierta redundancia de los sistemas.

Auditabilidad. El registro de las acciones en los servicios Web permite mantener una traza de las mismas de manera que se puedan realizar análisis posteriores de los datos.

Seguridad extremo-a-extremo. Cuando se ejecuta un servicio es necesario garantizar la seguridad durante todo el recorrido que efectúan los mensajes. Dado que normalmente existen routers como intermediarios de la comunicación, esto provoca un aumento de la política de seguridad que garantice que se realiza el transporte de forma segura y confirme la seguridad de los intermediarios. Es importante disponer de un contexto de seguridad único y que incluya el canal de comunicación. Para conseguirlo, es necesario aplicar diversas operaciones de carácter criptográfico sobre la información en el origen. De esta manera se evita una dependencia con la seguridad que se configure por debajo de la capa de aplicación y se garantiza los servicios de seguridad

Requisitos de Seguridad

Si realizamos una abstracción sobre la problemática, el objetivo principal es conseguir un entorno para las transacciones y los procesos que sea seguro para todo el canal de comunicación. Obviamente, es necesario garantizar la seguridad durante el tránsito de la comunicación, ya sea con intermediarios o sin ellos durante la misma. Pro otra parte, se necesita asegurar la seguridad de la información en los procesos de almacenamiento: A continuación se ofrece una revisión breve de los principales requisitos para asegurar la seguridad en la comunicación.

Mecanismos de autenticación

La autenticación es obligatoria para mantener control y verificar la identidad de solicitantes y proveedores. En algunas ocasiones, resultará necesario realizar una autenticación tanto del solicitante como del proveedor, ya que puede producirse que los participantes no estén en conexión directa. Pueden existir intermediarios que retransmitan la comunicación
En función de la política de seguridad que se adopte, será necesario autenticar tanto al proveedor como al solicitante o simplemente a alguno de ellos. Se pueden emplear métodos basados en contraseñas, certificados , etc.. para formalizar la autenticación. Si se basan en contraseñas, es necesario aplicar una política que aporte robustez a las mismas.

Se pueden emplear mecanismos basados en protocolos de transporte como el Http Autentication y SSL/TLS X509 Certificate. Estos mecanismos sólo son válidos cuando existe una conexión directa entre el consumidor y el proveedor de servicio, ya que si un mensaje SOAP viaja entre varios endpoints antes de llegar a su destino, las credenciales del consumidor original se pierden en el primer endpoint.
También se pueden emplear mecanismos basados en tokens que se incluye dentro del mensaje. El estándar WS-Security incorpora un gran número de tokens que pueden ser empleados en este caso; Username Token, X509 Certificate, SAML assertions, etc. Este mecanismo de autenticación no tiene los problemas de los mecanismos basados en el transporte, ya que las credenciales pueden viajar entre los distintos endpoints hasta llegar a su destino. Si usamos este mecanismo, es necesario que estos sean transmitidos de forma segura para evitar ataques de replay. Esto puede se consigue mediante la firma del token dentro del mensaje SOAP, junto a un TimeStamp o IDMessage, por lo que se recomienda incluir en la firma la cabecera de WS-Addressing. En entornos cerrados también se puede emplear SSL para transmitir los mensajes con Tokens de forma segura, aunque esta aproximación es menos segura que la anterior.

Autorización

La autorización resulta necesaria para efectuar un control sobre el acceso a los recursos. Una vez se ha realizado la autenticación sobre el participante y se conoce su identidad, se utilizarán los mecanismos de autorización para realizar las comprobaciones pertinentes y asegurar el acceso adecuado al recurso por parte del participante.
Se crean políticas que determinan los privilegios de los participantes. Mediante la gestión de la confianza, se permite la interacción entre un solicitante y un proveedor sin referencias previas pero que atendiendo a las credenciales que se intercambian determinen un nivel de confianza asumible por ambos. De esta manera se permite un proceso de autenticación sin que haya existido la necesidad de desvelar las identidades de los participantes en el proceso

Integridad y confidencialidad de los datos

El proceso que mantiene la integridad de los datos, garantiza que la información que se ha enviada no ha sufrido ninguna transformación sin que se haya detectado. La confidencialidad, asegura los principios de intimidad de la información. Es decir solo se permite el acceso a la información a aquellos participantes con permisos para hacerlo. Con frecuencia, se usan técnicas de cifrado para conceptos de confidencialidad y la firma digital para temas de integridad.

No repudio

El objeto de las técnicas de no repudio ya se han comentado anteriormente, es registrar la participación y el grado de la misma de los diferentes interlocutores en una transacción para protegerlo de una posible denegación, posiblemente por parte de algún interlocutor de la misma, negando de que la transacción ocurrió o de su participación en la misma.
Las técnicas de no repudio permiten proporcionar evidencias sobre lo sucedido en la transacción, de manera que una tercera parte resuelve el desacuerdo producido.
Para garantizar el no repudio dentro de las comunicaciones por Servicios Webs, los mensajes SOAPs intercambiados deberán ser identificados de forma única mediante el uso de la especificación WS-Addressing. Los mensajes SOAP junto a sus cabeceras "relevantes", deberán ser firmadas según los procedimientos recogidos en la especificación WS-Security. Por último, los mensajes deberán ser almacenados en ficheros de logs, para su posterior consulta.

Rastreabilidad

Es necesario ajustar trazas que aseguren poder conocer información del acceso una vez se haya producido este, y comprobar el comportamiento que ha tenido el usuario que ha realizado el acceso. Son de especial importancia para verificar la integridad del sistema. Normalmente las trazas las generen los determinados "agentes de auditoria" que pueden realizar monitoreo, observar recursos y el comportamiento de otros agentes, y validar el cumplimiento de las políticas establecidas. Con frecuencia , no es posible prevenir la violación de las diferentes obligaciones pero si un agente de auditoria detecta una brecha podría activar un plan de repulsa o determinar otro tipo de actividades.

Aplicación distribuida de las políticas de seguridad

Si se han definido arquitecturas que están basadas en Servicios Web, están deben permitir la definición de políticas de seguridad y comprobar su cumplimiento en las diversas plataformas y con las diversas variaciones de acceso al servicio.

Uso de políticas

Los mensajes que se envían en la comunicación de los servicios Web atraviesan los cortafuegos y pueden ser modificados a través de los diferentes puertos y protocolos existentes. Es necesario, para asegurar la calidad de seguridad en los servicios Web, crear políticas corporativas para integrarse con las diversas políticas de los proveedores y con la gestión de la confianza planificada.

Políticas distribuidas

Con frecuencia, se asocian las políticas de seguridad a los proveedores o a los clientes o a un mecanismo de descubrimiento. Se utilizan para controlar y definir la metodología de acceso de las peticiones y las respuestas a las mismas, dadas por los involucrados en la comunicación. Estas políticas son validadas en ejecución dentro del contexto de la comunicación. Cada parte involucrada debe realizar la validación de sus políticas.

Políticas de confianza

Defiendo de manera simple una política de confianza como una política distribuida que asegura a dos entidades que afrontan una interacción sin conocerse previamente. Mediante el uso de credenciales, asumen el nivel de seguridad que pueden soportar. En ocasiones, la definición de estas políticas implica a terceras entidades de forma recursiva, que influyen en la decisión. Un ejemplo, "yo confió en esta entidad, si mis dos compañeros confían en ti y tu confías en mis dos compañeros"

Mecanismo de Descubrimiento Seguro

El mecanismo de descubrimiento seguro controla las publicaciones y apariciones de un servicio. Cuando aparece un servicio, es necesario realizar una evaluación de las políticas de publicación del servicio, exceptuando las situaciones que supongan un servicio de descubrimiento entre nodos. Si el descubrimiento lo realiza un cliente, puede dotar de identidad o no dársela al servicio. En esta segunda situación hablamos de un descubrimiento anónimo.

Confianza y Descubrimiento

Si imaginamos una situación donde un cliente descubre que existe un servicio Web muy necesario para él, y el proveedor del mismo, es una entidad desconocida hay que preguntarse que nivel de confianza puede otorgar el solicitante a ese servicio. Esta situación es especialmente importante en el caso que se este manejando información muy sensible, ya que se esta corrigiendo un riesgo grave.

Privacidad

La privacidad se expresa mediante las diferentes políticas definidas por los diferentes propietarios de los datos. Con frecuencia, los propietarios son los usuarios de los servicios Web. Es necesario asegurar que los privilegios y derechos de los usuarios son respetados

Fiabilidad de los servicios Web

La aparición de errores es inevitable, especialmente si consideramos que el contexto engloba a multitud de servicios interconectados por una red global que pertenecen a todo tipo de personas y entidades. La eliminación de errores no puede ser completa, así que el objetivo principal es reducir la tasa de errores que aparecen al nivel máximo posible.
Si hablamos de fiabilidad dentro de los servicios Web, podemos realizar una clasificación en función de la predecibilidad y la fiabilidad de:

Los servicios de la infraestructura, como un mecanismo de transporte de los mensajes o un servicio de descubrimiento.
Las interacciones entre los servicios.
El comportamiento individual del solicitante y del proveedor.

Amenazas de seguridad

Si analizamos el concepto de amenaza de seguridad, tendemos a asumir que existirá un intento de acceso y mal uso de los servicios. Por lo tanto hay que realizar un esfuerzo para controlar los accesos no permitidos. Si realizamos una clasificación de las principales amenazas, tenemos lo siguiente:

Acceso no permitido llevado a cabo por entidades sin identificar. Es necesario poder identificar de forma confiable la identidad de proveedores, servicios, etc...

Alteración de la información en el canal de comunicación. Es necesario garantizar la integridad de la información que se envía.

Debe asegurarse el acceso a la información. Solo pueden acceder las partes deseadas. Debe de mantenerse una certeza del contenido y de que la comunicación tuvo lugar.

El acceso inapropiado a los recursos. Debería ser posible garantizar que los recursos y las acciones no son accesibles por aquellas partes que no están autorizadas. De nuevo, este hecho se podría extender al mero conocimiento de que cierto recurso existe, es decir, de alguna forma se debería poder impedir que personas no autorizadas no puedan conocer la existencia de ciertos recursos o ciertos servicios.

Denegación de servicio. No debería ser posible que los clientes de los servicios no puedan acceder a él.

Tipos de ataques

Los tipos de ataques que se listan a continuación están extraídos de la especificación W3C.

Alteración de los mensajes

Es un tipo de ataque centrado sobre la integridad de los mensajes. Se busca modificar el contenido del mensaje (ya sea parcialmente o totalmente). En el caso que el atacante tuviera controlado un canal de comunicaciones entre servicios podría modificar los mismos, eliminarlos, capturarlos y reenviarlos.
La integridad de los mensajes se proporciona mediante la firma digital del fichero XML junto con tokens de seguridad para asegurar que el mensaje es transmitido sin modificaciones. El mecanismo de integridad está diseñado para soportar múltiples firmas por diferentes actores y se puede extender para soportar nuevos mecanismo de firma. Integrando XMLSignature, según lo establecido por la especificación WS-Security se minimiza la repercusión de estos ataques.

Ataques a la confidencialidad

Centrados en la captación de la información contenida dentro de los mensajes. En ocasiones puede existir información muy sensible (datos médicos, datos económicos, etc...)

Hombre en el medio o ‘man- in-the-middle.

Es la infiltración por parte de un atacante entre los participantes de una comunicación. Normalmente, intercepta la comunicación y suplanta a los participantes de manera que estos creen que se comunican entre si cuando lo hacen con el atacante.
La posibilidad de un ataque de intermediario sigue siendo un problema potencial de seguridad serio, incluso para muchos sistemas criptográficos basados en clave pública. Existen varios tipos de defensa contra estos ataques que emplean técnicas de autenticación basadas en:

Claves públicas
Autenticación mutua fuerte
Claves secretas (secretos con alta entropía)
Passwords (secretos con baja entropía)
Otros criterios, como el reconocimiento de voz u otras características biométricas

La integridad de las claves públicas debe asegurarse de alguna manera, pero éstas no exigen ser secretas, mientras que los passwords y las claves de secreto compartido tienen el requerimiento adicional de la confidencialidad. Las claves públicas pueden ser verificadas por una autoridad de certificación (CA), cuya clave pública sea distribuida a través de un canal seguro (por ejemplo, integrada en el navegador web o en la instalación del sistema operativo).

Suplantación de identidad (Spoofing)

Es un ataque orientado a los niveles de confianza que se establecen en la comunicación. El atacante suplanta la identidad de uno de los participantes en una relación de confianza, usualmente trata de comprometer al destinatario de la comunicación. Es muy útil utilizar una robusta autenticación para fortalecer el servicio ante estos ataques.
Para evitar ataques de spoofing exitosos contra nuestros sistemas podemos tomar diferentes medidas preventivas; en primer lugar, parece evidente que una gran ayuda es reforzar la secuencia de predicción de números de secuencia TCP. Otra medida sencilla es eliminar las relaciones de confianza basadas en la dirección IP o el nombre de las máquinas, sustituyéndolas por relaciones basadas en claves criptográficas; el cifrado y el filtrado de las conexiones que pueden aceptar nuestras máquinas también son unas medidas de seguridad importantes de cara a evitar el spoofing.

Denegación de servicio

El objetivo es mantener un servicio activo para que los usuarios legítimos puedan acceder a él. Los ataques se centran en destruir la disponibilidad de un servicio. Su objetivo es interrumpir las operaciones de un servicio dejándolo desconectado.
Es necesario adaptar la configuración del servidor a las necesidades de autenticación, seguir recomendaciones con respecto al tamaño de mensajes aceptadas, controlar la distribución de mensajes para minimizar este tipo de ataques.

Ataque de repetición

En este caso un atacante es capaz de interceptar un mensaje válido pudiendo reenviarlo más tarde todas las veces que quiera al servicio para el que era destinatario. Para poder solventar este problema se deben utilizar técnicas de autenticación apropiadas conjuntamente con técnicas de sellado de tiempos y números de secuencia.

Interoperabilidad

La interoperabilidad entre los servicio web de ASP.NET y los servicio web de Windows Communication Foundation (WCF) se puede lograr asegurando que los servicios implementados usen ambas tecnologías de acuerdo con la especificación WS-I Basic Profile 1.1. Los servicio web de ASP.NET que cumplen con WS-I Basic Profile 1.1 son interoperables con clientes de WCF mediante el uso de enlace proporcionado por el sistema de WCF, BasicHttpBinding.

Utilice la opción de ASP.NET 2.0 de agregar los atributos WebService y WebMethodAttribute a una interfaz en lugar de a una clase y escribir una clase para implementar la interfaz, como se muestra en el siguiente código de ejemplo.

[WebService]
public interface IEcho
{
    [WebMethod]
    string Echo(string input);
}

public class Service : IEcho
{

   public string Echo(string input)
   {
        return input;
    }
}

El uso de esta opción es preferible, porque la interfaz con el atributo WebService constituye un contrato para las operaciones realizadas por el servicio, que puede reutilizarse con diferentes clases que podrían implementar ese mismo contrato de distintas maneras.
Evite usar el atributo SoapDocumentServiceAttribute para que los mensajes se enruten a métodos en función del nombre completo del elemento de cuerpo del mensaje SOAP en lugar del encabezado HTTP SOAPAction.WCF usa el encabezado HTTP SOAPAction para enrutar mensajes.

El XML en el que XmlSerializer serializa de forma predeterminada un tipo es semánticamente idéntico al XML en el que DataContractSerializer serializa un tipo, dando por hecho que el espacio de nombres para el XML se define explícitamente.Cuando defina un tipo de datos para su uso con los servicios web de ASP.NETy en previsión de que se adoptará WCF, haga lo siguiente:

Defina el tipo mediante las clases de .NET Framework en lugar de mediante el Esquema XML.
Agregue solo SerializableAttribute y XmlRootAttribute a la clase, utilizando el último para definir explícitamente el espacio de nombres del tipo.No agregue atributos adicionales del espacio de nombres System.Xml.Serialization para controlar cómo se traducirá la clase de .NET Framework a XML.
Mediante el uso de este enfoque, debería ser capaz de convertir más adelante las clases .NET en contratos de datos agregando DataContractAttribute y DataMemberAttribute sin modificar significativamente el XML en el que las clases se serializan para la transmisión.Los tipos utilizados en los mensajes por los servicios web de ASP.NET se pueden procesar como contratos de datos a través de aplicaciones WCF, lo que produce, entre otras ventajas, un mejor rendimiento en las aplicaciones WCF.

Evite usar las opciones de autenticación proporcionadas por Internet Information Services (IIS).Los clientes de WCF no las admiten.Si es necesario proteger un servicio, utilice las opciones proporcionadas por WCF, porque estas opciones son robustas y se basan en protocolos estándar.

Repercusión en el rendimiento de la carga de ServiceModel HttpModule

En .NET Framework 3.0, se instaló el HttpModule de WCF en el archivo raíz Web.config, de modo que cada aplicación ASP.NET sea compatible con WCF. Esto puede afectar al rendimiento, por lo que es posible quitar ServiceModel del archivo Web.config, como se muestra en el siguiente ejemplo.

<httpModules>
    <remove name=”ServiceModel” />
<httpModules/>

Fuente de informacion: http://www.desarrolloweb.com/articulos/1640.php

http://www.cyta.com.ar/ta1002/v10n2a3.htm

Programacion WEB

jueves, 30 de abril de 2015

6.3 Seguridad e interoperabilidad