Security considerations for Web services
Overview
Common web services security considerations include...
- Ensuring message freshness
Protect resources from a replay attack in which a message is captured and resent. Digital signatures, by themselves, cannot prevent a replay attack because a signed message can be captured and resent. It is recommended that you allow message recipients to detect message replay attacks when messages are exchanged through an open network. Use the following elements, which are described in the Web services security specifications, for this purpose:
- Timestamp
- Use the timestamp element to keep track of messages and to detect replays of previous messages. The WS-Security 2004 specification recommends that you cache time stamps for a given period of time. As a guideline, we can use five minutes as a minimum period of time to detect replays. Messages that contain an expired timestamp are rejected.
- Nonce
- A nonce is a child element of UsernameToken in the UsernameToken profile. Because each Nonce element has a unique value, recipients can detect replay attacks with relative ease.
Both the time stamp and nonce element must be signed. Otherwise, these elements can be altered easily and therefore cannot prevent replay attacks.
- Using XML digital signature and XML encryption properly to avoid a potential security hole
The WS-Security 2004 specification defines how to use XML digital signature and XML encryption in SOAP headers. Therefore, users must understand XML digital signature and XML encryption in the context of other security mechanisms and their possible threats to an entity.
When you build trust into an application based on a digital signature, incorporate other technologies such as certification trust validation based upon the Public Key Infrastructure (PKI).
For XML encryption, the combination of digital signing and encryption over a common data item might introduce some cryptographic vulnerabilities. For example, when you encrypt digitally signed data, you might leave the digital signature in plain text and leave your message vulnerable to plain text guessing attacks. As a general practice, when data is encrypted, encrypt any digest or signature over the data.
For more information, see...
http://www.w3.org/TR/xmlenc-core/#sec-Sign-with-EncryptYou also might want to look into acquiring an IBM Datapower appliance.
- Protect the integrity of security tokens
In a token substitution attack scenario. Digital signatures are verified with a key derived from a security token and included in a message. In a token substitution attack scenario the valid token is replaced with a fake token.
One solution is to sign the token with the signed data. If the token was issued by a trusted authority, it is a signed token, and token integrity issue are generally not a problem.
- Verify the certificate to leverage the certificate path verification and the certificate revocation list
Verify that the authenticity or validity of the token identity that is used for digital signature is properly trusted. Especially for an X.509 token, this issue involves verifying the certificate path and using a certificate revocation list (CRL). In the Web services security implementation in WAS v6.x, the certificate is verified by the TokenConsumer element. WAS provides a default implementation for the X.509 certificate that uses the Java CertPath library to verify and validate the certificate. In the implementation, there is no explicit concept of a CRL. Rather, proper root certificates and intermediate certificates are prepared in files only.
We can also develop a TokenConsumer implementation that performs certificate and CRL verification using the online CRL database or the Online Certificate Status Protocol (OCSP).
- Protect the username token with a password
Do not send a password in a UsernameToken to a downstream server without protection. Use transport-level security such as SSL (for example, HTTPS) or use XML encryption within Web services security to protect the password. The preferred method of protection depends upon your environment. However, you might be able to send a password to a downstream server as plain text in some special environments where you are positive that you are not vulnerable to an attack.
See also Web Services Interoperability Organization (WS-I) Basic Security Profile (BSP).
IBM is a trademark of the IBM Corporation in the United States, other countries, or both.