XML Signature Best Practices

2.1.1 Example: XSLT transform that causes denial of service

The following XSLT transform contains 4 levels of nested loops, and for each loop it iterates over all the nodes of the document. So if the original document has 100 elements, this would take 100^4 = 100 million operations. A malicious message could include this transform and cause an application server to spend hours processing it. The scope of this denial of service attack is greatly reduced when following the best practices described above, since it is unlikely that an authenticated user would include this kind of transform. XSLT transforms should only be processed for References, and not for ds:KeyInfo ds:RetrievalMethods, and only after first authenticating the entire signature and establishing an appropriate degree of trust in the originator of the message.

dos_xslt.xml


              <Transform Algorithm="http://www.w3.org/TR/1999/REC-xslt-19991116">
              <xsl:stylesheet version="1.0" 
              xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
              <xsl:template match="/">
              <xsl:for-each select="//. | //@*">
              <xsl:for-each select="//. | //@*">
              <xsl:for-each select="//. | //@*">
              <foo/>
              <xsl:for-each>
              <xsl:for-each>
              <xsl:for-each>
              </xsl:stylesheet>
              <Transform> 

As discussed further, below, support for XSLT transforms may also expose the signature processor or consumer to further risks in regard to external references or modified approvals. An implementation of XML Signature may choose not to support XSLT, may provide interfaces to allow the application to optionally disable support for it, or may otherwise mitigate risks associated with XSLT.

Instead of using the XML Signature XSLT transform, deployments can define a named transform of their own, by simply coining a URI in their own domain that can be used as the Algorithm. How that transform is implemented is then out of scope for the signature protocol - a named transform can very well be built in XSLT.

Choosing to name a new transform rather than embedding an XSLT transform in the signature reference has the advantage that the semantic intent of the transform can be made clear and limited in scope, as opposed to a general XSLT transform, possibly reducing the attack surface and allowing alternate implementations.

What may be lost is the general flexibility of using XSLT, requiring closer coordination between signer and verifiers since all will be required to understand the meaning of the new named transform.

2.1.2 Example: XSLT transform that executes arbitrary code

The XSLT transform in the example below makes use of the user-defined extension feature to execute arbitrary code when validating an XML Signature. The example syntax is specific to the Xalan XSLT engine, but this approach is valid for most XSLT engines. The example calls "os:exec" as a user-defined extension, which is mapped to the Java lang.Runtime.exec() method which can execute any program the process has the rights to run. While the example calls the shutdown command, one should expect more painful attacks if a series of attack signatures are allowed. If an implementation of XML Signature allows XSLT processing it should disable support for user-defined extensions. Changing the Transforms element does invalidate the signature. XSLT transforms should only be processed after first authenticating the entire signature and establishing an appropriate degree of trust in the originator of the message. Example:

xslt_transform_extensions.xml 


              <Transforms xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
              <Transform Algorithm="http://www.w3.org/TR/1999/REC-xslt-19991116">
              <xsl:stylesheet version="1.0" 
              xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:java="java">
              <xsl:template match="/" xmlns:os="java:lang.Runtime" >
              <xsl:variable name="runtime" 
              select="java:lang.Runtime.getRuntime()"/>
              <xsl:value-of select="os:exec($runtime, 'shutdown -i')" />
              </xsl:template>
              </xsl:stylesheet>
              </Transform>
              </Transforms>

2.1.3 Example: XPath Filtering transform that causes denial of service

The following XPath Transform has an expression that simply counts all the nodes in the document, but it is embedded in special document that has a 100 namespaces ns0 to ns99 and a 100 <e2> elements. The XPath model expects namespace nodes for each in-scope namespace to be attached to each element, and since in this special document all the 100 namespaces are in scope for each of the 100 elements, the document ends up having 100x100 = 10,000 NamespaceNodes.Now in an XPath Filtering transform, the XPath expression is evaluated for every node in the document. So it takes 10,000 x 10,000 = 100 million operations to evaluate this document. Again the scope of this attack can be reduced by following the above best practices

