Стандарт проверки безопасности приложений OWASP - V3 и использование с JSF - PullRequest
Новая
       36

Стандарт проверки безопасности приложений OWASP - V3 и использование с JSF

1 голос
/ 08 марта 2012

В настоящее время я занимаюсь реализацией всего, что нужно для защиты от угроз безопасности проекта Top 10
Для № 4 из 10 лучших - небезопасных прямых ссылок на объекты OWASP относится к Стандарту проверки безопасности приложений OWASP

Итак, я читал все суффиксы в V3 , но теперь у меня есть несколько вопросов по его реализации.
Я использую JBoss-AS 7.0.1 с Java EE6 и JSF 2.0

V3.4 Убедитесь, что идентификатор сеанса никогда не раскрывается, кроме как в заголовках файлов cookie; особенно в URL, сообщениях об ошибках или журналах. Это включает проверку того, что приложение не поддерживает перезапись URL-адресов файлов cookie сеанса.

Я читал здесь несколько статей о stackoverflow, как избежать появления jesssion в URL в первый раз, когда пользователь посещает сторону ... Но многие ответы такие: используйте переписывание URL ... что это означает в отличие от does not support URL rewriting of session cookies

Какой нормальный способ справиться с jsessions в первой записи? Что такое безопасный способ справиться с этим?

V3.10: убедитесь, что только идентификаторы сеансов, сгенерированные платформой приложения, распознаются приложением как действительные.

Как вы это делаете в JSF2.0 / JavaEE?

V3.12. Убедитесь, что для файлов cookie, содержащих аутентифицированные токены / идентификаторы сеанса, домен и путь установлены для соответствующего ограничительного значения для этого сайта.

Что это значит? Когда я смотрю со своим Firebug в cookie, я запускаю веб-приложение с URL http://localhost:8080/projectname/
и в cookie я получаю: Путь: / имя_проекта
это то, что означает OWASP с have their domain and path set to an appropriately restrictive value for that site.?

Спасибо!

1 Ответ

2 голосов
/ 08 марта 2012

V3.4 Убедитесь, что идентификатор сеанса никогда не раскрывается, кроме как в заголовках файлов cookie;особенно в URL, сообщениях об ошибках или журналах.Это включает проверку того, что приложение не поддерживает перезапись URL файлов cookie сеанса.

Контейнер сервлета по умолчанию настроен на поддержку отслеживания сеанса с помощью файлов cookie и URL-адресов.Отслеживание сеанса по URL-адресу также называется «перезапись URL-адреса», в котором вы видите ;jsessionid=[session id], отображаемый в URL-адресах.Это будет запущено автоматически, когда у клиента отключены куки.Чтобы отключить отслеживание по URL, необходимо явно указать режим отслеживания только по файлам cookie.Добавьте это в web.xml: 

<session-config>
    <tracking-mode>COOKIE</tracking-mode>
</session-config>

веб-приложения. Кроме того, вам необходимо убедиться, что код JSF нигде не печатает идентификатор сеанса в вывод HTML, среди прочего <h:outputText value="#{session.id}" />.

V3.10: убедитесь, что только идентификаторы сеансов, сгенерированные платформой приложения, распознаются приложением как действительные.

Контейнер сервлета по умолчанию уже сделает это.Только Tomcat 6.x (и, следовательно, по сути, также JBoss 5.x) имели проблему безопасности, заключающуюся в том, что при включении общего доступа к сеансам на сервере сервер будет использовать точно идентификатор сеанса, предоставленный клиентом в Cookie.заголовок запроса.Tomcat 7.x (и, следовательно, по сути также JBoss 6.x / 7.x) больше не будет этого делать.См. Также среди прочих документацию Tomcat 6.x <Connector> для получения дополнительной справочной информации (см. Описание атрибута emptySessionPath).

V3.12: Убедитесь, что для файлов cookie, содержащих аутентифицированные токены / идентификаторы сеансов, для домена и пути установлены соответствующие ограничительные значения для этого сайта.

Контейнер сервлета по умолчанию уже будет это делать.Только когда вы конфигурируете контейнер сервлета для использования общего сеанса сервера (таким образом, один и тот же сеанс распределяется между всеми развернутыми приложениями), это нарушает правило.См. Также предыдущий пункт.

Обратите внимание, что большинство из этих правил имеют очень мало общего с JSF.Они больше связаны с общей конфигурацией сервера и веб-приложения.JSF - это просто основанная на компонентах инфраструктура MVC.

...