Security considerations for web services

When you configure Web Services Security, you should make every effort to verify that the result is not vulnerable to a wide range of attack mechanisms. There are possible security concerns that arise when you are securing web services.

In WebSphere® Application Server, when you enable integrity, confidentiality, and the associated tokens within a SOAP message, security is not guaranteed. This list of security concerns is not complete. You must conduct your own security analysis for your 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. It is recommended that you allow message recipients to detect message replay attacks when messages are exchanged through an open network. You can use the following elements, which are described in the Web Services Security specifications, for this purpose:
    Timestamp
    You can 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, you 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.gotcha

    For more information about Timestamp, see Time stamp.

    WebSphere Application Server 會施行 IncludeTimestamp 原則主張。不過,很多服務提供者需要要求中有 <wsu:Timestamp> 元素,卻不會在回應中傳送任何一個元素。回應中也可能完全沒有 Security 標頭,更不用說有時間戳記。當原則中有 IncludeTimestamp,而回應中沒有傳回時間戳記時,用戶端上會發生下列錯誤:
    CWWSS5730E: 找不到必要的時間戳記。
    如果要解決這個問題,請配置服務提供者來傳送時間戳記,或在 WS-Security 原則連結中,將 com.ibm.wsspi.wssecurity.consumer.timestampRequired 自訂內容設為 false,以將用戶端配置成不需要時間戳記。如需相關資訊,請參閱Web services security custom properties
  • Using 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. Therefore, users must understand XML digital signature and XML encryption in the context of other security mechanisms and their possible threats to an entity. For XML digital signature, you must be aware of all of the security implications resulting from the use of digital signatures in general and XML digital signature in particular. When you build trust into an application based on a digital signature, you 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 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-Encrypt.

  • Protecting the integrity of security tokens

    The possibility of a token substitution attack exists. In this scenario, 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. You must assess the risk assessment based upon the deployed environment.

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

    It is recommended that you 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 WebSphere Application Server Version 6 and later, the certificate is verified by the <TokenConsumer> element. WebSphere Application Server 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, you might develop your 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

    It is recommended that you do not send a password in a username token to a downstream server without protection. You can 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.

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


指出主題類型的圖示 參照主題



時間戳記圖示 前次更新: July 9, 2016 11:14
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=rwbs_secconsider6wssec
檔名:rwbs_secconsider6wssec.html