dos_xpath.xml


              <dsig:Transform Algorithm="http://www.w3.org/TR/1999/REC-xpath-19991116">
              <dsig:XPath>count(//. | //@* | //namespace::*)</dsig:XPath>
              </dsig:Transform>

An implementation of XML Signature may choose not to support the XPath Filter Transform, may provide interfaces to allow the application to optionally disable support for it, or otherwise mitigate risks associated with it. Another option is to support a limited set of XPath expressions - which only use the ancestor or self axes and do not compute string-value of elements. Yet another option is to use the XPath Filter 2.0 transform instead, because in this transform, the XPath expressions are only evaluated once, not for every node of the transform.

2.1.4 Example: XPath selection that causes denial of service in streaming mode

When an XML Signature is to be verified in streaming mode, additional denial of service attack vectors occur. As an example, consider the following XPath expression that is conforming to the [XMLDSIG-XPATH]: "//A//B". This XPath is intended to select every occurrence of <B> elements in the document that have an <A> element ancestor. Hence, on streaming parsing the document, every occurrence of an <A> element will trigger a new search context for the subsequent <B> element. Thus, an attacker may modify the XML document itself to contain lots of nested <A> elements, i.e. "<A><A><A><A><A><A><A><A><A><A>....". This will result in n search contexts, with n being the number of <A> elements in the document, and hence in O(n^2) comparisons in total. Even worse, if an attacker also manages to tamper the XPath expression used for selection itself, he can trigger an even more rapid Denial of Service: an XPath of "//A//A//A//A//A..." causes the number of search contexts to explode to O(2^n).

Hence, besides following Best Practice 1, it is strongly recommended to reduce the use of "wildcard" XPath axes (such as "descendant", "following" etc.) in XML Signatures to a minimum.

2.1.5 Example: Retrieval method that causes an infinite loop

The ds:KeyInfo of a signature can contain a ds:RetrievalMethod child element, which can be used to reference a key somewhere else in the document. ds:RetrievalMethod has legitimate uses; for example when there are multiple signatures in the same document, these signatures can use a ds:RetrievalMethod to avoid duplicate ds:KeyInfo certificate entries. However, referencing a certificate (or most other ds:KeyInfo child elements) requires at least one transform, because the reference URI can only refer to the ds:KeyInfo element itself (only it carries an Id attribute). Also, there is nothing that prevents the ds:RetrievalMethod from pointing back to itself directly or indirectly and forming a cyclic chain of references. An implementation that must handle potentially hostile messages should constrain the ds:RetrievalMethod elements that it processes - e.g. permitting only a same-document URI reference, and limiting the transforms allowed.

dos_retrieval_loop1.xml 


              <RetrievalMethod xml:id="r1" URI="#r1"/>

dos_retrieval_loop2.xml


              <RetrievalMethod Id="r1" URI="#r2"/>
              <RetrievalMethod Id="r2" URI="#r1"/>

2.1.6 Example: Problematic external references

An XML Signature message can use URIs to references keys or to reference data to be signed. Same document references are fine, but external references to the file system or other web sites can cause exceptions or cross site attacks. For example, a message could have a URI reference to "file://etc/passwd" in its ds:KeyInfo. Obviously there is no key present in file://etc/passwd, but if the xmlsec implementation blindly tries to resolve this URI, it will end up reading the /etc/passwd file. If this implementation is running in a sandbox, where access to sensitive files is prohibited, it may be terminated by the container for trying to access this file.

URI references based on HTTP can cause a different kind of damage since these URIs can have query parameters that can cause some data to be submitted/modified in another web site. Suppose there is a company internal HR website that is not accessible from outside the company. If there is a web service exposed to the outside world that accepts signed requests it may be possible to inappropriately access the HR site. A malicious message from the outside world can send a signature, with a reference URI like this http://hrwebsite.example.com/addHoliday?date=May30. If the XML Security implementation blindly tries to dereference this URI when verifying the signature, it may unintentionally have the side effect of adding an extra holiday.

When implementing XML Signature, it is recommended to take caution in retrieving references with arbitrary URI schemes which may trigger unintended side-effects and/or when retrieving references over the network. Care should be taken to limit the size and timeout values for content retrieved over the network in order to avoid denial of service conditions.

When implementing XML Signature, it is recommended to follow the recommendations in section 2.3 to provide cached references to the verified content, as remote references may change between the time they are retrieved for verification and subsequent retrieval for use by the application. Retrieval of remote references may also leak information about the verifiers of a message, such as a "web bug" that causes access to the server, resulting in notification being provided to the server regarding the web page access. An example is an image that cannot be seen but results in a server access [WebBug-Wikipedia].

When implementing XML Signature with support for XSLT transforms, it can be useful to constrain outbound network connectivity from the XSLT processor in order to avoid information disclosure risks as XSLT instructions may be able to dynamically retrieve content from local files and network resources and disclose this to other networks.

Some kinds of external references are perfectly acceptable, e.g. Web Services Security uses a "cid:" URL for referencing data inside attachments, and this can be considered to be a same document reference. Another legitimate example would be to allow references to content in the same ZIP or other virtual file system package as a signature, but not to content outside of the package.

The scope of this attack is much reduced by following the above best practices, because with that only URIs inside a validated ds:SignedInfo section will be accessed. But to totally eliminate this kind of attack, an implementation can choose not to support external references at all.

2.1.7 Example: Denial of service caused by too many transforms

XML Signature spec does not limit the number of transforms, and a malicious message could come in with 10,000 C14N transforms. C14N transforms involve lot of processing, and 10,000 transforms could starve all other messages.

Again the scope of this attack is also reduced by following the above best practices, as now an unauthenticated user would need to at first obtain a valid signing key and sign this ds:SignedInfo section with 10,000 C14N transform.

This signature has a 1000 C14N and a 1000 XPath transforms, which makes it slow. This document has a 100 namespaces ns0 to ns99 and a 100 <e2> elements, like in the XPath denial of service example. Since XPath expands all the namespaces for each element, it means that there are 100x100 = 10,000 NamespaceNodes All of these are processed for every C14N and XPath transform, so total operations is 2000 x 10,000 = 20,000,000 operations. Note some C14N implementations do not expand all the Namespace nodes but do shortcuts for performance, to thwart that this example has an XPath before every C14N.

dos_toomanytranforms.xml


              <Transform Algorithm="http://www.w3.org/TR/1999/REC-xpath-19991116">
              <XPath>1</XPath>
              </Transform>
              <Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315">

              <Transform Algorithm="http://www.w3.org/TR/1999/REC-xpath-19991116">
              <XPath>1</XPath>
              </Transform>
              <Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315">
	          ... repeated 1000 times

To totally eliminate this kind of attack, an implementation can choose to have an upper limit of the number of transforms in each Reference.

2.2.1 Return pre digested data

While doing reference validation, the implementation needs to run through the transforms for each reference, the output of which is a byte array, and then digest this byte array. The implementation should provide a way to cache this byte array and return it tot he application. This would let the application know exactly what was considered for signing This is the only recommended approach for processors and applications that allow remote DTDs, as entity expansion during C14N may introduce another opportunity for a malicious party to supply different content between signature validation and an application's subsequent re-processing of the message.

2.2.2 Return pre C14N data

While the above mechanism let the application know exactly what was signed, it cannot be used by application to programmatically compare with what was expected to be signed. For programmatic comparison the application needs another byte array, and it is hard for the application to generate a byte array that will match byte for byte with the expected byte array.

A better but more complicated approach is to return the pre-C14N data as a nodeset. This should include all the transforms except the last C14N transform - the output of this should be nodeset. If there are multiple references in the signature,the result should be a union of these nodesets. The application can compare this nodeset with the expected nodeset. The expected nodeset should be a subset of the signed nodeset.

DOM implementations usually provide a function to compare if two nodes are the same - in some DOM implementations just comparing pointers or references is sufficient to know if they are the same, DOM3 specifies a "isSameNode()" function for node comparison.

This approach only works for XML data, not for binary data. Also the transform list should follow these rules.

• The C14N transform should be last transform in the list. Note if there no C14N transform, an inclusive C14N is implicitly added

• There should be no transform which causes data to be converted to binary and then back to a nodeset. The reason is that this would cause the nodeset to be from a completely different document, which cannot be compared with the expected nodeset.

3.1.1 Base Approval example

Consider an application which is processing approvals, and expects a message of the following format where the where the Approval is supposed to be signed

Expected message for approval verification
			
              <Doc>
              <Approval xml:id="ap" >...</Approval>
              <Signature>
              ...
              <Reference URI="ap"/>
              ...
              </Signature> 
              </Doc> 	

It is not sufficient for the application to check if there is a URI in the reference and that reference points to the Approval. Because there may be some transforms in that reference which modify what is really signed.

3.1.2 Modified Approval Example: XPath transform that causes nothing to be selected for signing

In this case there is an XPath transform that evaluates to zero or false for every node, so it ends up selecting nothing.

Whether this is an error or not needs to be determined by the application. It is an error and the document should be rejected if the application expected some content to be signed. There may be cases, however, where this is not an error. For example, an application may wish to ensure that every price element is signed, without knowing how many there are. In some cases there might be none in the signed document. This signature allows the application to detect added price elements, so it is useful even if the were no content in the initial signing.

Insecure Approval verification message
			
              <Doc>
              <Approval xml:id="ap">...</Approval>
              <Signature>
              ...
              <Reference URI="ap">
              <Transforms>
			  <Transform Algorithm="...XPath...">
			  <XPath>0</XPath>
			  </Transform>
              </Transforms>     ...
              </Reference>
              </Signature> 
              </Doc> 	

3.1.3 Modified Approval Example: Incorrect XPath syntax signals no error and results in nothing selected for signing

An XPath evaluation will not raise an exception, nor give any other advice that the XPath selected nothing if the XPath expression has incorrect syntax. This is due to the fact that an XPath parser will interpret misspelled function names as regular XPath tokens, leading to completely different semantics that do not match the intended selection.

Example:
              Incorrect XPath resulting in insecure Approval
              verification message 
              
			
              <Doc xmlns="http://any.ns"
              xmlns:dsig-xpath="http://www.w3.org/2002/06/xmldsig-filter2">
              <Approval xml:id="ap">...</Approval>
              <Signature>
              ...
              <Reference URI="">
              <Transforms>
              <Transform Algorithm="...xmldsig-filter2">
              <dsig-xpath:XPath Filter="intersect">//*[localname="Approval" and
              namespace-uri="http://any.ns"]</dsig-xpath:XPath>
              </Transform>
              </Transforms> ...
              </Reference>
              </Signature>
              </Doc>

