XSS

JSF est conçu pour avoir la prévention XSS intégrée. Vous pouvez rejouer en toute sécurité tout entrée contrôlée par l'utilisateur (en-têtes de demande (y compris les cookies!), les paramètres de la demande (et celles qui sont enregistrées dans la bd!) et request bodies (uploaded text files, etc)) en utilisant n'importe quel composant JSF.

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

notez que lorsque vous utilisez JSF 2.0 sur Facelets, vous pouvez utiliser EL dans le texte du modèle comme suit:

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

cela aussi sera implicitement échappé. Vous n'avez pas nécessairement besoin de <h:outputText> ici.

Seulement lorsque vous êtes explicitement unescaping contrôlée par l'utilisateur d'entrée à l'aide de escape="false" :

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

alors vous avez un trou d'attaque XSS potentiel!

si vous souhaitez rediffuser L'entrée contrôlée par l'utilisateur en HTML dans lequel vous souhaitez n'autoriser qu'une entrée spécifique sous-ensemble de balises HTML comme <b> , <i> , <u> , etc, puis vous devez nettoyer l'entrée par une liste blanche. Le parser HTML Jsoup est très utile dans ce.

itemLabelEscaped bug dans la Mojarra < 2.2.6

anciennes versions de Mojarra avant 2.2.6 avait le bug dans lequel <f:selectItems itemLabel> rend incorrectement l'étiquette non enregistrée quand fourni un List<T> via <f:selectItems var> au lieu de List<SelectItem> ou SelectItem[] comme valeur ( numéro 3143 ). En d'autres termes, si vous rediffusez des données contrôlées par l'utilisateur en tant qu'étiquettes d'articles via un List<T> , alors vous avez un trou XSS potentiel. Si la mise à niveau vers au moins Mojarra 2.2.6 n'est pas une option, vous devez définir explicitement l'attribut itemLabelEscaped à true pour éviter cela.

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

---

CSRF

JSF 2.x a déjà intégré prévention CSRF dans la saveur de javax.faces.ViewState champ caché dans la forme lors de l'utilisation de sauvegarde d'État côté serveur. Dans le JSF 1.x cette valeur était à savoir assez faible et trop facile à prévoir (il n'a en fait jamais été prévu que la prévention CSRF). Dans JSF 2.0, cela a été amélioré en utilisant une valeur longue et forte autogénérée au lieu d'une valeur de séquence assez prévisible et en faisant ainsi une prévention robuste CSRF.

dans JSF 2.2 c'est même être encore améliorée en faisant une partie nécessaire de la spécification JSF, avec une clé AES configurable pour chiffrer l'État côté client, dans le cas où l'enregistrement d'État côté client est activé. Voir aussi JSF Spec issue 869 et réutilisant ViewState value in other session (CSRF) . Nouveau dans JSF 2.2 est la protection CSRF sur les requêtes GET par <protected-views> .

seulement si vous utilisez des vues apatrides comme dans <f:view transient="true"> , ou il y a quelque part un trou d'attaque XSS dans l'application, alors vous avez un trou D'attaque CSRF potentiel.

---

SQL injection

ce N'est pas la responsabilité de JSF. La façon d'empêcher cela dépend de l'API de persistance que vous utilisez (JDBC brute, JPA moderne ou bon vieil hibernation), mais tous les trucs vers le bas que vous devriez jamais concaténer entrée contrôlée par l'utilisateur dans les chaînes SQL comme si

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 + "')";

imaginez ce qui se passerait si l'utilisateur final choisissait le nom suivant:

x'; DROP TABLE user; --

Vous devriez toujours utiliser des requêtes paramétrées, le cas échéant.

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)";

dans JDBC simple, vous devez utiliser PreparedStatement pour remplir les valeurs des paramètres et dans JPA (et Hibernate), le Query objet propose des setters pour cela ainsi.