Merge pull request #21807 from owen-mc/java/improve-qhelp-unsafe-deserialization

Shared: improve qhelp for unsafe deserialization queries

csharp/ql/src/Security Features/CWE-502/UnsafeDeserialization.qhelp

@@ -7,6 +7,17 @@
 <p>Deserializing an object from untrusted input may result in security problems, such
 as denial of service or remote code execution.</p>
 
+<p>
+Note that a deserialization method is only dangerous if it can instantiate
+arbitrary classes. Serialization frameworks that use a schema to instantiate
+only expected, predefined types are generally not tracked by this query. Such
+frameworks are generally safe with respect to arbitrary-class-instantiation and
+gadget-chain attacks when the schema is trusted and does not permit
+user-controlled type resolution. However, care must be taken to ensure the schema
+strictly limits the allowed types. Permitting common standard library classes
+can still leave the application vulnerable to gadget-chain attacks.
+</p>
+
 </overview>
 <recommendation>
 

csharp/ql/src/Security Features/CWE-502/UnsafeDeserializationUntrustedInput.qhelp

@@ -7,6 +7,17 @@
 <p>Deserializing an object from untrusted input may result in security problems, such
 as denial of service or remote code execution.</p>
 
+<p>
+Note that a deserialization method is only dangerous if it can instantiate
+arbitrary classes. Serialization frameworks that use a schema to instantiate
+only expected, predefined types are generally not tracked by this query. Such
+frameworks are generally safe with respect to arbitrary-class-instantiation and
+gadget-chain attacks when the schema is trusted and does not permit
+user-controlled type resolution. However, care must be taken to ensure the schema
+strictly limits the allowed types. Permitting common standard library classes
+can still leave the application vulnerable to gadget-chain attacks.
+</p>
+
 </overview>
 <recommendation>
 

java/ql/src/Security/CWE/CWE-502/UnsafeDeserialization.qhelp

@@ -5,26 +5,37 @@
 <p>
 Deserializing untrusted data using any deserialization framework that
 allows the construction of arbitrary serializable objects is easily exploitable
-and in many cases allows an attacker to execute arbitrary code.  Even before a
+and in many cases allows an attacker to execute arbitrary code. Even before a
 deserialized object is returned to the caller of a deserialization method a lot
 of code may have been executed, including static initializers, constructors,
-and finalizers.  Automatic deserialization of fields means that an attacker may
+and finalizers. Automatic deserialization of fields means that an attacker may
 craft a nested combination of objects on which the executed initialization code
 may have unforeseen effects, such as the execution of arbitrary code.
 </p>
 <p>
-There are many different serialization frameworks.  This query currently
+There are many different serialization frameworks. This query currently
 supports Kryo, XmlDecoder, XStream, SnakeYaml, JYaml, JsonIO, YAMLBeans, HessianBurlap, Castor, Burlap,
 Jackson, Jabsorb, Jodd JSON, Flexjson, Gson, JMS, and Java IO serialization through
 <code>ObjectInputStream</code>/<code>ObjectOutputStream</code>.
 </p>
+<p>
+Note that a deserialization method is only dangerous if it can instantiate
+arbitrary classes. Serialization frameworks that use a schema to instantiate
+only expected, predefined types are generally not tracked by this query. For
+example, Apache Avro's deserialization methods follow a schema and are
+therefore generally safe with respect to arbitrary-class-instantiation and
+gadget-chain attacks when the schema is trusted and does not permit
+user-controlled type resolution. However, care must be taken to ensure the schema
+strictly limits the allowed types. Permitting common standard library classes
+can still leave the application vulnerable to gadget-chain attacks.
+</p>
 </overview>
 
 <recommendation>
 <p>
-Avoid deserialization of untrusted data if at all possible.  If the
+Avoid deserialization of untrusted data if at all possible. If the
 architecture permits it then use other formats instead of serialized objects,
-for example JSON or XML.  However, these formats should not be deserialized
+for example JSON or XML. However, these formats should not be deserialized
 into complex objects because this provides further opportunities for attack.
 For example, XML-based deserialization attacks
 are possible through libraries such as XStream and XmlDecoder.
@@ -43,7 +54,7 @@ Recommendations specific to particular frameworks supported by this query:
         <li><b>Recommendation</b>: Call <code>com.alibaba.fastjson.parser.ParserConfig#setSafeMode</code> with the argument <code>true</code> before deserializing untrusted data.</li>
     </ul>
 <p></p>
-<p><b>FasterXML</b> -  <code>com.fasterxml.jackson.core:jackson-databind</code></p>
+<p><b>FasterXML</b> - <code>com.fasterxml.jackson.core:jackson-databind</code></p>
     <ul>
         <li><b>Secure by Default</b>: Yes</li>
         <li><b>Recommendation</b>: Don't call <code>com.fasterxml.jackson.databind.ObjectMapper#enableDefaultTyping</code> and don't annotate any object fields with <code>com.fasterxml.jackson.annotation.JsonTypeInfo</code> passing either the <code>CLASS</code> or <code>MINIMAL_CLASS</code> values to the annotation.
