XSS

JSF está diseñado para tener prevención XSS incorporada. Puede volver a mostrar de forma segura todas las entradas controladas por el usuario (encabezados de solicitud (incluidas las cookies!), parámetros de solicitud (también los que se guardan en DB!) y cuerpos de solicitud (archivos de texto cargados, etc)) utilizando cualquier componente JSF.

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

Tenga en cuenta que cuando está utilizando JSF 2.0 en Facelets, entonces puede usar EL en el texto de la plantilla de la siguiente manera:

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

Esto también se escapará implícitamente. No necesariamente necesitan <h:outputText> aquí.

Solo cuando estás explícitamente desescapando entrada controlada por el usuario usando escape="false":

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

Entonces tienes un agujero de ataque XSS potencial!

Si desea volver a mostrar la entrada controlada por el usuario como HTML en el que desea permitir solo un subconjunto específico de etiquetas HTML como <b>, <i>, <u>, etc, entonces usted necesita desinfectar la entrada por una lista blanca. El analizador HTML Jsoup es muy útil en este.

itemLabelEscaped error en Mojarra

Las versiones anteriores de Mojarra antes de 2.2.6 tenían el error en el que <f:selectItems itemLabel> incorrectamente renderiza la etiqueta sin escapar cuando se proporciona un List<T> a través de <f:selectItems var> en lugar de List<SelectItem> o SelectItem[] como valor ( problema 3143). En otras palabras, si estás volviendo a mostrar datos controlados por el usuario como etiquetas de elementos a través de un List<T>, entonces tienes un agujero XSS potencial. Si actualizar a al menos Mojarra 2.2.6 no es una opción, entonces necesita establecer explícitamente itemLabelEscaped atributo a true para evitar eso.

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

CSRF

JSF 2.x ya ha incorporado la prevención de CSRF en el tipo de javax.faces.ViewState campo oculto en el formulario cuando se utiliza el ahorro de estado del lado del servidor. En JSF 1.x este valor era a saber bastante débil y demasiado fácil predecible (en realidad nunca fue pensado como prevención CSRF). En JSF 2.0, esto se ha mejorado mediante el uso de un valor autogenerado largo y fuerte en lugar de un valor de secuencia bastante predecible, lo que lo convierte en un CSRF robusto prevención.

En JSF 2.2 esto se puede mejorar aún más al convertirlo en una parte requerida de la especificación JSF, junto con una clave AES configurable para cifrar el estado del lado del cliente, en caso de que se habilite el ahorro de estado del lado del cliente. Véase también JSF spec issue 869 y Reutilizando el valor ViewState en otra sesión (CSRF). Nuevo en JSF 2.2 es la protección CSRF en las solicitudes GET por <protected-views>.

Solo cuando estás usando vistas sin estado como en <f:view transient="true">, o hay en algún lugar de un agujero de ataque XSS en la aplicación, entonces usted tiene un potencial agujero de ataque CSRF.

Inyección SQL

Esto no es responsabilidad de JSF. Cómo evitar esto depende de la API de persistencia que esté utilizando (JDBC en bruto, JPA moderna o buena hibernación), pero todo se reduce a que debe nunca concatenar la entrada controlada por el usuario en cadenas SQL como así

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

Imagine lo que sucedería si el usuario final elige lo siguiente nombre:

x'; DROP TABLE user; --

Debe siempre usar consultas parametrizadas cuando corresponda.

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

En JDBC plano debe usar PreparedStatement para llenar los valores de los parámetros y en JPA (e Hibernar), el Query object también ofrece setters para esto.