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

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

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

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

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

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

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


spring spring-security
person Jim    schedule 13.12.2011    source источник

Ответы (1)


arrow_upward
3
arrow_downward

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

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

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

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

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

person Shaun the Sheep    schedule 13.12.2011
comment
+1. Попытка предотвратить использование с помощью этого типа сокрытия кода не остановит кого-то с действительно злонамеренными намерениями, но расстроит всех остальных, использующих вашу структуру, поскольку вы намеренно обходите (установленный) API. - person pap; 13.12.2011
comment
@user1095833 user1095833 Думаю, из вашего поста не совсем понятно, как вы используете Spring Security. Вы строите все в коде или используете ApplicationContext? Обычно единственный способ получить доступ к FilterChainProxy — это явно получить bean-компонент из ApplicationContext. Или у вас есть использование, которое включает расширение, использующее ссылку на FilterChainProxy? - person Shaun the Sheep; 13.12.2011
comment
Да, единственное, что меня беспокоит, это предотвращение вызова setFilterChainMap, потому что мы обнаружили, что код расширения напрямую обращается к bean-компоненту и использует этот установщик. Обновлен вопрос, чтобы показать файл конфигурации Spring. Он настраивает CustomFilterChainProxy вместо FilterChainProxy, поэтому обращение к bean-компоненту возвращает CustomFilterChainProxy. - person Jim; 17.12.2011
comment
Если вы настраиваете FilterChainProxy как bean-компонент, а не используете конфигурацию пространства имен, то это не должно иметь никакого значения, если вы используете пользовательский класс, при условии, что вы не измените поведение каким-либо другим образом. - person Shaun the Sheep; 17.12.2011