Network Working Group Jitendra Kumar
Internet-Draft Balaji Rajendran
Intended status: Standards Track Bindhumadhava BS
Expires: August 19, 2018 C-DAC Bangalore
February 15, 2018
A modified XML Signature algorithm to mitigate XML Digital Signature
wrapping attacks
draft-wrapping-attack-mitigation-00
Abstract
XML signature standard (described in RFC3275 [RFC3275])defined by
IETF/W3C references or identifies signed elements by their unique
identities specified by "id" attribute values in the given XML
document. Hence, signed XML elements can be shifted from one
location to another location in a XML document, and still, it does
not have any effect on its ability to verify its signature. This
flexibility paves the way for an attacker to tweak original XML
message without getting noticed by the receiver. This document
proposes to use absolute XPath as an "Positional Token" and modifies
XML Signature algorithm to overcome the XML Signature wrapping
attacks on XML signatures.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 19, 2018.
Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved.
Jitendra Kumar, et al. Expires August 19, 2018 [Page 1]
Internet-Draft Abbreviated Title February 2018
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. XML Digital Signature structure . . . . . . . . . . . . . . . 3
3. Suggested Modified Algorithm . . . . . . . . . . . . . . . . 3
3.1. Algorithm for signing SOAP Request . . . . . . . . . . . 4
3.2. Algorithm for verification of Signature . . . . . . . . . 4
3.2.1. Method for Verifying Digest for SignedInfo Element
with Decrypted Digest from SignatureValue element . . 5
4. Algorithm Validation . . . . . . . . . . . . . . . . . . . . 5
4.1. Mitigation of XML Signature wrapping attacks . . . . . . 6
4.2. Mitigation of XML elements jumbling type of wrapping
attacks . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . 7
8.2. Informative References . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
Many researchers have shown that even a signed SOAP messages are
vulnerable to interception and further manipulation of its content.
McIntosh and Austel (described in wrapping_attack [wrapping_attack])
have illustrated that a SOAP message content, protected by an XML
Digital Signature, as specified in WS-Security(refer, WS-Security
[WS-Security] )can be forged without invalidating the signature.
These attacks are termed as XML Signature wrapping attacks or XML
rewriting attacks.These types of attacks are possible because the XML
Digital Signature refers to a signed element in XML document in a way
that does not take care of its location inside the XML document into
consideration.Attackers inject additional nodes replacing signed
nodes while still preserving the signed nodes inside the document but
at different level in the hierarchy of the XML tree such that it
Jitendra Kumar, et al. Expires August 19, 2018 [Page 2]
Internet-Draft Abbreviated Title February 2018
results in successful signature verification thereby resulting in XML
Re-Writing/Wrapping attack.
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
2. XML Digital Signature structure
XML Signatures (described in RFC3275 [RFC3275]) are applied to
arbitrary digital content (data objects). Data objects are
digested,the resulting value is placed in an element (with other
information) and that element is then digested and cryptographically
signed.XML digital signatures are represented by the Signature
element which has the following structure (where "?" denotes zero or
one occurrence; "+" denotes one or more occurrences; and "*" denotes
zero or more occurrences):
(
()?
)+
()?
(
Signatures are related to data objects via URIs [URI]. Within an XML
document, signatures are related to local data objects via fragment
identifiers.
3. Suggested Modified Algorithm
As, SOAP requests are prone to XML wrapping attacks and this
vulnerabilities stems mostly because of usage of ID to identify the
signed XML sub tree. There are many solutions proposed to mitigate
such attacks but still such attacks can't be fully eliminated because
of inherent limitation present in XML Digital Signature standard.In
Jitendra Kumar, et al. Expires August 19, 2018 [Page 3]
Internet-Draft Abbreviated Title February 2018
this document, we have proposed an addition of "Positional Token" as
a doping to the XML element getting signed to mitigate XML Signature
wrapping attacks. We are also proposing a little modification of XML
Signature standard as to use of "Absolute XPath" instead of ID in
node's attribute to refer the signed element. Use this
absolute XPath as a "Positional Token", as this token exactly points
to the position of element getting signed. Also, during signing
process, add this "Positional Token" as an attribute (e.g. PosToken=
"Absolute XPath") to the element subjected to be signed. This
absolute XPath as a "Positional Token" would identify the signed
element in XML Signature and addition of this "Positional Token" as
an attribute to the element getting signed eliminate the chances of
XML Wrapping attacks as in the case of forged SOAP requests,
calculated digest of signed element will not match with the
respective digest value in node during signature
validation process. We propose a modified XML signature algorithm
which suggests usage of absolute XPath as a "Positional Token" and it
will be used during signing as well as during signature validation
process. The algorithms are as follows.:
3.1. Algorithm for signing SOAP Request
1. KS=Load(Keystore.JKS) //Load certificates and keys
2. For each element subjected to be signed represented by its "Id" attribute values{
3. ABSXpath= "Absolute XPath" of element to be signed as identified with its "Id" attribute value
4. ProtectTree=SOAP request node identified by ABSXpath
5. MixedElement=AppendSyntacticToken(ProtectTree, ABSXpath)
/*Append a Positional Token as an attribute, "PosToken= ABSXpath" to the ProtectTree */
6. H=Hash(MixedElement)
7. Add ABSXpath to node as "URI" attribute value
8. Enclose H to node inside the node, as defined in XML Signature standard [9].
9. }
10. SignedInfoHash=calculate hash of element
/* Calculate the digest of the element */
11. SignedSOAP=Encrypt(SignedInfoHash , KS.PrivateKey)
/*Signing that digest and enclosing the signature value in a element */
3.2. Algorithm for verification of Signature
Jitendra Kumar, et al. Expires August 19, 2018 [Page 4]
Internet-Draft Abbreviated Title February 2018
1. SignInfoDigest=Calculate digest of the element
2. SignatureValueContent= content inside node
3. Flag=VerifySignature(Public Key, SignatureValueContent, SignInInfoDigest)
4. If(Flag){
5. Ids=All URI's in nodes inside the node
6. For each Id from Ids){
7. ABSXpath=Get the content of Id
8. Subtree=Get the sub tree identified by ABSXpath
9. MixedElement =AppendSyntacticTokenSubTree(Subtree, ABSXpath)
/* Append a Positional Token as an attribute, "PosToken= ABSXpath" to the Subtree */
10. H=Hash (MixedElement)/* generate hash value of signed elements. */
11. Digest=Get digest value under the node and inside node, whose "URI" is equal to Id
12. If(H!=Digest){
13. return "Signature Validation Failed"
14. }else{
15. return "Signature Validation Successful"
16. }
17. } //For loop
18. else
19. return "Signature Validation Failed"
20. }
3.2.1. Method for Verifying Digest for SignedInfo Element with
Decrypted Digest from SignatureValue element
1. VerifySignature(PublicKey, SignatureValueContent, SignInInfoDigest){
2. DecryptedDigest=Decrypt SignatureValueContent with PublicKey
3. If(DecryptedDigest!=SignInInfoDigest){
4. return False
5. }
6. else{
7. return True
8. }
9. }
4. Algorithm Validation
In this section we will discuss as how the suggested algorithm can
mitigate the various scenarios of XML wrapping attacks.
Jitendra Kumar, et al. Expires August 19, 2018 [Page 5]
Internet-Draft Abbreviated Title February 2018
4.1. Mitigation of XML Signature wrapping attacks
This kind of attacks are possible because signature verification
algorithm identifies signed element using identity i.e. ID and
identifying position of signed element using ID has inherent flaw as
the signed element can easily be moved within the document and still
the document retains the ability to verify its signature. So, in our
algorithm, we have suggested the usage of absolute XPath in place of
ID for identifying the position of signed elements. Absolute XPath
has two fold advantages as it can easily identify the position of
signed element within the XML document and it fixes both the vertical
and horizontal axes of the signed element exactly. The absolute
XPath expression to identify signed element will not be same as
absolute XPath expression for signed element in forged document.The
signature validation will fail at step-8, of algorithm in
Section 3.2, as there is no such node, Further, if the attacker
modifies the URI attribute and tries to perform XML wrapping attack ,
the digest of will not match and signature validation
will fail at step-4 of algorithm in Section 3.2.
4.2. Mitigation of XML elements jumbling type of wrapping attacks
This kind of wrapping attacks are possible as the attacker jumbles
the position of signed elements within the document as XML signature
process defined by specification takes only ID into consideration for
referencing the signed elements. The proposed algorithm suggests
using "Absolute XPath" for referencing the signed elements as well as
doping the elements subjected to be signed with it. Hence, the
digest of the signed element inside node has a trail of
the position of element; refer step-6 of algorithm in Section 3.1.
Hence, any changes in the position of signed elements by the
attackers will invalidate the signature validation; refer step-12 of
algorithm in Section 3.2 , because calculated digest during signature
validation will not match with the digest contained in
of the forged SOAP request.
5. Conclusion
XML Signature wrapping attacks try to inject forged elements into the
XML document structure in such a way that the valid signature covers
the unmodified elements, while forged elements are processed by the
application logic. This results in a scenario, where an attacker can
perform arbitrary web service requests, while authenticating as a
legitimate user. The proposed algorithm takes help of the absolute
XPath as a "Positional Token" for identifying the signed elements and
adding this to the elements to be signed as an attribute before the
canonicalization process has a trace of both content of signed
element and its position in the XML document as well. Hence, the
Jitendra Kumar, et al. Expires August 19, 2018 [Page 6]
Internet-Draft Abbreviated Title February 2018
proposed algorithm can solve the issue of XML wrapping attacks
elegantly without much change in the current standard.
6. IANA Considerations
This memo includes no request to IANA.
7. Security Considerations
This draft proposes a modification to the existing algorithm of XML
signature to counter XML Signature wrapping attacks. However other
forms of attack may be possible that could not be mitigated.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
.
[RFC2807] Reagle, J., "XML Signature Requirements", RFC 2807,
DOI 10.17487/RFC2807, July 2000,
.
[RFC3275] Eastlake 3rd, D., Reagle, J., and D. Solo, "(Extensible
Markup Language) XML-Signature Syntax and Processing",
RFC 3275, DOI 10.17487/RFC3275, March 2002,
.
8.2. Informative References
[I-D.narten-iana-considerations-rfc2434bis]
Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", draft-narten-iana-
considerations-rfc2434bis-09 (work in progress), March
2008.
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
DOI 10.17487/RFC2629, June 1999,
.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552,
DOI 10.17487/RFC3552, July 2003,
.
Jitendra Kumar, et al. Expires August 19, 2018 [Page 7]
Internet-Draft Abbreviated Title February 2018
[wrapping_attack]
McIntosh, Michael. and Paula. Austel, "XML signature
element wrapping attacks and countermeasures", 2005,
.
[WS-Security]
OASIS., "OASIS Web Services Security (WSS) TC", 2006,
.
Authors' Addresses
Jitendra Kumar
C-DAC Bangalore
#68, Electronics City Hosur Road
Bangalore 560100
India
Email: jitendra@cdac.in
Balaji Rajendran
C-DAC Bangalore
#68, Electronics City Hosur Road
Bangalore 560100
India
Email: baaji@cdac.in
Bindhumadhava BS
C-DAC Bangalore
Old Madras Road, Opposite Hal Aero Engine Division
Bangalore 560038
India
Email: bindhu@cdac.in
Jitendra Kumar, et al. Expires August 19, 2018 [Page 8]