In this case, the XPath filter looks like it is selecting the Approval element of namespace http://any.ns. In reality it selects nothing at all since the function should be spelled "local-name" instead of "localname" and both function calls need brackets () in the correct syntax. The correct XPath expression to match the intent is:

//*[local-name()="Approval" and namespace-uri()="http://any.ns"].

Since nothing is selected, the digital signature does not provide any data integrity properties. It also raises no exception on either signature generation or on verification. Hence, when applying XML Signatures using XPath it is recommended to always actively verify that the signature protects the intended elements.

3.1.4 Modified Approval Example: XSLT transform that causes nothing to be selected for signing

Similar to the previous example, this one uses an XSLT transform which takes the incoming document, ignores it, and emits a "<foo/>" . So the actual Approval isn't signed. Obviously this message needs to be rejected.

Insecure Approval verification message
			
              <Doc>
              <Approval xml:id="ap">...</Approval>
              <Signature>
              ...
              <Reference URI="ap">
              <Transforms>
              <Transform Algorithm="...xslt...">
              <xsl:stylesheet>
              <xsl:template match="/">
              <foo/>
              </xsl:template>
              </xsl:stylesheet> 
              </Transform>
              </Transforms>     ...
              </Reference>
              </Signature> 
              </Doc> 	

3.1.5 Modified Approval Example: Wrapping attack

