Prevención de ataques de inyección CSRF, XSS y SQL en JSF

Tengo una aplicación web construida en JSF con MySQL como DB. Ya implementé el código para evitar CSRF en mi aplicación.

Ahora que mi framework subyacente es JSF, creo que no tengo que manejar el ataque XSS ya que UIComponent maneja. No estoy usando ningún JavaScript en ninguna de las páginas de vista. Incluso si uso, ¿realmente necesito implementar código para evitar ataques XSS?

Para DB estamos usando declaraciones preparadas y procedimientos almacenados en todas las interacciones de DB.

¿Hay algo más que deba manejarse para prevenir estos 3 ataques comunes? Ya he visitado el sitio de OWASP y sus hojas de trucos .

¿Debo ocuparme de otros posibles vectores de ataque?

XSS

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

    etc... 

Tenga en cuenta que cuando usa JSF 2.0 en Facelets, puede usar EL en el texto de la plantilla de esta manera:

 

Welcome, #{user.name}

Esto también será implícitamente escapado. No necesariamente necesitas aquí.

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

  

¡entonces tienes un potencial agujero de ataque XSS!

Si desea volver a mostrar la entrada controlada por el usuario como HTML en la que le gustaría permitir solo un subconjunto específico de tags HTML como , , , etc., debe desinfectar la entrada mediante un lista blanca El analizador de HTML Jsoup es muy útil en esto.

itemLabelEscaped en Mojarra <2.2.6

Las versiones anteriores de Mojarra anteriores a la 2.2.6 tenían el error por el cual incorrectamente deja la etiqueta sin guardar cuando proporcionaba una List través de lugar de List o SelectItem[] como valor ( problema 3143 ). En otras palabras, si está redistribuyendo datos controlados por el usuario como tags de elementos a través de una List , entonces tiene un posible agujero XSS. Si la actualización a Mojarra 2.2.6 como mínimo no es una opción, entonces debe establecer explícitamente el atributo itemLabelEscaped en true para evitar eso.

  

CSRF

JSF 2.x ya ha incorporado la prevención de CSRF en el sabor del campo oculto javax.faces.ViewState en el formulario cuando se usa el ahorro de estado del lado del servidor. En JSF 1.x este valor era bastante débil y demasiado fácil de predecir (en realidad nunca fue pensado como prevención de 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 y, por lo tanto, una sólida prevención de CSRF.

En JSF 2.2, esto se mejora aún más al convertirlo en una parte requerida de la especificación JSF, junto con una clave AES configurable para encriptar el estado del lado del cliente, en caso de que el ahorro de estado del lado del cliente esté habilitado. Consulte también la especificación JSF número 869 y Reutilización del valor de ViewState en otra sesión (CSRF) . Nuevo en JSF 2.2 es la protección CSRF en las solicitudes GET por .

Solo cuando usa vistas sin estado como en , o hay un agujero de ataque XSS en alguna parte de la aplicación, entonces tiene un posible 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 sin formato, JPA moderna o Hibernate antiguo), pero todo se reduce a que nunca debe concatenar la entrada controlada por el usuario en cadenas de SQL como lo hace

 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 el siguiente nombre:

 x'; DROP TABLE user; -- 

Siempre debe usar consultas parametrizadas donde 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 simple necesita usar PreparedStatement para llenar los valores de los parámetros y en JPA (e Hibernate), el objeto Query ofrece setters para esto.

No estoy usando ningún JavaScript en ninguna de las páginas de vista. Incluso si uso, realmente necesito implementar código para eludir el ataque XSS.

Puede ser vulnerable a XSS incluso si no usa JavaScript en sus páginas. XSS ocurre cuando incorpora contenido controlado por un atacante sin una encoding adecuada.

Cada vez que haces algo como

 response.write("" + x + "") 

donde un atacante puede hacer que x contenga HTML que contenga JavaScript, entonces usted es vulnerable a XSS.

La solución generalmente no es escribir grandes cantidades de código. Normalmente, la solución es codificar $x y cualquier otro valor controlado por un atacante antes de incluirlos en el HTML que genere.

 response.write("" + escapePlainTextToHtml(x) + "") 

Filtrar o desinfectar las entradas puede ayudar a proporcionar una capa adicional de protección.

También puede usar un lenguaje de plantilla que codifica la salida automáticamente para proteger contra XSS.

La plantilla de cierre es una de esas opciones para Java.

El autoescalado contextual funciona al boost las plantillas de cierre para codificar adecuadamente cada valor dynamic en función del contexto en el que aparece, defendiendo así contra las vulnerabilidades XSS en valores controlados por un atacante.

EDITAR

Como está utilizando JSF, debe leer sobre la mitigación de XSS en JSF :

Texto de salida de escape

y de forma predeterminada tiene el atributo de escape establecido en True. Al usar esta etiqueta para mostrar resultados, puede mitigar la mayoría de la vulnerabilidad XSS.

SeamTextParser y

Si desea permitir que los usuarios utilicen algunas de las tags html básicas para personalizar sus entradas, JBoss Seam proporciona una etiqueta que permite algunas tags y estilos html básicos especificados por los usuarios.