Uploaded image for project: 'Spring Web Services'
  1. Spring Web Services
  2. SWS-997

Thread proliferation and memory leak when using WSS4JSecurityInterceptor

    Details

    • Type: Bug
    • Status: Open
    • Priority: Critical
    • Resolution: Unresolved
    • Affects Version/s: 2.4.0
    • Fix Version/s: None
    • Component/s: Core
    • Labels:
      None

      Description

      We're using a WSS4JSecurityInterceptor to validate incoming messages and sign outgoing messages:

       Wss4jSecurityInterceptor wss4jSecurityInterceptor = new Wss4jSecurityInterceptor();   
       
         // Validate signature of incoming messages
         wss4jSecurityInterceptor.setValidationSignatureCrypto(crypto);
         wss4jSecurityInterceptor.setValidationActions("Timestamp Signature");
       
         // Sign outgoing messages
         wss4jSecurityInterceptor.setSecurementSignatureCrypto(crypto);
         wss4jSecurityInterceptor.setSecurementSignatureKeyIdentifier("DirectReference");
         wss4jSecurityInterceptor.setSecurementUsername(privateKeyAlias);
         wss4jSecurityInterceptor.setSecurementPassword(privateKeyPassword);
         wss4jSecurityInterceptor.setSecurementActions("Timestamp Signature");
         wss4jSecurityInterceptor.setSecurementSignatureParts("{}{http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd}Timestamp;{}{http://schemas.xmlsoap.org/soap/envelope/}Body");
       
             // and later
      class SpringWSConfiguration extends WsConfigurerAdapter  {
          @Override
          public void addInterceptors(List<EndpointInterceptor> interceptors) {
                  interceptors.add(wss4jSecurityInterceptor);
          }
      }
      

      When using the interceptor this way, a lot of EHCache threads named "wss4j%002etimestamp%002ecache-e%0058ga%0058l%0058%004b%0057g%004ah%0050w==.data" (and similar) start to appear, one for each request that has been made.

      I believe this happens because of the way the Wss4jSecurityInterceptor initializes the WSS4J RequestData structure in initializeRequestData and initializeValidationRequestData. By default the RequestData class has caching enabled for detecting various replay attacks. However the default implementation is to just create one cache per RequestData structure using the ReplayCacheFactory.newInstance() method.

      Now when you send a request and this is validated, this at some point calls WSS4J's SignatureProcessor class, which in turn calls RequestData.getTimestampReplayCache() which by default creates a new EHCache instance (if EHCache happens to be on the classpath which it is for our project).

      I found out about this issue reading through http://apache-xml-project.6118.n7.nabble.com/nonce-cache-thread-proliferation-td42797.html for a similar problem. The recommended solution is to either disable replay caches or to properly initialize them by calling the setXXXReplayCache methods when creating the RequestData structure.

      So since the current implementation wouldn't detect replay attacks either (because having one cache per request basically disables replay attack checks, albeit in a very expensive manner), i would suggest changing the implementation of the Wss4jSecurityInterceptor initializeRequestData and initializeValidationRequestData methods and to append these lines before returning the RequestData structure:

        requestData.setEnableNonceReplayCache(false);
        requestData.setEnableSamlOneTimeUseReplayCache(false);
        requestData.setEnableTimestampReplayCache(false);
      

        Activity

        No work has yet been logged on this issue.

          People

          • Assignee:
            Unassigned
            Reporter:
            j.thomae Jan Thomä
          • Votes:
            2 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated: