Security considerations for web services

There security concerns that arise when we are securing web services.

In WebSphere Application Server, when we enable integrity, confidentiality, and the associated tokens within a SOAP message, security is not guaranteed. This list of security concerns is not complete. We must conduct our own security analysis for the environment.

• Ensuring the message freshness

  Message freshness involves protecting 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. IBM recommends that we 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 the <UsernameToken> element in the UsernameToken profile. Because each nonce element has a unique value, recipients can detect replay attacks with relative ease.

  In order to get the most safety from replay attacks using the Timestamp requirement, both the Timestamp and Nonce elements must be signed. Otherwise, these elements can be altered easily and, therefore, cannot prevent replay attacks.

  For more information about Timestamp, see Time stamp.

  WAS enforces IncludeTimestamp policy assertion. However, many service providers require that <wsu:Timestamp> element in the request, but do not send one in the response. There could also be no Security header in the response at all, much less a timestamp. The following error will occur on a client when IncludeTimestamp is in the policy but no timestamp is returned in the response:

  CWWSS5730E: A required timestamp is not found.
  

  To resolve the issue, either configure the service provider to send a timestamp or configure the client to not require the timestamp by setting the com.ibm.wsspi.wssecurity.consumer.timestampRequired custom property to false in the WS-Security policy bindings. See Web services security custom properties for more information.

• Use XML digital signature and XML encryption properly to avoid a potential security hole

  The Web Services Security 2004 specification defines how to use XML digital signature and XML encryption in SOAP headers. When building trust into an application based on a digital signature, we must 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 encrypting digitally signed data, we might leave the digital signature in plain text and leave a message vulnerable to plain text guessing attacks. As a general practice, when data is encrypted, encrypt any digest or signature over the data. See http://www.w3.org/TR/xmlenc-core/#sec-Sign-with-Encrypt.

• Protecting the integrity of security tokens

  With a token substitution attack, a digital signature is verified with a key that is often derived from a security token and is included in a message. If the token is substituted, a recipient might accept the message based on the substituted key, which might not be what you expect. One possible solution to this problem is to sign the security token (or the unique identifying data from which the signing key is derived) together with the signed data. In some situations, the token that is issued by a trusted authority is signed. In this case, there might not be an integrity issue. However, because application semantics and the environment might change over time, the best practice is to prevent this attack. We must assess the risk assessment based upon the deployed environment.

• Verifying the certificate to leverage the certificate path verification and the certificate revocation list

  IBM recommends verifying that the authenticity or validity of the token identity 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 and later, 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. For a sophisticated solution, we might develop our own TokenConsumer implementation that performs certificate and CRL verification using the online CRL database or the Online Certificate Status Protocol (OCSP).

• Protecting the username token with a password

  IBM recommends not sending a password in a username token 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 the environment. However, we might be able to send a password to a downstream server as plain text in some special environments where we are positive that we are not vulnerable to an attack.

Secure web services involves more work than just enabling XML digital signature and XML encryption. To properly secure a Web service, we must have knowledge about the PKI. The amount of security needed depends upon the deployed environment and the usage patterns. However, there are some basic rules and best practices for securing web services. IBM recommends reading some books on PKI and also read information on the Web Services Interoperability Organization (WS-I) Basic Security Profile (BSP).

Related:

Overview of standards and programming models for web services message-level security

Time stamp

Basic Security Profile Version 1.0