2010-02-25 1 views
6

Estoy buscando algo de prevención XSS en mi aplicación Java.Java 5 HTML escaping Para evitar XSS

Actualmente tengo rutinas personalizadas que escaparán de cualquier HTML almacenado en la base de datos para una visualización segura en mi jsps. Sin embargo, prefiero usar un método integrado/estándar para hacer esto si es posible.

Actualmente no estoy codificando los datos que se envían a la base de datos, pero me gustaría comenzar a hacerlo también.

¿Hay algún método incorporado que pueda ayudarme a lograr esto?

+5

Tenga en cuenta que la respuesta aceptada a continuación es un enfoque incompleto e ingenuo. 'La codificación de los" 5 grandes "sirve exactamente para el propósito para el que fue diseñada: evita la inyección de etiquetas HTML con caracteres ilegales dentro de las etiquetas y los valores de los atributos. Sin embargo, no impide inyecciones más elaboradas, no ayuda con "caracteres fuera de rango = signos de interrogación" cuando se envían cadenas a escritores con codificaciones de un solo byte, ni impide la reinterpretación de caracteres cuando el usuario cambia la codificación del navegador sobre la página mostrada' http: // www .owasp.org/index.php/How_to_perform_HTML_entity_encoding_in_Java – Pool

+0

¿No diría usted que la respuesta aceptada es en general correcta, es solo que se debe tener en cuenta una mayor gama de caracteres cuando se escapa el HTML? – AJM

+0

Es bueno mantener la puerta cerrada con llave, pero probablemente sea mejor no dejar las ventanas abiertas de par en par. Es un consejo peligroso. – Pool

Respuesta

9

Normalmente escapa de XSS durante pantalla, no durante tienda. En JSP puede usar la etiqueta JSTL (simplemente suelte jstl-1.2.jar en /WEB-INF/lib) o la función fn:escapeXml para esto. P.ej.

<input name="foo" value="<c:out value="${param.foo}" />"> 

o

<input name="foo" value="${fn:escapeXml(param.foo)}"> 

Eso es todo. Si lo hace durante el procesamiento de la entrada y/o el almacenamiento en DB también, entonces todo está distribuido en el código comercial y/o en la base de datos. No debe hacer eso, es solo un problema de mantenimiento y correrá el riesgo de escapes dobles o más cuando lo haga en diferentes lugares (por ejemplo, & se convertiría en &amp;amp; en lugar de &amp; para que el usuario final vea literalmente &amp; en lugar de & en la vista. .. de código y DB no son sensibles a XSS Sólo la vista es a continuación, debe escapar sólo allí

actualización:. has publicado 4 temas sobre el mismo tema:

sólo le advertirá: haces no necesidad de escapar en servlet/filtro/JAVACODE/base de datos/lo que sea. Solo estás complicando innecesariamente las cosas. Solo escapéalo durante la exhibición. Eso es todo.

+0

Sí, tal vez debería dejar de publicar preguntas ahora ... En términos de tratar con la salida que es una conclusión que me atrae, pero me doy cuenta de que algunos sitios aconsejan que generes como mínimo y luego la codificas en la tienda por encima ese. – AJM

+0

Tiene buenos sitios y tiene sitios malos. – BalusC

+0

Sí, pero ¿sabe de una fuente bastante definida que podría señalar a alguien que está enamorado de la idea de persistir en el código HTML para cambiar su forma de pensar? – AJM

5

no incorporado, pero echa un vistazo a owasp esapi filter, debe hacer lo que estás buscando y más. Es una gran biblioteca de seguridad de código abierto escrita por las chicas inteligentes & chicas en Owasp ("Proyecto de seguridad de aplicaciones web abiertas").

5

Tengo que decir que no estoy de acuerdo con la respuesta aceptada de aparentemente escapar en la salida para evitar XSS.

Creo que el mejor enfoque es desinfectar la entrada que se puede lograr fácilmente con un aspecto para que no tenga que colocarlo por todos lados. Desinfección es diferente de escapar.

No puede escapar a ciegas:

  • es posible que desee que los usuarios introduzcan un subconjunto de HTML (también conocidos como enlaces y etiquetas de negrita).
  • Escapar no impide XSS

recomiendo el uso de la biblioteca de OWASP Antisammy con la recomendación un aspecto o @ de futtta del filtro.

A continuación se muestra un aspecto que escribí para desinfectar la entrada del usuario utilizando las anotaciones de Spring MVC (ya que utilizamos eso para todas nuestras entradas).

@SuppressWarnings("unused") 
@Aspect 
public class UserInputSanitizerAdivsor { 

    @Around("execution(@RequestMapping * * (..))") 
    public Object check(final ProceedingJoinPoint jp) throws Throwable { 
     Object[] args = jp.getArgs(); 
     if (args != null) { 
      for (int i = 0; i < args.length; i++) { 
       Object o = args[i]; 
       if (o != null && o instanceof String) { 
        String s = (String) o; 
        args[i] = UserInputSanitizer.sanitize(s); 
       } 
      } 
     } 
     return jp.proceed(args); 
    } 
} 

Usted todavía tendrá que escapar en la producción de los campos no de texto enriquecido pero nunca se podrá (y creo que nunca debe) tener datos maliciosos en su base de datos.

Si no desea desinfectar ciertas entradas siempre puede hacer una anotación que hará que el aspecto no se desinfecte.

La otra razón por la que no desea datos maliciosos en su base de datos es si proporciona cualquier tipo de API REST a Internet. Puede hacer lo correcto en el resultado, pero sus socios mashup no pueden hacerlo.

La entrada de desinfección o entrada de bloqueo está bien (me refiero a que la mayoría de las personas tiene límite de carga de archivos ¿verdad?). La mayoría de los campos de una aplicación web no necesitan etiquetas de guiones para ser ingresados ​​y lo más importante es que la mayoría de sus usuarios probablemente no necesiten o quieran ingresar etiquetas de guiones (la excepción obvia es la desbordamiento de pila).

+0

Esto simplemente va en contra de la recomendación general de OWASP. La desinfección de la entrada es problemática porque, en muchos casos, desinfecta incorrectamente datos perfectamente legales porque algunos caracteres * pueden * ser dañinos cuando se muestran sin escaparse. –

+0

La realidad es que necesitas hacer ambas cosas particularmente si permites la entrada de HTML. El hecho de que desinfecte no significa que tenga que almacenarlo también. Simplemente puede fallar y decirle al usuario por qué. –