Spring/spring-framework
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Up-to-date guidelines for serialization-based endpoints

Browse Source 
Issue: SPR-15317
This commit is contained in:
Juergen Hoeller
2017-03-24 11:09:57 +01:00
parent b90d3d0e88
commit 2236262fc6
7 changed files with 59 additions and 43 deletions
Download Patch File Download Diff File Expand all files Collapse all files

12
src/asciidoc/data-access.adoc
View File

@@ -6651,13 +6651,13 @@ which consists of string aliases mapped to classes:
[WARNING]
====
By default, XStream allows for arbitrary classes to be unmarshalled, which can result in
security vulnerabilities. As such, it is __not recommended to use the
By default, XStream allows for arbitrary classes to be unmarshalled, which can lead to
unsafe Java serialization effects. As such, it is __not recommended to use the
`XStreamMarshaller` to unmarshal XML from external sources__ (i.e. the Web), as this can
result in __security vulnerabilities__. If you do use the `XStreamMarshaller` to
unmarshal XML from an external source, set the `supportedClasses` property on the
`XStreamMarshaller`, like so:
result in __security vulnerabilities__.
If you choose to use the `XStreamMarshaller` to unmarshal XML from an external source,
set the `supportedClasses` property on the `XStreamMarshaller`, like as follows:
[source,xml,indent=0]
[subs="verbatim,quotes"]

20
src/asciidoc/integration.adoc
View File

@@ -377,6 +377,21 @@ advanced and easier-to-use functionality. Refer to
http://hc.apache.org/httpcomponents-client-ga/[hc.apache.org/httpcomponents-client-ga/]
for more information.
[WARNING]
====
Be aware of vulnerabilities due to unsafe Java deserialization:
Manipulated input streams could lead to unwanted code execution on the server
during the deserialization step. As a consequence, do not expose HTTP invoker
endpoints to untrusted clients but rather just between your own services.
In general, we strongly recommend any other message format (e.g. JSON) instead.
If you are concerned about security vulnerabilities due to Java serialization,
consider the general-purpose serialization filter mechanism at the core JVM level,
originally developed for JDK 9 but backported to JDK 8, 7 and 6 in the meantime:
https://blogs.oracle.com/java-platform-group/entry/incoming_filter_serialization_data_a
http://openjdk.java.net/jeps/290
====
[[remoting-httpinvoker-server]]
@@ -2499,7 +2514,7 @@ be obtained from JNDI instead (using `<jee:jndi-lookup>`). The Spring-based mess
listeners can then interact with the server-hosted `ResourceAdapter`, also using the
server's built-in `WorkManager`.
Please consult the JavaDoc for `JmsMessageEndpointManager`, `JmsActivationSpecConfig`,
Please consult the javadoc for `JmsMessageEndpointManager`, `JmsActivationSpecConfig`,
and `ResourceAdapterFactoryBean` for more details.
Spring also provides a generic JCA message endpoint manager which is not tied to JMS:
@@ -2507,7 +2522,7 @@ Spring also provides a generic JCA message endpoint manager which is not tied to
for using any message listener type (e.g. a CCI MessageListener) and any
provider-specific ActivationSpec object. Check out your JCA provider's documentation to
find out about the actual capabilities of your connector, and consult
`GenericMessageEndpointManager`'s JavaDoc for the Spring-specific configuration details.
`GenericMessageEndpointManager`'s javadoc for the Spring-specific configuration details.
[NOTE]
====
@@ -5966,7 +5981,6 @@ along with an inline image.
[WARNING]
====
Inline resources are added to the mime message using the specified `Content-ID` (
`identifier1234` in the above example). The order in which you are adding the text and
the resource are __very__ important. Be sure to __first add the text__ and after that