Попытка предоставить альтернативную реализацию для SpringC FilterChainProxy

Question

Я работаю над приложением, использующим безопасность Spring.
Приложение расширяемое, и я хотел бы заблокировать расширения программным изменением фильтров в карте цепочек фильтров Spring's FilterChainProxy.Я собираюсь сделать следующее:

1. Реализация CustomFilterChainProxy реализации всех реализованных интерфейсов FilterChainProxy (Filter, InitializingBean, ApplicationContextAware).В нем я буду держать приватного члена FilterChainProxy и делегировать ему все вызовы интерфейса.

2. Использовать DelegatingFilterProxy Spring, объявив в файле web.xml:

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

3. В файлах конфигурации Spring вместо непосредственного использования Spring FilterChainProxy у моего компонента будет CustomFilterChainProxy в качестве класса, как показано ниже:

   <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. Чтобы иметь возможность установить карту цепочки фильтров во время загрузки bean-компонента Spring, я должен предоставить установщик в своем классе CustomFilterChainProxy.Что я сделаю.И чтобы предотвратить установку карты цепочки фильтров после загрузки bean-компонента Spring, я позабочусь о том, чтобы после построения bean-компонента (в методе @PostConstruct) из этого установщика было сгенерировано исключение.

Имея CustomFilterChainProxy вместо FilterChainProxy, я вызываю какой-либо сбой Spring-процесса?

Я видел, что единственный класс Spring, ссылающийся на сам объект FilterChainProxy, это FilterChainProxyPostProcessor, но не смогвыяснить, должно ли это повлиять на мой выбор реализации.Любой ввод?

Большое спасибо.

Answer 1

Этого вряд ли достаточно, чтобы защитить вас от вредоносного кода расширения.

Если расширение может получить доступ к вашему бину, то оно также может просто получить доступ к оригинальному FilterChainProxy через ApplicationContext. Фактически, он может получить доступ к любому другому компоненту в той же конфигурации, поэтому он может потенциально:

• Загрузка данных учетной записи пользователя, включая пароли
• Изменение или чтение настроек на других компонентах, чтобы сломать систему
• Использовать отражение для непосредственного чтения полей экземпляра
• Изменить текущий контекст безопасности
• Множество других неприятных вещей в зависимости от того, что вы используете

Если в вашем приложении есть недоверенный код, вам нужно будет использовать SecurityManager, чтобы предотвратить подобные вещи, а затем вы также можете запретить доступ к классам Spring Security. Настройка SecurityManager может быть трудной задачей, но, вероятно, это единственный вариант, если у вас есть код, которому вы не доверяете, работающий на той же виртуальной машине.

Обновление: Если ваша единственная задача состоит в том, чтобы никто не вызывал метод setFilterChainMap, то переопределение этого метода, очевидно, предотвратит случайный вызов этого метода через ссылку на ваш bean-компонент (этот метод фактически устарел в 3.1 в пользу конструктора. Однако из вашего вопроса неясно, почему кто-то получит ссылку на ваш экземпляр, а не на исходный бин, или почему это ваша главная задача. FilterChainProxy обычно не вызывается пользовательским кодом в приложения. Для этого вам необходимо явно запросить его у фабрики бинов.