XSS

JSF został zaprojektowany tak, aby miał wbudowaną profilaktykę XSS. Możesz bezpiecznie ponownie odtworzyć wszystkie wejścia kontrolowane przez użytkownika (nagłówki żądań (w tym pliki cookie!), parametry żądania (również te, które są zapisywane w DB!) i organy żądań (przesłane pliki tekstowe, itp.)) przy użyciu dowolnego komponentu JSF.

<h:outputText value="#{user.name}" />
<h:outputText value="#{user.name}" escape="true" />
<h:inputText value="#{user.name}" />
etc...

Zauważ, że gdy używasz JSF 2.0 na Faceletach, możesz użyć EL w tekście szablonu w następujący sposób:

<p>Welcome, #{user.name}</p>

To również w domyśle zostanie usunięte. Ty nie koniecznie potrzebuję <h:outputText> tutaj.

Tylko gdy jawnie unescaping wejście kontrolowane przez Użytkownika za pomocą escape="false":

<h:outputText value="#{user.name}" escape="false" />

Więc masz potencjalną dziurę do ataku XSS!

Jeśli chcesz ponownie wyświetlić dane wejściowe sterowane przez użytkownika jako HTML, w którym chcesz zezwolić tylko na określony podzbiór znaczników HTML, takich jak <b>, <i>, <u>, itd., następnie należy wyczyścić dane wejściowe za pomocą białej listy. Parser HTML Jsoup jest bardzo pomocny w to.

itemLabelEscaped bug in Mojarra

Starsze wersje Mojarra przed 2.2.6 miały błąd, w którym <f:selectItems itemLabel> nieprawidłowo renderuje Etykietę bez znaku, gdy podano List<T> poprzez <f:selectItems var> zamiast List<SelectItem> lub SelectItem[]jako wartość ( wydanie 3143). Innymi słowy, jeśli zmieniasz dane kontrolowane przez użytkownika jako etykiety przedmiotów za pomocą List<T>, masz potencjalną dziurę w XSS. Jeśli aktualizacja do co najmniej Mojarra 2.2.6 nie jest opcją, musisz jawnie ustawić itemLabelEscaped atrybut true, aby temu zapobiec.

<f:selectItems value="#{bean.entities}" var="entity" itemValue="#{entity}"
    itemLabel="#{entity.someUserControlledProperty}" itemLabelEscaped="true" />

CSRF

JSF 2.x wbudował już zapobieganie CSRF w ukrytym polu javax.faces.ViewState w formularzu przy użyciu zapisywania stanu po stronie serwera. W JSF 1.x wartość ta była dość słaba i zbyt łatwa do przewidzenia (w rzeczywistości nigdy nie była przeznaczona jako zapobieganie CSRF). W JSF 2.0 zostało to poprawione przez użycie długiej i silnej wartości autogeneracyjnej zamiast dość przewidywalnej wartości sekwencji, dzięki czemu stał się solidnym CSRF profilaktyka.

W JSF 2.2 jest to jeszcze bardziej ulepszone, czyniąc go wymaganą częścią specyfikacji JSF, wraz z konfigurowalnym kluczem AES do szyfrowania stanu po stronie klienta, w przypadku, gdy włączone jest zapisywanie stanu po stronie klienta. Zobacz także JSF Spec issue 869 i ponowne użycie wartości ViewState w innej sesji (CSRF). Nowością w JSF 2.2 jest ochrona CSRF przy żądaniach GET przez <protected-views>.

Tylko wtedy, gdy używasz bezstanowych widoków jak w <f:view transient="true">, lub jest gdzieś dziura ataku XSS w aplikacji, to masz potencjalny dziura ataku CSRF.

SQL injection

To nie jest odpowiedzialność JSF. Jak temu zapobiec, zależy od używanego interfejsu API persistence (raw JDBC, modern JPA lub good old' Hibernate), ale wszystko sprowadza się do tego, że nie powinieneś nigdy łączyć kontrolowanych przez użytkownika danych wejściowych z łańcuchami SQL w taki sposób

String sql = "SELECT * FROM user WHERE username = '" + username + "' AND password = md5(" + password + ")";
String jpql = "SELECT u FROM User u WHERE u.username = '" + username + "' AND u.password = md5('" + password + "')";

Wyobraź sobie, co by się stało, gdyby użytkownik końcowy wybrał następujące nazwa:

x'; DROP TABLE user; --

Powinieneś zawsze używać parametryzowanych zapytań tam, gdzie ma to zastosowanie.

String sql = "SELECT * FROM user WHERE username = ? AND password = md5(?)";
String jpql = "SELECT u FROM User u WHERE u.username = ?1 AND u.password = md5(?2)";

W zwykłym JDBC musisz użyć PreparedStatement aby wypełnić wartości parametrów i w JPA (i Hibernate),Query obiekt oferuje również setery do tego celu.