Секунда весны: перехватить URL-адрес легко обойти?

1

В нашем приложении java мы используем Spring security для управления полномочиями на основе ролей. Недавно нам стало известно, что делать с несколькими сопоставлениями сервлетов в web.xml эти проверки URL-адресов были легко обойдены. Однако, сократив до одного отображения сервлета, я все еще не уверен, что у нас есть правильные URL-адреса, потому что их смешно легко обойти. Например:

 <sec:intercept-url pattern="/m/partner/list/**" access="hasRole('VIEW_ADMIN_PARTNER_LIST')"/>

На первый взгляд, это не позволяет пользователю с ролью VIEW_ADMIN_PARTNER_LIST загружать эту страницу... пока я не добавлю .html к концу. Тогда он загружается просто отлично. Или, если я добавлю .fff или любое другое расширение, оно работает. Итак, мы изменили шаблон на это:

 <sec:intercept-url pattern="/m/partner/list**" access="hasRole('VIEW_ADMIN_PARTNER_LIST')"/>

Это отлично работает! Теперь, независимо от того, какое расширение я добавляю в конец URL-адреса, я все равно получаю ошибку 403. Но... добавление косой черты в конец URL-адреса полностью обходит безопасность. Не то, что мы хотим.

Похоже, что для реального внедрения реальной защиты шаблонов URL мы должны реализовать оба этих шаблона? Это меньше, чем идеально, потому что у нас есть более 75 правил безопасности URL, и их дублирование и синхронизация будут сложными. Есть ли лучший способ написать сопоставления шаблонов, или Spring безопасности по своей сути нарушена?

Изменение: вот соответствующая информация из нашего web.xml:

<servlet-mapping>
    <servlet-name>myproject</servlet-name>
    <url-pattern>/m/*</url-pattern>
</servlet-mapping>

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

<filter-mapping>
    <filter-name>springSecurityFilterChain</filter-name>
    <url-pattern>/*</url-pattern>
</filter-mapping>
Теги:
spring-security
spring
spring-mvc

2 ответа

0
Лучший ответ

Переключитесь на использование выражений регулярных выражений для выражения ваших URL-адресов, это дает вам большую гибкость, например:

<sec:http auto-config="true" use-expressions="true" path-type="regex">
    <sec:intercept-url pattern="/m/partner/list.*" access="hasRole('VIEW_ADMIN_PARTNER_LIST')"/>
</sec:http>

Уведомление /** было заменено на .* Которое в мире регулярного выражения будет соответствовать чему угодно.

Поделиться
  • 0
    @anttix - What's wrong with ant expressions for his use case? варианта What's wrong with ant expressions for his use case? - ммм, они не работают, как следует из вопроса;)
  • 0
    Он пытается обеспечить путь / m / partner / list, что мешает работе выражения муравья? Кроме понятия, что "регулярное выражение круто"?
Показать ещё 7 комментариев
0

По умолчанию Spring Security использует шаблоны Ant. Образец, который вы ищете

/m/partner/list*/**

Это будет соответствовать

  • /m/partner/list.html
  • /m/partner/list/c.html
  • /m/partner/list/c/d.html
  • и т.д

Ниже приведен фрагмент кода Java, который можно использовать для тестирования шаблонов Ant (добавьте ant.jar в classpath)

import org.apache.tools.ant.types.selectors.SelectorUtils;
public class PatternTest {
    public static void main(String [] args) {
        System.out.println(SelectorUtils.matchPath("/a/b*/**", "/a/b"));
        System.out.println(SelectorUtils.matchPath("/a/b*/**", "/a/b.html"));
        System.out.println(SelectorUtils.matchPath("/a/b*/**", "/a/b/c.html"));
    }
}
Поделиться

Ещё вопросы

Сообщество Overcoder
Наверх
Меню