From bda223771bddcdc2d67b86714d76d0faf895ffda Mon Sep 17 00:00:00 2001
From: Artem Smotrakov <artem.smotrakov@gmail.com>
Date: Sat, 6 Mar 2021 22:05:00 +0100
Subject: [PATCH] Added another example for
 SpringExporterUnsafeDeserialization.ql

---
 .../SpringExporterUnsafeDeserialization.qhelp     | 15 ++++++++++-----
 .../SpringExporterUnsafeDeserialization.xml       |  4 ++++
 2 files changed, 14 insertions(+), 5 deletions(-)
 create mode 100644 java/ql/src/experimental/Security/CWE/CWE-502/SpringExporterUnsafeDeserialization.xml

diff --git a/java/ql/src/experimental/Security/CWE/CWE-502/SpringExporterUnsafeDeserialization.qhelp b/java/ql/src/experimental/Security/CWE/CWE-502/SpringExporterUnsafeDeserialization.qhelp
index ffb8dddae56..da681b7125c 100644
--- a/java/ql/src/experimental/Security/CWE/CWE-502/SpringExporterUnsafeDeserialization.qhelp
+++ b/java/ql/src/experimental/Security/CWE/CWE-502/SpringExporterUnsafeDeserialization.qhelp
@@ -4,7 +4,7 @@
 <overview>
 <p>
 The Spring Framework provides an abstract base class <code>RemoteInvocationSerializingExporter</code>
-for defining remote service exporters.
+for creating remote service exporters.
 A Spring exporter, which is based on this class, deserializes incoming data using <code>ObjectInputStream</code>.
 Deserializing untrusted data is easily exploitable and in many cases allows an attacker
 to execute arbitrary code.
@@ -24,7 +24,8 @@ using unsafe <code>ObjectInputStream</code>. If a remote attacker can reach such
 it results in remote code execution in the worst case.
 </p>
 <p>
-CVE-2016-1000027 has been assigned to this issue in the Spring Framework. It is regarded as a design limitation, and can be mitigated but not fixed outright.
+CVE-2016-1000027 has been assigned to this issue in the Spring Framework.
+It is regarded as a design limitation, and can be mitigated but not fixed outright.
 </p>
 </overview>
 
@@ -35,16 +36,20 @@ and any other exporter that is based on <code>RemoteInvocationSerializingExporte
 Instead, use other message formats for API endpoints (for example, JSON),
 but make sure that the underlying deserialization mechanism is properly configured
 so that deserialization attacks are not possible. If the vulnerable exporters can not be replaced,
-consider using global deserialization filters introduced by JEP 290.
-In general, avoid using Java's built-in deserialization methods on untrusted data.
+consider using global deserialization filters introduced in JEP 290.
 </p>
 </recommendation>
 
 <example>
 <p>
-The following example defines a vulnerable HTTP endpoint:
+The following example shows how a vulnerable HTTP endpoint can be defined
+using <code>HttpInvokerServiceExporter</code> and Spring annotations:
 </p>
 <sample src="UnsafeHttpInvokerEndpoint.java" />
+<p>
+The next examples shows how the same vulnerable endpoint can be defined in a Spring XML config:
+</p>
+<sample src="UnsafeHttpInvokerEndpoint.xml" />
 </example>
 
 <references>
diff --git a/java/ql/src/experimental/Security/CWE/CWE-502/SpringExporterUnsafeDeserialization.xml b/java/ql/src/experimental/Security/CWE/CWE-502/SpringExporterUnsafeDeserialization.xml
new file mode 100644
index 00000000000..bf058cfffc1
--- /dev/null
+++ b/java/ql/src/experimental/Security/CWE/CWE-502/SpringExporterUnsafeDeserialization.xml
@@ -0,0 +1,4 @@
+<bean name="/account" class="org.springframework.remoting.httpinvoker.HttpInvokerServiceExporter">
+    <property name="service" ref="accountService"/>
+    <property name="serviceInterface" value="AccountService"/>
+</bean>
\ No newline at end of file