Share via

Web service security - Threats and Countermeasures - Part 4 : Message Protection – Sign and Encrypt and Encrypt Signature!

  • Article

Threats

  •  Network eavesdropping leads to disclosure of confidential information even though the SOAP message body is encrypted

Vulnerabilities

  •  Many web service security platforms support signing and encrypting SOAP messages (see Threat 1 - Message Protection), however, what isn't always obvious is that the XML signature created to verify data integrity is often sent in plain text. The plain text signature (in combination with an understanding of the format of the message that something like the WSDL could provide) could be used by an attacker to perform an offline guessing attack potentially allowing the attacker to guess the value of the body of the message.

Background

  • An XML Signature contains two main elements - the SignatureValue and the SignedInfo. See EXTRACT 1 for a sample message. The SignedInfo element contains a series of child elements that reference sections of the SOAP message that are actually signed. Within each of these references there is a DigestValue which is the hash (typically SHA-1) of the XML element being signed. The XML Signature also contains a SignatureValue section which is where the asymmetric (if you are using X.509) or symmetric (if you are using Kerberos, or UsernameToken etc) signature created on top of the SignedInfo section is.

Countermeasures

  • Ws-Security supports the ability to not only sign and encrypt SOAP messages, but also to Sign, Encrypt and also Encrypt the SOAP signature! See EXTRACT 2 for an example.

Implementations

  • WSE 2.0 - WSE 2.0 did not support encrypting the signature by default, however, we created a custom ConfidentialityEx assertion for our WS-I Basic Security Profile sample application that enabled this capability. Take a look at: https://msdn.microsoft.com/practices/guidetype/RefImp/default.aspx?pull=/library/en-us/dnpag2/html/MSWSIBSP.asp
  • WSE 3.0 - WSE 3.0 supports this capability by using the policy configuration attribute: messageProtectionOrder="SignBeforeEncryptAndEncryptSignature". All of our Web service security implementation patterns implement this capability by default. WSE 3.0 tooling only uses ""SignBeforeEncrypt" by default.
  • J2EE - From what I understand this capability is not implemented by default in many of the solutions (although hopefully comments to the contrary on this blog will let you know what your platform supports). The good news is that all vendors writing applications within the WS-I BSP Sample Application working group are supporting this scenario - so contact your vendor and ask for a copy of their sample application to find out how it works!

Message Protection Design Patterns (for WSE 3.0):

Considerations:

I believe at one point there were interop issues - but we have been testing this scenario within the WS-I for > 12 months now and this has never been a cause of interop issue to my knowledge.

The one downside to this is that if you wanted to have a message router perform logic based on the signature or perform authentication then that router would have to be able to decrypt the message first - which would require it to have the service's private key - or shared secret. Not always (ever?) a good idea... so think carefully about this.

Sample Messages

EXTRACT 1 - XML Signature and Message Body from a message that is signed and encrypted - but XML signature is in plain text

         - + <Signature xmlns="https://www.w3.org/2000/09/xmldsig#">
            - + <SignedInfo>
                 <ds:CanonicalizationMethod Algorithm="https://www.w3.org/2001/10/xml-exc-c14n#" xmlns:ds="https://www.w3.org/2000/09/xmldsig#" />
                 <SignatureMethod Algorithm="https://www.w3.org/2000/09/xmldsig#rsa-sha1" />
               - + <Reference URI="#Id-190c8f3c-cd45-4183-8de7-95bc398a63d6">
                  - + <Transforms>
                       <Transform Algorithm="https://www.w3.org/2001/10/xml-exc-c14n#" />
                    </Transforms>
                    <DigestMethod Algorithm="https://www.w3.org/2000/09/xmldsig#sha1" />
                  - + <DigestValue>lpZoxBZ12gWO7kTaiKMD/q5N8m4=</DigestValue>
                 </Reference>
               - + <Reference URI="#Id-73ccf67b-6a8d-4c5e-ba8d-197d392a9f40">
