Защита внутренних страниц шаблона слоя представления в приложениях сервлета

Question

У меня очень простой вопрос о веб-приложениях MVC на Java.

Начиная с прежних дней сырой JSP и вплоть до современных технологий, таких как Seam, очень простой шаблон всегда был внутренней диспетчеризацией от контроллера, который первоначально принял запрос к уровню представления, который создает выходные данные для отправки клиенту.

Эта внутренняя диспетчеризация обычно выполняется (хотя механизм может быть скрыт через дополнительный уровень конфигурации), запрашивая у контейнера сервлета новый ресурс с использованием URL-адреса. Сопоставление этих URL-адресов выполняется тем же файлом web.xml, который также определяет «реальный» URL-адрес снаружи.

Если не приняты специальные меры, часто можно напрямую получить доступ к слою вида. Посмотрите демонстрационную версию "регистрации" в Seam, где вы можете обойти "register.seam" и перейти непосредственно к "istered.xhtml ". Это потенциальная проблема безопасности. По крайней мере, он пропускает представление исходного кода шаблона.

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

Какой самый простой способ ограничить точки входа URL?

Может быть, есть что-то вроде каталога "WEB-INF", компонента магического пути URL, доступ к которому возможен только по внутренним запросам?

Answer 1

Вы можете запретить доступ к внутренним ресурсам, используя security-constraint в дескрипторе развертывания web.xml.

Например, я использую следующую конфигурацию для предотвращения прямого доступа к JSP:

<!-- Prevent direct access to JSPs. -->
<security-constraint>
    <web-resource-collection>
        <web-resource-name>JSP templates</web-resource-name>
        <url-pattern>*.jsp</url-pattern>
    </web-resource-collection>
    <auth-constraint/> <!-- i.e. nobody -->
</security-constraint>

Answer 2

Один из способов справиться с этим - создать фильтр сервлетов, который проверяет путь запроса каждого запроса и обрабатывает каждый запрос соответственно. Вот ссылка, которая может помочь вам начать работу, JavaServer Pages (JSP) и JSTL - Контроль доступа с помощью JSP

Answer 3

Я бы не рекомендовал разрешать интернет-запросам прямой доступ к вашему серверу приложений. Я бы бросил веб-сервер впереди, а затем разрешил запрос определенных типов URL. Не хотите, чтобы люди заходили на foo.com/jsps? Ограничь это раз и навсегда.

Здесь немного разговоров на эту тему: скрытие страниц за WEB-INF?

Answer 4

Я видел пару приложений, которые помещают свои внутренние JSP в WEB-INF/jsp. Это, кажется, делает трюк, по крайней мере, для JSP, а также для скорости. , похоже, не работает для JSF .