JSF URL-карты безопасности - PullRequest
Новая
       5

JSF URL-карты безопасности

5 голосов
/ 14 июня 2011

Когда вы используете JSF, у вас будет контроллер-сервлет javax.faces.webapp.FacesServlet, который будет отображаться на следующее: 

<servlet-mapping>
   ...
    <url-pattern>/somefacesurl/*</url-pattern>
</servlet-mapping>

Помещение mypage.xhtml в /, у нас естьриск безопасности, потому что к нему будут обращаться двумя способами (начиная с контекста приложения): 1) /somefacesurl/mypage.xhtml 2) /mypages.xhtml

Первый обработан jsf и является правильным. Второй не обрабатывается jsf и поэтому представляется клиенту, выставляющему теги jsf, и это представляет угрозу безопасности.

Я нашел только два решения1) сопоставление всегда с корневым URL: 

<servlet-mapping>
   ...
    <url-pattern>*.xhtml</url-pattern>
</servlet-mapping>

Хорошее решение, но разрешает только сопоставления по расширению файла.

2) Сопоставление с любым URL-адресом и использование ограничений безопасности для запрета доступа к ним.файлы, как предлагается в: Как избежать доступа пользователя к странице .xhtml в JSF?

Оба решения представлены в спецификации JSF 2.0 как жизнеспособные альтернативы, НО нет ни слова о различныхподход к безопасности этих двух решений.

Поскольку безопасность НЕ рассматривается, мне интересно, является ли первое «безопасным» с точки зрения доступа к файлам xhtml или, возможно, существует способ получить файл .xhtmlисточники.

1 Ответ

3 голосов
/ 14 июня 2011

Неверно, что спецификация JSF требует первого сопоставления. Он просто приводит примеры обоих отображений в главе 11.1.2 спецификации JSF 2.0 (которую вы должны прочитать) и в главе 10.1.2 спецификации JSF 1.2. Вот выдержка из актуальности спецификации JSF 2.0 (выделено мной):

11.1.2 Отображение сервлета

Все запросы к веб-приложению сопоставляются с конкретным сервлетом на основе соответствия шаблону URL (как определено в Спецификация Java-сервлета ) для части URL запроса после контекстного пути, который выбрал этот веб приложение. Реализации JSF должны поддерживать веб-приложение, которое определяет <servlet-mapping> который сопоставляет любой действительный url-pattern с FacesServlet. Может использоваться префикс или расширение. Когда с использованием сопоставления префиксов рекомендуется следующее сопоставление, но не обязательно: 

<servlet-mapping>
    <servlet-name> faces-servlet-name </servlet-name>
    <url-pattern>/faces/*</url-pattern>
</servlet-mapping>

При использовании сопоставления расширений рекомендуется следующее сопоставление, но не обязательно: 

<servlet-mapping>
    <servlet-name> faces-servlet-name </servlet-name>
    <url-pattern>*.faces</url-pattern>
</servlet-mapping>

В дополнение к FacesServlet реализации JSF могут поддерживать другие способы вызова запроса JavaServer Faces жизненный цикл обработки, но приложения, использующие эти механизмы, не будут переносимыми.

Я действительно не понимаю, почему отображение расширения (суффикса) является "хитрым". Более того, это мое любимое отображение JSF. Я рекомендую использовать *.xhtml в качестве отображения JSF. Это также дает вам преимущество в том, что вам не нужно возиться с ограничениями безопасности для предотвращения прямого доступа к исходным файлам.

Обновление : обратите внимание, что утечка исходного кода сама по себе не является проблемой безопасности, если представление является декларативным и не содержит ни одной строки исходного кода Java, в которой используются такие переменные, как имя пользователя / пароль базы данных. хранится и выставляется. Поскольку Facelets запрещает встраивать необработанный код Java (например, JSP-скриптлеты), я не понимаю, как это утечка безопасности. Что может сделать хакер с источником просмотра? Отредактировать, отрендерить и отправить как-нибудь обратно? (Я бы очень удивился как ). Это просто невозможно, так как JSF по умолчанию полагается также на состояние просмотра на стороне сервера.

Однако я согласен с тем, что спецификация JSF должна проинформировать читателя об этом. Для этого я создал JSF spec проблема 1015 .

...