This one is a different kind of problem - a wrapping attack.There are no transforms here, but notice that Reference URI is not "ap" but "ap2". And "ap2" points to another <Approval> element that is squirreled away in an Object element. An Object element allows any content. The application will be fooled into thinking that the approval element is properly signed, it just checks the name of what the element that the Reference points to. It should check both the name and the position of the element.

Insecure Approval verification message
			
              <Doc>
              <Approval xml:id="ap">...</Approval>
              <Signature>
              ...
              <Reference URI="ap2"/>
              ...
              <Object>
              <Approval xml:id="ap2">...</Approval>
              </Object> 
              </Signature> 
              </Doc> 	

3.2.1 Sign what matters

By electing to only sign portions of a document this opens the potential for substitution attacks.

To give an example, consider the case where someone signed the action part of the request, but didn't include the user name part. In this case an attacker can easily take the signed request as is, and just change the user name and resubmit it. These Replay attacks are much easier when you are signing a small part of the document. To prevent replay attacks, it is recommended to include user names, keys, timestamps, etc into the signature.

A second example is a "wrapping attack" [MCINTOSH-WRAP] where additional XML content is added to change what is signed. An example is where only the amounts in a PurchaseOrder are signed rather than the entire purchase order.

3.2.2 Make Effective use of signing time and Nonces to protect against Replay Attacks

