Question

I’m working on an application using Spring security.
The application is extensible and I would like to block extensions from programmatically changing the filters in the filter chain map of Spring’s FilterChainProxy. What I intend to do is the following:

1. Implement a CustomFilterChainProxy implementing all of FilterChainProxy‘s implemented interfaces (Filter, InitializingBean, ApplicationContextAware). In it I will hold a private FilterChainProxy member and delegate all of the interface calls to it.

2. Use Spring’s DelegatingFilterProxy by declaring in the web.xml file:

   <filter>
       <filter-name>customSecurityFilterChain</filter-name>
       <filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
   </filter>
   

3. In the Spring configuration files, instead of using Spring’s FilterChainProxy directly I will have my bean have the CustomFilterChainProxy as its class, as follows:

   <bean id="customSecurityFilterChain" class="....CustomFilterChainProxy">
       <security:filter-chain-map ...>
           <security:filter-chain pattern="..." filters="..." />
           <security:filter-chain pattern="..." filters="..." />
           ...
       </security:filter-chain-map>
   </bean>
   

4. In order to be able to set the filter chain map during Spring bean loading I must supply a setter in my CustomFilterChainProxy class. That I will do. And in order to prevent setting the filter chain map after Spring bean loading I will make sure that after bean construction (in a @PostConstruct method) an exception will be thrown from that setter.

By having a CustomFilterChainProxy instead of a FilterChainProxy, am I causing any Spring process to malfunction?

I saw the only Spring class referencing the FilterChainProxy object itself is FilterChainProxyPostProcessor but couldn’t find out if this should affect my implementation choice. Any input?

Thanks a lot.

Answer 1

This is unlikely to be sufficient to protect you from malicious extension code.

If the extension can access your bean, then it can also just access the original FilterChainProxy through the ApplicationContext. In fact, it can probably access any other bean in the same configuration, so it could potentially:

• Load user account data, including passwords
• Modify or read settings on other beans to break the system
• Use reflection to read instance fields directly
• Modify the current security context
• Lots of other nasty things depending on what you are using

If you have untrusted code in your app then you would need to use a SecurityManager to prevent this kind of thing and you can then also prevent access to Spring Security classes. Configuring a SecurityManager can be a pain, but it’s probably the only option if you have code you don’t trust running in the same VM.

Update: If your only concern is preventing anyone from calling the setFilterChainMap method then overriding this method will obviously prevent anyone from accidentally calling this through a reference to your bean (this method is actually deprecated in 3.1 in favour of a constructor. However, it’s not clear from your question why someone would obtain a reference to your instance rather than the original bean, or why this is your main concern. The FilterChainProxy is not normally accessed by user code in an application. To do so, you’d have to explicitly request it from the bean factory.