@@ -56,16 +67,16 @@ Recommendations specific to particular frameworks supported by this query:
         <li><b>Recommendation</b>: Don't call <code>com.esotericsoftware.kryo(5).Kryo#setRegistrationRequired</code> with the argument <code>false</code> on any <code>Kryo</code> instance that may deserialize untrusted data.</li>
     </ul>
 <p></p>
-<p><b>ObjectInputStream</b> -  <code>Java Standard Library</code></p>
+<p><b>ObjectInputStream</b> - <code>Java Standard Library</code></p>
     <ul>
         <li><b>Secure by Default</b>: No</li>
-        <li><b>Recommendation</b>: Use a validating input stream, such as  <code>org.apache.commons.io.serialization.ValidatingObjectInputStream</code>.</li>
+        <li><b>Recommendation</b>: Use a validating input stream, such as <code>org.apache.commons.io.serialization.ValidatingObjectInputStream</code>.</li>
     </ul>
 <p></p>
 <p><b>SnakeYAML</b> - <code>org.yaml:snakeyaml</code></p>
     <ul>
         <li><b>Secure by Default</b>: As of version 2.0.</li>
-        <li><b>Recommendation</b>: For versions before 2.0, pass an instance of <code>org.yaml.snakeyaml.constructor.SafeConstructor</code> to  <code>org.yaml.snakeyaml.Yaml</code>'s constructor before using it to deserialize untrusted data.</li>
+        <li><b>Recommendation</b>: For versions before 2.0, pass an instance of <code>org.yaml.snakeyaml.constructor.SafeConstructor</code> to <code>org.yaml.snakeyaml.Yaml</code>'s constructor before using it to deserialize untrusted data.</li>
     </ul>
 <p></p>
 <p><b>XML Decoder</b> - <code>Standard Java Library</code></p>

python/ql/src/Security/CWE-502/UnsafeDeserialization.qhelp

@@ -5,22 +5,32 @@
 <p>
 Deserializing untrusted data using any deserialization framework that
 allows the construction of arbitrary serializable objects is easily exploitable
-and in many cases allows an attacker to execute arbitrary code.  Even before a
+and in many cases allows an attacker to execute arbitrary code. Even before a
 deserialized object is returned to the caller of a deserialization method a lot
 of code may have been executed, including static initializers, constructors,
-and finalizers.  Automatic deserialization of fields means that an attacker may
+and finalizers. Automatic deserialization of fields means that an attacker may
 craft a nested combination of objects on which the executed initialization code
 may have unforeseen effects, such as the execution of arbitrary code.
 </p>
 <p>
-There are many different serialization frameworks.  This query currently
+There are many different serialization frameworks. This query currently
 supports Pickle, Marshal and Yaml.
 </p>
+<p>
+Note that a deserialization method is only dangerous if it can instantiate
+arbitrary classes. Serialization frameworks that use a schema to instantiate
+only expected, predefined types are generally not tracked by this query. Such
+frameworks are generally safe with respect to arbitrary-class-instantiation and
+gadget-chain attacks when the schema is trusted and does not permit
+user-controlled type resolution. However, care must be taken to ensure the schema
+strictly limits the allowed types. Permitting common standard library classes
+can still leave the application vulnerable to gadget-chain attacks.
+</p>
 </overview>
 
 <recommendation>
 <p>
-Avoid deserialization of untrusted data if at all possible.  If the
+Avoid deserialization of untrusted data if at all possible. If the
 architecture permits it then use other formats instead of serialized objects,
 for example JSON.
 </p>

ruby/ql/src/queries/security/cwe-502/UnsafeDeserialization.qhelp

@@ -7,6 +7,16 @@ Deserializing untrusted data using any method that allows the construction of
 arbitrary objects is easily exploitable and, in many cases, allows an attacker
 to execute arbitrary code.
 </p>
+<p>
+Note that a deserialization method is only dangerous if it can instantiate
+arbitrary classes or objects. Serialization frameworks that use a schema to instantiate
+only expected, predefined types are generally not tracked by this query. Such
+frameworks are generally safe with respect to arbitrary-class-instantiation and
+gadget-chain attacks when the schema is trusted and does not permit
+user-controlled type resolution. However, care must be taken to ensure the schema
+strictly limits the allowed types. Permitting common standard library classes
+can still leave the application vulnerable to gadget-chain attacks.
+</p>
 </overview>
 
 <recommendation>
@@ -31,7 +41,7 @@ safely be used.
 If deserializing an untrusted XML document using the <code>ox</code> gem,
 do not use <code>parse_obj</code> and <code>load</code> using the non-default :object mode.
 Instead use the <code>load</code> method in the default mode or better explicitly set a safe
-mode such as :hash. 
+mode such as :hash.
 </p>
 
 <p>