In many cases replay detection is provided as a part of application logic, often and a by product of normal processing. For example, if purchase orders are required to have a unique serial number, duplicates may be automatically discarded. In these cases, it is not strictly necessary for the security mechanisms to provide replay detection. However, since application logic may be unknown or change over time, providing replay detection is the safest policy.

Nonces and passwords must fall under at least one signature to be effective. In addition, the signature should include at least a critical portion of the message payload, otherwise an attacker might be able to discard the dateTime and its signature without arousing suspicion.

Web Services Security [WS-SECURITY11] defines a <Timestamp> element which can contain a Created dateTime value and/or a Expires dateTime value. The Created value obviously represents an observation made. The expires value is more problematic, as it represents a policy choice which should belong to the receiver not the sender. Setting an expiration date on a Token may reflect how long the data is expected to be correct or how long the secret may remain uncompromised. However, the semantics of a signature "expiring" is not clear.

WSS provides for the use of a nonce in conjunction with hashed passwords, but not for general use with asymmetric or symmetric signatures.

WSS sets a limit of one <Timestamp> element per Security header, but their can be several signatures. In the typical case where all signatures are generated at about the same time, this is not a problem, but SOAP messages may pass through multiple intermediaries and be queued for a time, so this limitation could possibly create problems. In general Senders should ensure and receivers should assume that the <Timestamp> represents the first (oldest) signature. It is not clear how if at all a <Timestamp> relates to encrypted data.

3.3.1 Timestamp Authorities

The X.509 Public Key Infrastructure Time-Stamp Protocol, RFC 3161 [RFC3161], describes the use of a time stamp authority to establish evidence that a signature existed before a given time, useful in applications where dispute resolution may be necessary.

The IETF PKIX WG "ESSCertIDv2 update for RFC 3161" should be consulted when referencing RFC 3161 [RFC3161-PKIX-UPDATE-9].

ETSI has produced TS 101 903: "XML Advanced Electronic Signatures" [XADES], which among other ones, deals with the issue of long-term electronic signatures. It has defined a standard way for incorporating time-stamps to XML signatures. In addition to the signature time-stamp, which should be generated soon after the generation of the signature, other time-stamps may be added to the signature structure protecting the validation material used by the verifier. Recurrent time-stamping (with stronger algorithms and keys) on all these items, i.e., the signature, the validation material and previous time-stamps counters the revocation of validation data and weaknesses of cryptographic algorithms and keys. RFC 3161 and OASIS DSS time-stamps may be incorporated in XAdES signatures.

OASIS DSS core specifies a XML format for time-stamps based in XML Sig. In addition DSS core and profiles allow the generation and verification of signatures, time-stamps, and time-stamped signatures by a centralized server.

The XAdES and DSS Timestamps should not be confused with WSS Timestamps. Although they are both called Timestamps, the WSS <Timestamp> is just a xsd:dateTime value added by the signer representing the claimed time of signing. XAdES and DSS Timestamps are full fledged signatures generated by a Time-stamp Authority (TSA) binding together a the digest of what is being time-stamped and a dateTime value. TSAs are trusted third parties which operate under certain rules on procedures, software and hardware including time accuracy assurance mechanisms.

3.3.2 Include time of signing in Long-Lived Signatures

Note that in the absence of a trusted time source, such a signing time should be viewed as indicating a minimum, but not a maximum age. This is because we assume that a time in the future would be noticed during processing. So if the time does not indicate when the signature was computed it at least indicates earliest time it might have been made available for processing.

It is considered desirable for ephemeral signature to be relatively recently signed and not to be replayed. The signing time is useful for either or both of these. The use for freshness is obvious. Signing time is not ideal for preventing replay, since depending on the granularity, duplicates are possible.

A better scheme is to use a nonce and a signing time The nonce is checked to see if it duplicates a previously presented value. The signing time allows receivers to limit how long nonces are retained (or how many are retained).