You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@ws.apache.org by co...@apache.org on 2012/11/26 12:56:45 UTC
svn commit: r1413565 - in /webservices/wss4j/branches/1_6_x-fixes/src/site: site.xml xdoc/best_practice.xml

Author: coheigea
Date: Mon Nov 26 11:56:44 2012
New Revision: 1413565

URL: http://svn.apache.org/viewvc?rev=1413565&view=rev
Log:
Adding a security best practices page

Added:
    webservices/wss4j/branches/1_6_x-fixes/src/site/xdoc/best_practice.xml
Modified:
    webservices/wss4j/branches/1_6_x-fixes/src/site/site.xml

Modified: webservices/wss4j/branches/1_6_x-fixes/src/site/site.xml
URL: http://svn.apache.org/viewvc/webservices/wss4j/branches/1_6_x-fixes/src/site/site.xml?rev=1413565&r1=1413564&r2=1413565&view=diff
==============================================================================
--- webservices/wss4j/branches/1_6_x-fixes/src/site/site.xml (original)
+++ webservices/wss4j/branches/1_6_x-fixes/src/site/site.xml Mon Nov 26 11:56:44 2012
@@ -15,6 +15,7 @@
       <item name="Using WSS4J" href="using.html"/>
       <item name="WSS4J Configuration" href="config.html"/>
       <item name="Special Topics" href="topics.html"/>
+      <item name="Security Best Practices" href="best_practice.html"/>
       <item name="WSS4J 1.6 Release Notes" href="wss4j16.html"/>
     </menu>
 

Added: webservices/wss4j/branches/1_6_x-fixes/src/site/xdoc/best_practice.xml
URL: http://svn.apache.org/viewvc/webservices/wss4j/branches/1_6_x-fixes/src/site/xdoc/best_practice.xml?rev=1413565&view=auto
==============================================================================
--- webservices/wss4j/branches/1_6_x-fixes/src/site/xdoc/best_practice.xml (added)
+++ webservices/wss4j/branches/1_6_x-fixes/src/site/xdoc/best_practice.xml Mon Nov 26 11:56:44 2012
@@ -0,0 +1,79 @@
+<?xml version="1.0" encoding="ISO-8859-1"?>
+<document>
+<body>
+<section name="Security Best Practices">
+<p>
+This page describes a number of steps which should be taken to ensure that security best
+practices are followed and enforced.
+</p>
+<subsection name="Upgrade from WSS4J 1.5.x to WSS4J 1.6.x">
+<p>
+The 1.5.x series of releases of WSS4J is deprecated. You should switch to a 1.6.x release
+as a matter of priority, as this branch contains up to date security fixes. For example,
+WSS4J 1.6.x uses the "secure validation" mode of Apache XML Security for Java, which protects
+against a number of <a href="http://santuario.apache.org/java150releasenotes.html">attacks</a>
+on XML Signature.
+</p>
+</subsection>
+<subsection name="Upgrade to the latest minor release as soon as possible">
+<p>
+You should always upgrade to the latest minor release in a timely manner, in order to pick up 
+security fixes.
+</p>
+</subsection>
+<subsection name="Use WS-SecurityPolicy to enforce security requirements">
+<p>
+WSS4J can be used with a web services stack such as Apache CXF or Apache Axis in one of two
+ways: either by specifying security actions directly, or via WS-SecurityPolicy. 
+WS-SecurityPolicy is a much richer way of specifying security constraints when processing
+messages, and gives you more "automatic" protection against various attacks then when
+configuring via security actions. See for example, this blog 
+<a href="http://coheigea.blogspot.ie/2012/10/xml-signature-wrapping-attacks-on-web.html">post</a>
+on XML signature wrapping attacks. Therefore, you should always try to use WSS4J with a
+WS-SecurityPolicy requirement.
+</p>
+</subsection>
+<subsection name="Use RSA-OAEP for the Key Transport Algorithm">
+<p>
+WSS4J supports two key transport algorithms, RSA v1.5 and RSA-OAEP. A number of attacks
+exist on RSA v1.5. Therefore, you should always use RSA-OAEP as the key transport algorithm,
+and enforce this decision. For WS-SecurityPolicy, this means to avoid using any AlgorithmSuite
+that ends with "Rsa15" (e.g. "Basic128Rsa15"). For the direct configuration case, you should
+explicitly configure WSHandlerConstants.ENC_KEY_TRANSPORT ("encryptionKeyTransportAlgorithm")
+to be "http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p". This latter point requires the
+web services stack to set this property on the Request (is it known that Apache CXF does this).
+</p>
+</subsection>
+<subsection name="Avoid using a cbc Symmetric Encryption Algorithm">
+<p>
+There are some attacks that exploit the "cbc" mode of a Symmetric Encryption Algorithm. 
+WSS4J has support for "gcm" mode algorithms as well. This can be specified via
+WSHandlerConstants.ENC_SYM_ALGO ("encryptionSymAlgorithm"), for example to 
+"http://www.w3.org/2009/xmlenc11#aes128-gcm".
+</p>
+</subsection>
+<subsection name="Use Subject DN regular expressions with chain trust">
+<p>
+WSS4J 1.6.7 introduced the ability to specify regular expressions on the Subject DN of a 
+certificate used for signature validation. It is important to add this constraint when you
+are supporting "chain trust", which is where you are establishing trust in a certificate 
+based on the fact that the Issuer of the certificate is in your trust store. Otherwise, any
+certificate of this issuer will pass trust validation. See 
+<a href="http://coheigea.blogspot.ie/2012/08/subject-dn-certificate-constraint.html">here</a>
+for more information. 
+</p>
+</subsection>
+<subsection name="Specify signature algorithm on receiving side">
+<p>
+When not using WS-SecurityPolicy (see point above about favouring the WS-SecurityPolicy
+approach), you should specify a signature algorithm to use on the receiving side. This
+can be done via WSHandlerConstants.SIG_ALGO ("signatureAlgorithm"). Setting this property
+to (e.g.) "http://www.w3.org/2000/09/xmldsig#rsa-sha1" will ensure that the signature
+algorithm allowed is RSA-SHA1 and not (e.g.) HMAC-SHA1. This latter point requires the
+web services stack to set this property on the Request (is it known that Apache CXF does 
+this). See also the previous point about setting the key encryption transport algorithm.
+</p>
+</subsection>
+</section>            
+</body>
+</document>