Escapar html en Java

Question

¿Cómo me aseguro de no escapar de algo dos veces?

He escuchado que es una buena práctica para escapar de los valores a medida que los recibe de un formulario, y también escapan cuando la salida. De esa forma tienes dos oportunidades de atrapar algo.

Answer 1

Supongo que está utilizando JSP.

Solo escape durante pantalla solamente. Allí para la etiqueta JSTL<c:out> es perfectamente adecuado. Se escapa de las entidades HTML de forma predeterminada. Úselo para mostrar cada entrada controlada por el usuario, como URL de solicitud, encabezados de solicitud y parámetros de solicitud.

E.g.

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

No es necesario el escape durante la entrada. XSS no daña en código Java sin procesar ni en bases de datos SQL. Por otro lado, también preferiría guardar los datos sin modificar en DB para que aún pueda ver lo que el usuario en realidad ingresó, para que pueda, si es necesario, realizar acciones sociales en los usuarios de mailicious.

Si desea saber de qué escapar durante la entrada, sería SQL injection. En tal caso, solo use PreparedStatement en lugar de Statement cuando quiera guardar cualquier entrada controlada por el usuario en la base de datos.

E.g.

create = connection.prepareStatement("INSERT INTO user (username, password) VALUES (?, MD5(?))"); 
create.setString(1, username); 
create.setString(2, password); 
create.executeUpdate(); 

Answer 2

Usted debe solamente html codificar cuando saca algo a un navegador. Esto evita los ataques XSS. El tipo de escape que realiza cuando recopila datos de un formulario, antes de insertarlo en una base de datos, es y no html encoding. Se está escapando caracteres especiales de la base de datos (lo mejor es usar consultas parametrizadas). El objetivo de esto es evitar ataques de inyección SQL. Entonces no hay una doble codificación.

Answer 3

El contenido inofensivo en un contexto puede ser peligroso en otro contexto. La mejor forma de evitar los ataques de inyección es preparar el contenido antes de pasarlo a otro contexto. En su caso, el texto html cambia su contexto cuando se pasa al navegador. El servidor no procesa el html, pero el navegador sí lo hace. Así que asegúrese de pasar ningún html malicioso al navegador y enmascararlo antes de enviarlo.

Otro argumento para hacerlo es que podría ser posible que el código de ataque se ensamble dentro de la aplicación desde dos o más entradas. Cada una de las entradas era inofensiva, pero juntas pueden volverse peligrosas.