| 失效链接处理 |
|
java core libraries developer guide PDF 下载
本站整理下载：
提取码：lhb6
相关截图：
主要内容：
Serialization Filtering
You can use the Java serialization filtering mechanism to help prevent deserialization
vulnerabilities. You can define pattern-based filters or you can create custom filters.
Topics:
• Addressing Deserialization Vulnerabilities
• Java Serialization Filters
• Whitelists and Blacklists
• Creating Pattern-Based Filters
• Creating Custom Filters
• Built-in Filters
• Logging Filter Actions
Addressing Deserialization Vulnerabilities
An application that accepts untrusted data and deserializes it is vulnerable to attacks.
You can create filters to screen incoming streams of serialized objects before they are
deserialized.
An object is serialized when its state is converted to a byte stream. That stream can be
sent to a file, to a database, or over a network. A Java object is serializable if its class
or any of its superclasses implements either the java.io.Serializable interface
or the java.io.Externalizable subinterface. In the JDK, serialization is used in
many areas, including Remote Method Invocation (RMI), custom RMI for interprocess
communication (IPC) protocols (such as the Spring HTTP invoker), Java Management
Extensions (JMX), and Java Messaging Service (JMS).
An object is deserialized when its serialized form is converted to a copy of the object. It
is important to ensure the security of this conversion. Deserialization is code
execution, because the readObject method of the class that is being deserialized
can contain custom code. Serializable classes, also known as "gadget classes", can
do arbitrary reflective actions such as create classes and invoke methods on them. If
your application deserializes these classes, they can cause a denial of service or
remote code execution.
When you create a filter, you can specify which classes are acceptable to an
application, and which should be rejected. You can control the object graph size and
complexity during deserialization so that the object graph doesn’t exceed reasonable
limits. Filters can be configured as properties, or implemented programmatically.
Besides creating filters, you can take the following actions to help prevent
deserialization vulnerabilities:
• Do not deserialized untrusted data.
• Use SSL to encrypt and authenticate the connections between applications.
2-1
• Validate field values before assignment, including checking object invariants by
using the readObject method.
Note:
Built-in filters are provided for RMI. However, you should use these built-in
filters as starting points only. Configure blacklists and/or extend the whitelist
to add additional protection for your application that uses RMI. See Built-in
Filters.
For more information about these and other strategies, see "Serialization and
Deserialization" in Secure Coding Guidelines for Java SE.
Java Serialization Filters
The Java serialization filtering mechanism screens incoming streams of serialized
objects to help improve security and robustness. Filters can validate incoming classes
before they are deserialized.
As stated in JEP 290, the goals of the Java serialization filtering mechanism are to:
• Provide a way to narrow the classes that can be deserialized down to a contextappropriate set of classes.
• Provide metrics to the filter for graph size and complexity during deserialization to
validate normal graph behaviors.
• Allow RMI-exported objects to validate the classes expected in invocations.
You can implement serialization filters in the following ways:
• Pattern-based filters do not require you to modify your application. They consist of
a sequence of patterns that are defined in properties, in a configuration file or on
the command line. Pattern-based filters can accept or reject specific classes,
packages, or modules. They can place limits on array sizes, graph depth, total
references, and stream size. A typical use case is to blacklist classes that have
been identified as potentially compromising the Java runtime. Pattern-based filters
are defined for one application or all applications in a process.
• Custom filters are implemented using the ObjectInputFilter API. They allow
an application to integrate finer control than pattern-based filters, because they
can be specific to each ObjectInputStream. Custom filters are set on an
individual input stream or on all streams in a process.
The filter mechanism is called for each new object in the stream. If more than one
active filter (process-wide filter, application filter, or stream-specific filter) exists, only
the most specific filter is called.
In most cases, a custom filter should check if a process-wide filter is set. If one exists,
the custom filter should invoke it and use the process-wide filter’s result, unless the
status is UNDECIDED.
Support for serialization filters is included starting with JDK 9, and in Java CPU
releases starting with 8u121, 7u131, and 6u141.
Chapter 2
Java Serialization Filters
2-2
Whitelists and Blacklists
Whitelists and blacklists can be implemented using pattern-based filters or custom
filters. These lists allow you to take proactive and defensive approaches to protect
your applications.
The proactive approach uses whitelists to accept only the classes that are recognized
and trusted. You can implement whitelists in your code when you develop your
application, or later by defining pattern-based filters. If your application only deals with
a small set of classes then this approach can work very well. You can implement
whitelists by specifying the classes, packages, or modules that are allowed.
The defensive approach uses blacklists to reject classes that are not trusted. Usually,
blacklists are implemented after an attack that reveals that a class is a problem. A
class can be added to a blacklist, without a code change, by defining a pattern-based
filter.
Creating Pattern-Based Filters
Pattern-based filters are filters that you define without changing your application code.
You add process-wide filters in properties files, or application-specific filters on the
java command line.
A pattern-based filter is a sequence of patterns. Each pattern is matched against the
name of a class in the stream or a resource limit. Class-based and resource limit
patterns can be combined in one filter string, with each pattern separated by a
semicolon (;).
Pattern-based Filter Syntax
When you create a filter that is composed of patterns, use the following guidelines:
• Separate patterns by semicolons. For example:
pattern1.*;pattern2.*
• White space is significant and is considered part of the pattern.
• Put the limits first in the string. They are evaluated first regardless of where they
are in the string, so putting them first reinforces the ordering. Otherwise, patterns
are evaluated from left to right.
• A class that matches a pattern that is preceded by ! is rejected. A class that
matches a pattern without ! is accepted. The following filter rejects
pattern1.MyClass but accepts pattern2.MyClass:
!pattern1.*;pattern2.*
• Use the wildcard symbol (*) to represent unspecified classes in a pattern as
shown in the following examples:
– To match every class, use * – To match every class in mypackage, use mypackage.*
– To match every class in mypackage and its subpackages, use mypackage.**
Chapter 2
Whitelists and Blacklists
2-3
– To match every class that starts with text, use text*
If a class doesn’t match any filter, then it is accepted. If you want to accept only certain
classes, then your filter must reject everything that doesn’t match. To reject all classes
other than those specified, include !* as the last pattern in a class filter.
For a complete description of the syntax for the patterns, see the conf/security/
java.security file, or see JEP 290.
Pattern-Based Filter Limitations
Pattern-based filters are used for simple acceptance or rejection. These filters have
some limitations. For example:
• Patterns can’t allow different sizes of arrays based on the class.
• Patterns can’t match classes based on the supertype or interfaces of the class.
• Patterns have no state and can’t make choices depending on the earlier classes
deserialized in the stream.
Define a Pattern-Based Filter for One Application
You can define a pattern-based filter as a system property for one application. A
system property supersedes a Security Property value.
To create a filter that only applies to one application, and only to a single invocation of
Java, define the jdk.serialFilter system property in the command line.
The following example shows how to limit resource usage for an individual application:
java -
Djdk.serialFilter=maxarray=100000;maxdepth=20;maxrefs=500 com.example.test.
Application
Define a Pattern-Based Filter for All Applications in a Process
You can define a pattern-based filter as a Security Property, for all applications in a
process. A system property supersedes a Security Property value.
1. Edit the java.security properties file.
• JDK 9 and later: $JAVA_HOME/conf/security/java.security
• JDK 8,7,6: $JAVA_HOME/lib/security/java.security
2. Add the pattern to the jdk.serialFilter Security Property.
Define a Class Filter
You can create a pattern-based class filter that is applied globally. For example, the
pattern might be a class name or a package with wildcard.
In the following example, the filter rejects one class from a package (!
example.somepackage.SomeClass), and accepts all other classes in the package:
jdk.serialFilter=!example.somepackage.SomeClass;example.somepackage.*;
|
| Java1234官方群25： | 
|
| Java1234官方群25： | 838462530 |
苏公网安备 32061202001004号