.
.
.
              </SignedInfo>
            - + <SignatureValue>lCGSfL8dvKeMmwR/cdU95Xemsfagr8EKZQPmr4m/4P3SmjOG1njT000fyn2U2GngUJTC2ZW0/YLAmtOzPx9kTecaceJp8RLPNs4rzlJzJ7dypD2x8gx8wDWUrZ5lp03BZu+T6IWYh0GC6BQFzDH5Y01hYzkXETK8oorRP15VOeY=</SignatureValue>
            - + <KeyInfo>
               - + <wsse:SecurityTokenReference>
                    <wsse:Reference URI="#SecurityToken-b84fefe6-3024-49b7-ba08-12ffded701b0" ValueType="https://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3" />
                 </wsse:SecurityTokenReference>
              </KeyInfo>
           </Signature>
        </wsse:Security>
     </soap:Header>
   - + <soap:Body wsu:Id="Id-d97e5c2b-4ac4-4316-83f8-ce0bd0d233a1">
      - + <xenc:EncryptedData Id="Enc-71ae2fc0-c780-4d25-90eb-8b5522d54c6d" Type="https://www.w3.org/2001/04/xmlenc#Content"
          xmlns:xenc="https://www.w3.org/2001/04/xmlenc#">
           <xenc:EncryptionMethod Algorithm="https://www.w3.org/2001/04/xmlenc#aes256-cbc" />
         - + <xenc:CipherData>
            - + <xenc:CipherValue>qtXLf/qqoIYTP/IZHCbUVwFdlFCusWEvJrldKLEgunO0GPn6tStX6KVRks3BCj8r7MilAm7gTi9qVzuquaWP1JSkn16BA=</xenc:CipherValue>
           </xenc:CipherData>
        </xenc:EncryptedData>
     </soap:Body>
  </soap:Envelope>

EXTRACT 2 - XML Signature and Message Body from a message that is signed and encrypted with an encrypted XML signature

<wsse:Security soap:mustUnderstand="1">
         - + <wsu:Timestamp wsu:Id="Timestamp-cdc0377d-9151-437d-a9cd-9f3ab87fd973">
            - + <wsu:Created>2005-12-28T18:47:48Z</wsu:Created>
            - + <wsu:Expires>2005-12-28T18:52:48Z</wsu:Expires>
           </wsu:Timestamp>
         - + <xenc:ReferenceList xmlns:xenc="https://www.w3.org/2001/04/xmlenc#">
              <xenc:DataReference URI="#Enc-e5bb6890-2550-4620-8b16-23ec8c226da9" />
              <xenc:DataReference URI="#Enc-60e36641-079c-4533-a9a7-f17d69b6247a" />
           </xenc:ReferenceList>
         - + <xenc:EncryptedData Id="Enc-e5bb6890-2550-4620-8b16-23ec8c226da9" Type="https://www.w3.org/2001/04/xmlenc#Element"
             xmlns:xenc="https://www.w3.org/2001/04/xmlenc#">
              <xenc:EncryptionMethod Algorithm="https://www.w3.org/2001/04/xmlenc#aes256-cbc" />
            - + <KeyInfo xmlns="https://www.w3.org/2000/09/xmldsig#">
               - + <wsse:SecurityTokenReference>
                    <wsse:Reference URI="#SecurityToken-e559e109-26c6-42c3-b835-c3752e45ed5e" ValueType="https://schemas.xmlsoap.org/ws/2005/02/sc/sct" />
                 </wsse:SecurityTokenReference>
              </KeyInfo>
            - + <xenc:CipherData>
               - + <xenc:CipherValue>Q0q4UfT2H0gCMPNhmyN5M2RDcLE2t6+1mmREaV84F95kOHpaEebtVC7mzo3xL5ZJMkwmIFkX1mdzwjggDQdggAN1pRoQv6TC6WJJOs7euLGM0g+eLY+E5ZICuobgeigDnIcdPNAzmhvEscJpr0i7vP+6k=</xenc:CipherValue>
              </xenc:CipherData>
           </xenc:EncryptedData>
        </wsse:Security>

Comments

  • Anonymous
    September 17, 2008
    update me on web services security new vulnerabilities