Tengo una aplicación web hecha en JSF con MySQL como base de datos. Ya he implementado el código para evitar que CSRF en mi aplicación.

Ahora desde mi marco subyacente es JSF, supongo que no tengo que manejar ataque XSS como ya es manejado por UIComponent. No estoy usando ningún JavaScript en cualquiera de las páginas de vista. Incluso si yo uso lo que realmente necesita para implementar código para evitar ataques XSS?

Para DB estamos utilizando preparado las instrucciones y procedimientos almacenados en todos los DB interacciones.

¿Hay algo más que necesita ser manejado para la prevención de estas 3 común de los ataques?
Ya he sido a través de la OWASP sitio y sus hojas de trucos.

Necesito para cuidar de otros posibles vectores de ataque?

3 Comentarios

  1. 107

    XSS

    JSF está diseñado para tener builtin XSS la prevención. De forma segura puede volver a mostrar todos controlada por el usuario de entrada (encabezados de solicitud (incluyendo las cookies!), los parámetros de solicitud (también los que se guardan en la base de datos!) y a solicitud de los órganos (cargar archivos de texto, etc)) el uso de 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 usted está utilizando JSF 2.0 en Facelets, entonces usted puede utilizar en EL texto de la plantilla así:

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

    Esto también implícitamente se escapó. Usted no necesariamente necesita <h:outputText> aquí.

    Sólo cuando usted está explícitamente unescaping controlada por el usuario de entrada utilizando escape="false":

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

    luego has un potencial ataque de XSS agujero!

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

    itemLabelEscaped error en Mojarra < 2.2.6

    Mayores Mojarra versiones antes de 2.2.6 tenía el bug donde <f:selectItems itemLabel> representa incorrectamente la etiqueta de sin escape cuando se proporciona un List<T> a través de <f:selectItems var> en lugar de List<SelectItem> o SelectItem[] como valor (tema 3143). En otras palabras, si usted está volvemos a poner controlada por el usuario datos como elemento de etiquetas a través de una List<T>, entonces usted tiene un potencial de XSS agujero. Si la actualización a al menos Mojarra 2.2.6 no es una opción, entonces usted necesita para establecer explícitamente itemLabelEscaped atributo true para evitar que.

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

    CSRF

    JSF 2.x ya ha incorporado CSRF prevención en el sabor de javax.faces.ViewState campo oculto en el formulario cuando se utiliza el lado del servidor estado de ahorro. En JSF 1.x este valor fue a saber bastante débil y demasiado fácil de predicción (que en realidad nunca fue pensado como CSRF prevención). En JSF 2.0 esta ha sido mejorado mediante el uso de un largo y fuerte valor generado de forma automática en lugar de una secuencia predecible de valor y, por tanto, es un robusto CSRF la prevención.

    En JSF 2.2, esto es incluso ser mejorado aún más por lo que es una parte necesaria de la especificación JSF, junto con un configurables clave AES para cifrar el lado del cliente del estado, en caso de que lado del cliente estado de ahorro está habilitado. Véase también JSF spec problema 869 y La reutilización de valor de ViewState en otra sesión (CSRF). De nuevo en JSF 2.2 es la protección CSRF en las solicitudes GET por <protegido de vistas>.

    Sólo cuando se está utilizando apátridas vistas como en <f:view transient="true">, o hay en algún lugar un ataque XSS agujero en la aplicación, entonces usted tiene un potencial ataque CSRF agujero.


    De inyección de SQL

    Esto no es JSF responsabilidad. Cómo evitar que esto depende de la API de persistencia está utilizando (raw JDBC, moderno JPA o good ol’ Hibernación), pero todo se reduce a que usted debe nunca concatenar controlada por el usuario de entrada en cadenas SQL como

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

    Imaginar lo que pasaría si el usuario final elige el siguiente nombre:

    x'; DROP TABLE user; --

    Debe siempre utilizar 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 la llanura de JDBC que usted necesita para utilizar PreparedStatement para rellenar los valores de los parámetros y en JPA (Hibernate y), la Consulta objeto ofrece incubadoras para esto también.

    • Yo añadiría que, al contrario de lo que creen, el uso de procedimientos almacenados no no guardar automáticamente desde los ataques de inyección SQL: he visto a los procedimientos almacenados de SQL create declaraciones por concatenación y que es igualmente vulnerables a la inyección de SQL! Se trata de la misma manera que el uso de PreparedStatements no guardan automáticamente a partir de los ataques de inyección SQL, si usted está utilizando mal!
    • Bien no puedo agradecerles lo suficiente por este excelente explicación..Pero tengo algunas dudas. En mi GUI, yo uso <h:outputText value=»#{usuario.nombre}» escape=»false» /> para mostrar en la interfaz gráfica de usuario..Ahora este es un potencial Ataque XSS.¿Cómo puedo evitarlo.??. En segundo lugar, estoy stll el uso de JSF 1.2 y entonces, ¿cómo puedo manejar CSRF entonces?.He utilizado WebScrarab herramienta para interceptar la Petición Http y modificar el valor y, de hecho, fue un éxito.Qué significa que la aplicación es propenso a los ataques.¿Cómo puedo evitar. Ya he manejado la inyección de SQL. Sólo una cosa te preocupes por mí es XSS y CSRF como los de ahora..por Favor ayuda.
    • También la explicación proporcionada por Samuel me sugieren para tener una mirada en el cierre de la Plantilla para el saneamiento de HTML de la entrada. Pero he oído que el cierre de la plantilla grave problema de rendimiento y además es de Google Labs, así que será casi en versión Beta por lo tanto no es estable…Que uno recomendaría para HTMl santizing..Jsoup o Cierre..soy absolutamente nuevo en esto santizing y análisis y, por tanto, yo preferiría algo que es fácil de aprender y aplicar.
    • En cuanto a XSS, acaba de quitar escape="false". O si desea permitir que ciertos HTML, a continuación, utilizar Jsoup. Usted sólo necesita hacer String safe = Jsoup.clean(unsafe, Whitelist.basic());. Véase también esta guía. Usted puede hacer esto directamente antes de guardar la entrada en DB. En cuanto a CSRF prevención en JSF 1.x, debe mantener una sesión basada en el anti-CSRF token en el formulario (básicamente, un oculto campo de entrada con un largo/autogenerado/impredecible valor). Seam framework tiene un componente similar <s:token>: seamframework.org/Documentation/CrossSiteRequestForgery
    • Por cierto, si usted está usando JSF 1.2, ¿por qué la etiqueta de JSF 2.0 en la pregunta?
    • si usted tiene una mirada en el OWASP Dokument acerca de Inyección ORM usted puede leer the current Oracle JDBC driver escapes input for prepared statements and parameterized stored procedures. por lo que esto significa, que está a salvo de las Inyecciones, a la derecha?
    • podemos para una mejor seguridad en escribir un filtro y en este uso Jsoup.limpia en todos los parámetros de petición? yo hago esto, pero me devuelve un java.lang.IllegalStateException y dice No modifications are allowed to a locked ParameterMap. gracias por el tiempo que usted gasta.
    • no hacerlo durante la entrada, pero durante sólo de salida.
    • puede usted decir lo que deberá abstenerse de esto en la entrada? yo almacenar algunos datos en la base de datos. y durante la salida significa que hacer este trabajo sobre la respuesta de los parámetros del objeto? gracias mucho.
    • Con respecto a XSS y escape automático en JSF me gustaría considerar que vale la pena mencionar que hay una excepción a la regla (por h:selectOneMenu componentes), se documenta aquí: stackoverflow.com/questions/15020320/…
    • es #{usuario.nombre} escapado incluso si yo uso JSTL con Facelets?

  2. 8

    No estoy usando ningún JavaScript en cualquiera de las páginas de vista. Incluso si yo uso lo que realmente necesita para implementar código para la derivación de Ataque XSS.

    Puede ser vulnerable a XSS, incluso si usted no utiliza código JavaScript en sus páginas. XSS se produce al incorporar el contenido controlado por un atacante sin la adecuada codificación de los mismos.

    Cualquier momento de hacer algo como

    response.write("<b>" + x + "</b>")

    donde un atacante puede causar x para contener código HTML que contiene JavaScript, entonces usted es vulnerable a XSS.

    La solución es generalmente no para escribir grandes cantidades de código. Normalmente la solución es codificar $x y otros valores controlado por un atacante antes de incluirlos en el código HTML de generar.

    response.write("<b>" + escapePlainTextToHtml(x) + "</b>")

    La filtración o desinfección de los insumos pueden ayudar a proporcionar una capa adicional de protección.

    <shameless-plug>

    También puede utilizar una plantilla de lenguaje que codifica la salida de forma automática para proteger contra XSS.

    El Cierre De La Plantilla es uno de esos opción para Java.

    Contextuales autoescaping funciona mediante el aumento de Cierre de Plantillas para codificar correctamente cada valor dinámico basado en el contexto en el que aparece, por lo tanto la defensa contra vulnerabilidades XSS en valores que son controlados por un atacante.

    EDITAR

    Puesto que usted está utilizando JSF usted debe leer sobre XSS de mitigación en JSF:

    Escapar de texto de salida

    <h:outputText/> y <h:outputLabel/> por defecto tiene el escape atributo se establece en True. Mediante esta etiqueta a las salidas de pantalla, usted es capaz de mitigar la mayoría de la vulnerabilidad de XSS.

    SeamTextParser y <s:formattedText/>

    Si desea permitir a los usuarios utilizar algunas de las etiquetas html básicas para personalizar sus entradas, JBoss Seam proporciona un <s:formattedText/> etiqueta que permite que algunas etiquetas html básicas y estilos especificados por los usuarios.

    • Lo siento, no soy muy claro con su respuesta.
    • Hay una frase en particular que usted encuentre confuso?
    • El problema es que estoy usando JSF y supongo que al igual que otros marcos se genera automáticamente HTML..Así que todavía estoy desorientado sobre lo que escribió..yo también pasó por el cierre de la plantilla..es tan nuevo para mí…
    • También para agregar:- Mi GUI no va a permitir que el usuario introduzca el soporte de ángulo de etiquetas<>.Se producirá la validación del lado del cliente y el pedido no será procesado..por lo que he entendido, SI me permite al USUARIO introducir etiquetas HTML en mi GUI entonces tengo que usar el cierre de la plantilla para asegurarse de que todas son válidas las etiquetas y que todos no son válidos…por Favor me corrija si estoy equivocado.
    • He editado para añadir un puntero a algunas de las mejores prácticas para la vulnerabilidad de XSS de mitigación en JSF.
    • Que enlace ciertamente resuelto muchas de mis dudas..
    • A diferencia de como en la vieja usanza, JSP/Servlets, JSF no tiene realmente un concepto de response.write(foo). Esta respuesta es un poco confuso para usuarios que son nuevos en JSF 2.x.

  3. 0

    Cuando usted está usando JSF con PrimeFaces, tenga cuidado de <p:textEditor> – por defecto no desinfectar la entrada del usuario, así que cuando se utiliza <h:outputText escape="false"> está abierto para un desagradable ataque de XSS. En tales casos, he creado un JSF htmlSanitizingConverter que utiliza Jsoup para desinfectar la entrada del usuario. Se puede utilizar como esto:

    <h:outputText escape="false" converter="htmlSanitizingConverter"/>

    Y el propio convertidor:

    /**
     * Prevents from XSS attack if output text is not escaped.
     */
    @FacesConverter("htmlSanitizingConverter")
    public class HtmlSanitizingConverter implements Converter {
    
        private static final Whitelist JSOUP_WHITELIST = Whitelist.relaxed()
                .preserveRelativeLinks(true)
                .addAttributes(":all","style");
                /*
                 Optionally - add support for hyperlinks and base64 encoded images.
                .addTags("img")
                .addAttributes("img", "height", "src", "width")
                .addAttributes("a", "href")
                .addProtocols("img", "src", "http", "https", "data");
                */
    
        @Override
        public Object getAsObject(FacesContext context, UIComponent component, String submittedValue) {
            return (submittedValue != null) ? Jsoup.clean(submittedValue, JSOUP_WHITELIST) : null;
        }
    
        @Override
        public String getAsString(FacesContext context, UIComponent component, Object value) {
            return (value != null) ? Jsoup.clean(value.toString(), JSOUP_WHITELIST) : "";
        }
    
    }
    • 1: de componentes individuales no debe ser una respuesta a una pregunta genérica. 2: El problema se corrigió en la versión 7.0 en que el componente puede ser configurado para hacer la limpieza y en 7.1 duraran incluso ser la predeterminada.
    • converter es una solución general para la solución de este problema, independientemente de la tecnología utilizada. Sólo estoy señalando esta PF problema porque es el más popular de los componentes JSF de la biblioteca y las versiones anteriores de PF son todavía muy utilizado (y en la mayoría de los casos no se actualiza debido a problemas de compatibilidad).
    • No estoy diciendo que tu respuesta no es valioso, creo que es, sólo que no pertenecen directamente aquí. Puede (e incluso animó a) en Stackoverflow para crear una pregunta y respuesta de usted mismo. E. g. ‘¿Cómo puedo prevenir la vulnerabilidad de XSS en p:el editor de texto` y responder a ti mismo con esta respuesta. Es en serio, muy apreciado y mantiene las cosas en claro, separados etc.
    • Entiendo que el convertidor es genérico, pero ese es también el caso cuando se utiliza una llanura textarea, y es una costumbre js html editor plugin (o la reducción o incluso cuando plain html se escribe en un textarea). Así que usted puede hacer que sea más genérico, centrándose en las diferentes maneras de entradas también (de ahí refiriéndose a la p:textEditor a). Ahora la respuesta parece centrarse únicamente en el p:textEditor mientras que la solución está en la pantalla y no la ‘entrada de datos’ (puedes utilizar un convertidor en la entrada demasiado… Incluso más limpio… No hay riesgos si alguien se olvida de aplicar en la salida

Dejar respuesta

Please enter your comment!
Please enter your name here