JSF просмотреть идентификатор как токены запроса - PullRequest
Новая
       25

JSF просмотреть идентификатор как токены запроса

2 голосов
/ 26 марта 2010

Я где-то читал, что идентификаторы представлений, используемые в JSF-фреймворке, имеют приятный побочный эффект, выступая в качестве токенов запроса и, таким образом, блокируя CSRF.Может кто-нибудь сказать мне, если это означает, что мне не нужно ничего делать с точки зрения программирования (то есть).Как программист, если я использую JSF, мне не нужно беспокоиться о CSRF?

Ответы [ 3 ]

3 голосов
/ 09 апреля 2010

JSF действительно имеет «встроенную» защиту от CSRF с помощью javax.faces.ViewState. На JSF 1.x это, может быть, «слишком просто» угадать. Это было исправлено в JSF 2.1. См. Также выпуск JSF 812 и выпуск JSF 869 .

Ваши основные проблемы должны быть XSS и SQL-инъекции . Успешная атака XSS будет источником гарантированной успешной атаки CSRF. Чтобы избежать XSS, убедитесь, что вы (пере) отображаете все контролируемый пользователем ввод, используя h:outputText, а не в виде простого шаблона шаблона. Внедрение SQL не обязательно приводит к потенциальным дырам в CSRF, но может привести к утечке или неправильному отображению конфиденциальных данных. Чтобы избежать этого, убедитесь, что вы используете надежную среду ORM, которая использует именованные запросы (JPA, Hibernate и т. Д.) Или, когда вы используете "простой ванильный" JDBC, убедитесь, что вы используете PreparedStatement вместо Statement полностью.

0 голосов
/ 26 октября 2010

Извините, на днях я ошибся: «Я сказал, что мое приложение JSF не сообщает о какой-либо проблеме CSRF». Но теперь я хотел бы сказать вам, что JSF не имеет встроенной защиты от CSRF. Я тестировал с помощью инструмента CSRFTester, он показывает, что мое приложение JSF уязвимо для атак CSRF. А также я хотел бы сказать вам, что все приложения Java EE уязвимы для CSRF-атак. Я нашел один из возможных способов защитить приложение от CSRF-атаки - генерировать случайные токены и добавлять их в URL. Спасибо !!

0 голосов
/ 19 апреля 2010

Это гарантировано? В некоторых реализациях JSF используется последовательный идентификатор, который может быть угадан злоумышленником.

Вот статья, в которой описывается, как Sun JSF-RI выполняет последовательную генерацию идентификатора представления вместо более принятого Java SecureRandom:

http://seamframework.org/Documentation/CrossSiteRequestForgery

...