Consideraciones de seguridad para servicios web
Cuando configura la seguridad de servicios web, debe realizar todos los esfuerzos necesarios para comprobar que el resultado no es vulnerable a una gran gama de mecanismos de ataque. Existen posibles temas de seguridad que pueden surgir cuando se protegen los servicios web.
En WebSphere Application Server, cuando habilita la integridad, confidencialidad y las señales asociadas contenidas en un mensaje SOAP, no se garantiza la seguridad. Esta lista de temas de seguridad no está completa. Debe realizar su propio análisis de seguridad.
- Comprobar la pureza del mensaje La pureza del mensaje requiere proteger los recursos de un ataque de reproducción en el que se capta y reenvía un mensaje. Las firmas digitales, por sí mismas, no pueden impedir un ataque de reproducción porque un mensaje firmado se puede capturar y reenviar. Se le recomienda que permite a los destinatarios de mensajes que detecten ataques de reproducción de mensajes cuando intercambien mensajes intercambiados en una red abierta. Puede utilizar los elementos siguientes, que se describen en las especificaciones de la seguridad de servicios web, para este fin:
- Timestamp
- Puede utilizar el elemento de indicación de la hora para realizar un seguimiento de los mensajes y detectar reproducciones de mensajes anteriores. La especificación WS-Security 2004 recomienda que almacene en memoria caché las indicaciones de la hora durante un período de tiempo determinado. Como directriz, puede utilizar cinco minutos como el período mínimo de tiempo para detectar reproducciones. Los menajes que contienen una indicación de la hora caducada se rechazarán.
- Nonce
- Un nonce es un elemento hijo de <UsernameToken> en el perfil UsernameToken. Debido a que cada elemento nonce tiene un valor exclusivo, los destinatarios pueden detectar los ataques de reproducción con relativa facilidad.
Avoid trouble: Para lograr la máxima seguridad de los ataque por reproducción utilizando el requisito de indicación de fecha y hora, deben firmarse los elementos Timestamp y Nonce. De lo contrario, estos elementos se pueden alterar fácilmente y, por lo tanto, no se podrán evitar los ataques de reproducción.gotcha
Para obtener más información sobre la indicación de fecha y hora, consulte Indicación de fecha y hora.
WebSphere Application Server aplica la aserción de política IncludeTimestamp. Sin embargo, muchos proveedores de servicio necesitan ese elemento <wsu:Timestamp> en la solicitud, pero no envían ninguno en la respuesta. También es posible que no exista ninguna cabecera de seguridad en la respuesta y mucho menos una indicación de fecha y hora. Se producirá el error siguiente en un cliente cuando IncludeTimestamp esté en la política pero no se devuelva ninguna indicación de fecha y hora en la respuesta:
Para resolver este problema, configure el proveedor de servicio para que se envíe una indicación de fecha y hora o configure el cliente para que no necesite la indicación de fecha y hora estableciendo la propiedad personalizada com.ibm.wsspi.wssecurity.consumer.timestampRequired en false en los enlaces de política de WS-Security. Para obtener más información, consulte Propiedades personalizadas de seguridad de servicios web.CWWSS5730E: No se ha encontrado una indicación de fecha y hora necesaria.
- Utilizar la firma digital XML y el cifrado XML correctamente evita un agujero de seguridad potencial
La especificación Web Services Security 2004 define cómo utilizar la firma digital XML y el cifrado XML en las cabeceras SOAP. Por lo tanto, los usuarios deben entender la firma digital XML y el cifrado XML dentro del contexto de otros mecanismos de seguridad y sus posibles amenazas a una entidad. Para las firmas digitales XML, debe conocer todas las implicaciones para la seguridad que supone el uso de firmas digitales en general y, en especial, la firma digital XML. Cuando crea confianza en una aplicación basada en la firma digital, debe incorporar otras tecnologías como, por ejemplo, la validación de la confianza de los certificados basada en PKI (Public Key Infrastructure). Para el cifrado XML, la combinación de la firma digital y el cifrado a través de un elemento de datos común tiene cierta vulnerabilidad criptográfica. Po ejemplo, cuando cifra digitalmente los datos firmados, puede dejar la firma digital como texto plano y con lo que el mensaje puede ser vulnerable a ataques en los que se adivine el texto plano. Como método general, cuando cifre datos, cifre cualquier valor de conversión o firma de los datos. Para obtener más información, consulte http://www.w3.org/TR/xmlenc-core/#sec-Sign-with-Encrypt.
- Protección de la integridad de las señales de seguridad
Existe la posibilidad de un ataque en el que se sustituya la señal. En este caso, se verifica una firma digital con una clave que generalmente se deriva de una señal de seguridad y se incluye en un mensaje. Si se sustituye la señal, es posible que un destinatario acepte el mensaje basándose en la clave sustituida, lo que puede no ser lo previsto. Una solución posible a este problema es firmar la señal de seguridad (o los datos de identificación exclusivos de los que se deriva la clave de firmado) junto con los datos firmados. En algunas situaciones, la señal que emite una autoridad de confianza está firmada. En este caso, es posible que no existe ningún problema de integridad. No obstante, debido a que la semántica de las aplicaciones y el entorno puede cambiar con el tiempo, se recomienda impedir este tipo de ataque. Debe evaluar el riesgo basándose en el entorno de despliegue.
- Verificación del certificado para reforzar la verificación de vías de acceso de certificados y la lista de revocación de certificados
Se le recomienda que verifique si la autenticidad o la validez de la identidad de la señal que se utiliza para firmas digitales tiene la confianza correcta. Especialmente para una señal X.509, ya que esta señal requiere que se verifique la vía de acceso al certificado mediante una lista de revocación de certificados, una CRL. En la implementación de la seguridad de servicios web de WebSphere Application Server Versión 6 y posterior, el certificado se verifica mediante el elemento <TokenConsumer>. WebSphere Application Server proporciona una implementación predeterminada para el certificado X.509 que utiliza la biblioteca Java™ CertPath para verificar y validar el certificado. En la implementación, no hay ningún concepto explícito de una CRL. sino que los certificados raíz y los certificados intermedios se preparan únicamente en archivos. Para una solución sofisticada, puede desarrollar su propia implementación TokenConsumer que realiza la verificación del certificado y de la CRL utilizando la base de datos CRL en línea u OCSP (Online Certificate Status Protocol).
- Protección de la señal username con una contraseña
Se le recomienda que no envíe una contraseña con un nombre de usuario a un servidor en sentido descendente sin protección. Puede utilizar la seguridad de nivel de transporte como SSL (por ejemplo HTTPS) o utilizar el cifrado XML de la seguridad de servicios web para proteger la contraseña. El método de protección preferido depende del entorno. No obstante, puede enviar una contraseña a un servidor en sentido descendente como texto plano en algunos entornos especiales en los que está prácticamente seguro de que no existe ninguna vulnerabilidad a los ataques.
La protección de los servicios web requiere más trabajo que simplemente habilitar la firma digital XML y el cifrado XML. Para proteger correctamente un servicio web, debe conocer PKI. El tipo de seguridad que necesite dependerá del entorno desplegado y de los patrones de uso. No obstante, hay algunas reglas básicas y métodos recomendados para proteger los servicios web. Se le recomienda que lea algunos manuales sobre PKI y también la información sobre WS-I (Web Services Interoperability Organization) y BSP (Basic Security Profile).