From f6288be1fee1205adbfa5bb345cab624e361c735 Mon Sep 17 00:00:00 2001 From: sebastien-andrivet-sonarsource Date: Wed, 27 Sep 2023 14:13:29 +0200 Subject: [PATCH 1/4] Change text to fit LaYC format. --- rules/S6377/description.adoc | 16 ---------- rules/S6377/java/metadata.json | 7 +---- rules/S6377/java/rule.adoc | 54 +++++++++++++++++++++++++++++----- rules/S6377/rule.adoc | 10 ------- 4 files changed, 48 insertions(+), 39 deletions(-) delete mode 100644 rules/S6377/description.adoc delete mode 100644 rules/S6377/rule.adoc diff --git a/rules/S6377/description.adoc b/rules/S6377/description.adoc deleted file mode 100644 index f07f0b8ef9c..00000000000 --- a/rules/S6377/description.adoc +++ /dev/null @@ -1,16 +0,0 @@ -XML signature validations work by parsing third-party data that cannot be trusted until it is actually validated. - -As with any other parsing process, unrestricted validation of third-party XML signatures can lead to security vulnerabilities. In this case, threats range from denial of service to confidentiality breaches. - -By default, the Java XML Digital Signature API does not apply restrictions on XML signature validation, unless the application runs with a security manager. + -To protect the application from these vulnerabilities, set the ``org.jcp.xml.dsig.secureValidation`` attribute to ``true`` with the ``javax.xml.crypto.dsig.dom.DOMValidateContext.setProperty`` method. + -This attribute ensures that the code enforces the following restrictions: - -* Forbids the use of XSLT transforms -* Restricts the number of ``SignedInfo`` or ``Manifest Reference`` elements to 30 or less -* Restricts the number of ``Reference`` transforms to 5 or less -* Forbids the use of MD5-related signatures or MAC algorithms -* Ensures that ``Reference`` IDs are unique to help prevent signature wrapping attacks -* Forbids Reference URIs of type ``http``, ``https``, or ``file`` -* Does not allow a ``RetrievalMethod`` element to reference another ``RetrievalMethod`` element -* Forbids RSA or DSA keys less than 1024 bits diff --git a/rules/S6377/java/metadata.json b/rules/S6377/java/metadata.json index d72e842293a..ffcd4415b08 100644 --- a/rules/S6377/java/metadata.json +++ b/rules/S6377/java/metadata.json @@ -1,6 +1 @@ -{ - "quickfix": "infeasible", - "tags": [ - "symbolic-execution" - ] -} +{ } diff --git a/rules/S6377/java/rule.adoc b/rules/S6377/java/rule.adoc index f6027eeaea0..91f16a8cced 100644 --- a/rules/S6377/java/rule.adoc +++ b/rules/S6377/java/rule.adoc @@ -1,10 +1,29 @@ +XML signatures are a method used to ensure the integrity and authenticity of XML documents. However, if XML signatures are not validated securely, it can lead to potential vulnerabilities. + == Why is this an issue? -include::../description.adoc[] +Before Java 17, XML Digital Signature API does not apply restrictions on XML signature validation, unless the application runs with a security manager which is rare. This can have several consequences: + +=== Increased Vulnerability to Signature Spoofing + +By disabling secure validation, the Java application becomes more susceptible to signature spoofing attacks. Attackers can potentially manipulate the XML signature in a way that bypasses the validation process, allowing them to forge or tamper with the signature. This can lead to the acceptance of invalid or maliciously modified signatures, compromising the integrity and authenticity of the XML documents. + +=== Risk of Injection Attacks + +Disabling secure validation can expose the application to injection attacks. Attackers can inject malicious code or entities into the XML document, taking advantage of the weakened validation process. In some cases, it can also expose the application to denial of service attacks. Attackers can exploit vulnerabilities in the validation process to cause excessive resource consumption or system crashes, leading to service unavailability or disruption. + + +== How to fix it in Java SE + +=== Code examples + +For versions of Java before 17, secure validation is disabled by default unless the application runs with a security manager which is rare. It should be enabled explicitly by setting the ``org.jcp.xml.dsig.secureValidation`` attribute to true with the ``javax.xml.crypto.dsig.dom.DOMValidateContext.setProperty`` method. -=== Noncompliant code example +For Java 17 and higher, secure validation is enabled by default. -[source,java] +==== Noncompliant code example + +[source,java,diff-id=1,diff-type=noncompliant] ---- NodeList signatureElement = doc.getElementsByTagNameNS(XMLSignature.XMLNS, "Signature"); @@ -15,10 +34,9 @@ XMLSignature signature = fac.unmarshalXMLSignature(valContext); boolean signatureValidity = signature.validate(valContext); ---- -=== Compliant solution -In order to benefit from this secure validation mode, set the DOMValidateContext's ``org.jcp.xml.dsig.secureValidation`` property to ``TRUE``. +==== Compliant solution -[source,java] +[source,java,diff-id=1,diff-type=compliant] ---- NodeList signatureElement = doc.getElementsByTagNameNS(XMLSignature.XMLNS, "Signature"); @@ -30,13 +48,35 @@ XMLSignature signature = fac.unmarshalXMLSignature(valContext); boolean signatureValidity = signature.validate(valContext); ---- +=== How does this work? + +When XML Signature secure validation mode is enabled, XML Signatures are processed more securely. It enforces the following restrictions: + +* Forbids the use of XSLT transforms +* Restricts the number of ``SignedInfo`` or ``Manifest Reference`` elements to 30 or less +* Restricts the number of ``Reference`` transforms to 5 or less +* Forbids the use of MD5-related signatures or MAC algorithms +* Ensures that ``Reference`` IDs are unique to help prevent signature wrapping attacks +* Forbids Reference URIs of type ``http``, ``https``, or ``file`` +* Does not allow a ``RetrievalMethod`` element to reference another ``RetrievalMethod`` element +* Forbids RSA or DSA keys less than 1024 bits + +These restrictions can protect you from XML Signatures that may contain potentially hostile constructs that can cause denial-of-service or other types of security issues. == Resources -* https://docs.oracle.com/en/java/javase/14/security/java-xml-digital-signature-api-overview-and-tutorial.html#GUID-DB46A001-6DBD-4571-BDBC-1BBC394BF61E[Oracle Java Documentation] - XML Digital Signature API Overview and Tutorial +=== Documentation + +* https://docs.oracle.com/en/java/javase/21/security/java-xml-digital-signature-api-overview-and-tutorial.html[Oracle Java Documentation] - XML Digital Signature API Overview and Tutorial + +=== Standards + +* https://owasp.org/Top10/A02_2021-Cryptographic_Failures/[OWASP + Top 10:2021 A02:2021] - Cryptographic Failures * https://owasp.org/www-project-top-ten/2017/A3_2017-Sensitive_Data_Exposure[OWASP Top 10 2017 Category A3] - Sensitive Data Exposure * https://cwe.mitre.org/data/definitions/347[MITRE, CWE-347] - Improper Verification of Cryptographic Signature + ifdef::env-github,rspecator-view[] ''' diff --git a/rules/S6377/rule.adoc b/rules/S6377/rule.adoc deleted file mode 100644 index bbf8f52d178..00000000000 --- a/rules/S6377/rule.adoc +++ /dev/null @@ -1,10 +0,0 @@ -== Why is this an issue? - -include::description.adoc[] - -== Resources - -* https://owasp.org/www-project-top-ten/2017/A3_2017-Sensitive_Data_Exposure[OWASP Top 10 2017 Category A3] - Sensitive Data Exposure -* https://cwe.mitre.org/data/definitions/347[MITRE, CWE-347] - Improper Verification of Cryptographic Signature - - From 29726e1c7c2420fc3fadcbf778d4ced9e0acc0cf Mon Sep 17 00:00:00 2001 From: sebastien-andrivet-sonarsource Date: Fri, 29 Sep 2023 15:38:53 +0200 Subject: [PATCH 2/4] Put back metadata. --- rules/S6377/java/metadata.json | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/rules/S6377/java/metadata.json b/rules/S6377/java/metadata.json index ffcd4415b08..ca1da9aca73 100644 --- a/rules/S6377/java/metadata.json +++ b/rules/S6377/java/metadata.json @@ -1 +1,6 @@ -{ } +{ + "quickfix": "infeasible", + "tags": [ + "symbolic-execution" + ] +} \ No newline at end of file From 37745fd947608bd9e63f642dd1d7c8c5e562e46f Mon Sep 17 00:00:00 2001 From: sebastien-andrivet-sonarsource Date: Fri, 29 Sep 2023 15:40:29 +0200 Subject: [PATCH 3/4] Add the missing section and clarify the text. --- rules/S6377/java/rule.adoc | 21 ++++++++------------- 1 file changed, 8 insertions(+), 13 deletions(-) diff --git a/rules/S6377/java/rule.adoc b/rules/S6377/java/rule.adoc index 91f16a8cced..dff41926f36 100644 --- a/rules/S6377/java/rule.adoc +++ b/rules/S6377/java/rule.adoc @@ -2,7 +2,11 @@ XML signatures are a method used to ensure the integrity and authenticity of XML == Why is this an issue? -Before Java 17, XML Digital Signature API does not apply restrictions on XML signature validation, unless the application runs with a security manager which is rare. This can have several consequences: +Before Java 17, XML Digital Signature API does not apply restrictions on XML signature validation unless the application runs with a security manager, which is rare. + +== What is the potential impact + +By not enforcing secure validation, the XML Digital Signature API is more susceptible to attacks such as signature spoofing and injections. === Increased Vulnerability to Signature Spoofing @@ -10,14 +14,14 @@ By disabling secure validation, the Java application becomes more susceptible to === Risk of Injection Attacks -Disabling secure validation can expose the application to injection attacks. Attackers can inject malicious code or entities into the XML document, taking advantage of the weakened validation process. In some cases, it can also expose the application to denial of service attacks. Attackers can exploit vulnerabilities in the validation process to cause excessive resource consumption or system crashes, leading to service unavailability or disruption. +Disabling secure validation can expose the application to injection attacks. Attackers can inject malicious code or entities into the XML document, taking advantage of the weakened validation process. In some cases, it can also expose the application to denial-of-service attacks. Attackers can exploit vulnerabilities in the validation process to cause excessive resource consumption or system crashes, leading to service unavailability or disruption. == How to fix it in Java SE === Code examples -For versions of Java before 17, secure validation is disabled by default unless the application runs with a security manager which is rare. It should be enabled explicitly by setting the ``org.jcp.xml.dsig.secureValidation`` attribute to true with the ``javax.xml.crypto.dsig.dom.DOMValidateContext.setProperty`` method. +For versions of Java before 17, secure validation is disabled by default unless the application runs with a security manager, which is rare. It should be enabled explicitly by setting the ``org.jcp.xml.dsig.secureValidation`` attribute to true with the ``javax.xml.crypto.dsig.dom.DOMValidateContext.setProperty`` method. For Java 17 and higher, secure validation is enabled by default. @@ -50,16 +54,7 @@ boolean signatureValidity = signature.validate(valContext); === How does this work? -When XML Signature secure validation mode is enabled, XML Signatures are processed more securely. It enforces the following restrictions: - -* Forbids the use of XSLT transforms -* Restricts the number of ``SignedInfo`` or ``Manifest Reference`` elements to 30 or less -* Restricts the number of ``Reference`` transforms to 5 or less -* Forbids the use of MD5-related signatures or MAC algorithms -* Ensures that ``Reference`` IDs are unique to help prevent signature wrapping attacks -* Forbids Reference URIs of type ``http``, ``https``, or ``file`` -* Does not allow a ``RetrievalMethod`` element to reference another ``RetrievalMethod`` element -* Forbids RSA or DSA keys less than 1024 bits +When XML Signature secure validation mode is enabled, XML Signatures are processed more securely. It enforces a number of restrictionsto to protect from XML Documents that may contain hostile constructs that can cause denial-of-service or other types of security issues. These restrictions can protect you from XML Signatures that may contain potentially hostile constructs that can cause denial-of-service or other types of security issues. From 854e6efe970a12cdf382d1e97647b61baee6e74c Mon Sep 17 00:00:00 2001 From: sebastien-andrivet-sonarsource Date: Fri, 29 Sep 2023 15:42:37 +0200 Subject: [PATCH 4/4] Format properly the links --- rules/S6377/java/rule.adoc | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/rules/S6377/java/rule.adoc b/rules/S6377/java/rule.adoc index dff41926f36..10f824f81fe 100644 --- a/rules/S6377/java/rule.adoc +++ b/rules/S6377/java/rule.adoc @@ -62,14 +62,13 @@ These restrictions can protect you from XML Signatures that may contain potentia === Documentation -* https://docs.oracle.com/en/java/javase/21/security/java-xml-digital-signature-api-overview-and-tutorial.html[Oracle Java Documentation] - XML Digital Signature API Overview and Tutorial +* Oracle Java Documentation - https://docs.oracle.com/en/java/javase/21/security/java-xml-digital-signature-api-overview-and-tutorial.html[XML Digital Signature API Overview and Tutorial] === Standards -* https://owasp.org/Top10/A02_2021-Cryptographic_Failures/[OWASP - Top 10:2021 A02:2021] - Cryptographic Failures -* https://owasp.org/www-project-top-ten/2017/A3_2017-Sensitive_Data_Exposure[OWASP Top 10 2017 Category A3] - Sensitive Data Exposure -* https://cwe.mitre.org/data/definitions/347[MITRE, CWE-347] - Improper Verification of Cryptographic Signature +* OWASP - https://owasp.org/Top10/A02_2021-Cryptographic_Failures/[Top 10:2021 A02:2021 - Cryptographic Failures] +* OWASP - https://owasp.org/www-project-top-ten/2017/A3_2017-Sensitive_Data_Exposure[Top 10 2017 Category A3 -Sensitive Data Exposure] +* CWE - https://cwe.mitre.org/data/definitions/347[CWE-347 - Improper Verification of Cryptographic Signature] ifdef::env-github,rspecator-view[]