You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: java/ql/src/experimental/Security/CWE/CWE-502/SpringHttpInvokerUnsafeDeserialization.qhelp
+4-4Lines changed: 4 additions & 4 deletions
Original file line number
Diff line number
Diff line change
@@ -3,14 +3,14 @@
3
3
4
4
<overview>
5
5
<p>
6
-
Spring Framework provides an abstract base class <code>RemoteInvocationSerializingExporter</code>
6
+
The Spring Framework provides an abstract base class <code>RemoteInvocationSerializingExporter</code>
7
7
for defining remote service exporters.
8
8
A Spring exporter, which is based on this class, deserializes incoming data using <code>ObjectInputStream</code>.
9
9
Deserializing untrusted data is easily exploitable and in many cases allows an attacker
10
10
to execute arbitrary code.
11
11
</p>
12
12
<p>
13
-
Spring Framework also provides two classes that extend <code>RemoteInvocationSerializingExporter</code>:
13
+
The Spring Framework also provides two classes that extend <code>RemoteInvocationSerializingExporter</code>:
14
14
<li>
15
15
<code>HttpInvokerServiceExporter</code>
16
16
</li>
@@ -24,7 +24,7 @@ using unsafe <code>ObjectInputStream</code>. If a remote attacker can reach such
24
24
it results in remote code execution in the worst case.
25
25
</p>
26
26
<p>
27
-
CVE-2016-1000027 has been assigned to this issue in Spring Framework. There is no fix for that.
27
+
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.
28
28
</p>
29
29
</overview>
30
30
@@ -36,7 +36,7 @@ Instead, use other message formats for API endpoints (for example, JSON),
36
36
but make sure that the underlying deserialization mechanism is properly configured
37
37
so that deserialization attacks are not possible. If the vulnerable exporters can not be replaced,
38
38
consider using global deserialization filters introduced by JEP 290.
39
-
In general, avoid deserialization of untrusted data.
39
+
In general, avoid using Java's built-in deserialization methods on untrusted data.
0 commit comments