Issue 1:
Alex Rau opened SPR-7842 and commented

DataBinder which is used by WebRequestDataBinder and ServletRequestDataBinder grows automatically collections when "autoGrowNestedPaths" is on (AFAIK this is the default for the DataBinder).

The behaviour of DataBinder when "autoGrowNestedPaths" is that a property with a given index N will result in growing a collection to size N if the collection is not large enough. Collection elements with index < N will be initialized with default objects of the collection's type.

Based on WebRequestDataBinder it's therefore easily possible to DoS a web application if it's allowed to bind against a collection property and the client POSTs a single property using a very large index.

Sending a single request containing a parameter for a collection property with index 99999999 caused an OOM on a JVM on MacOsX with default memory settings (64MB?). The list type in this case contained 7 String properties and 2 Longs.

I think there are several things to follow-up:

It would be safer to set autoGrowNestedPaths to false by default. Use of DataBinder and autoGrowNestedPaths then would be more restrictive by default and require explicit action to enable autoGrowing.

The creation of "default" values in BeanWrapperImpl should be more flexible. A strategy for creating default values would allow clients to define how such default values should be created. In the case of WebRequestDataBinder creating empty (null) collection elements instead of default objects is certainly safer to fill the gaps in the collection - especially for exposed applications to the public. Furthermore this does not expose unwanted restrictions like a maximum allowed index limitation etc.

Presumably this could be solved with CustomPropertyEditors. However the majority of developers probably tries to stick with what is available out-of-the box and as the DataBinding in general for "standard" use-cases works fine dealing with the described issue is not obvious and could lead to wide-spread holes.

Affects: 3.0.5

Issue Links:

#13022 Can make an OutOfMemoryException by sending a modified form list property with an high index ("is duplicated by")

#10702 Data Binder: Auto-grow collections as needed to support nested property binding

#14862 Limit auto grow collection size when using SpEL

7 votes, 7 watchers

Issue 2:
Colin Sampaleanu opened SPR-1319 and commented

If you try to use one bean factory post-processor it can't actually modify the definion of a 2nd post-processor, even if that one has yet to run. This is because the appcontext as a one time process builds up two lists (ordered and non-ordered) of all the post-processors, and actually creates the objects then. Any modified bean definition past that point will be irrelevant.

I'm not sure this can be resolved without some painful code, but I'm putting the issue here so it can be either marked 'won't resolve' or 'working as intended', or actually fixed, and people can find it when searching.

Here's a snippet of config that shows the problem. In this case, one PropertyPlaceHolderConfigurer modifies the 2nd:

<bean id="fixProperties" class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">

<property name="location" value="classpath:remote-sync-client.properties"/>

<property name="ignoreUnresolvablePlaceholders" value="true"></property>

</bean>

<bean id="variableProperties" class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer" depends-on="fixProperties">
<property name="location" value="file:${remote.sync.data.dir}/client.config"/>
</bean>

<bean id="pathProperties" class="org.springframework.beans.factory.config.PropertiesFactoryBean" depends-on="variableProperties">
<property name="location" value="file:${remote.sync.data.dir}/path.config"/>
</bean>

<bean id="clientConfiguration" class="com.tirawireless.remotesync.client.impl.ClientConfiguration" depends-on="pathProperties">
<property name="id" value="${client.id}"></property>
<property name="password" value="${client.password}"></property>
<property name="serverHost" value="${remote.sync.server.host}"></property>
<property name="serverPort" value="${remote.sync.server.port}"></property>
<property name="dataDirectory" value="${remote.sync.data.dir}"></property>
<property name="syncDirectories">
<ref local="pathProperties"/>
</property>
</bean>

Affects: 1.2.4

Issue Links:

#5782 AbstractApplicationContext shouldn't eagerly instantiate all BeanFactoryPostProcessors ("duplicates")