Pregunta Prácticas recomendadas de Java para evitar secuencias de comandos cruzadas del sitio [cerrado]


He revisado las principales vulnerabilidades de OWASP y he descubierto que Cross-Site Scripting es lo que tenemos que tomar notas. Hubo pocas soluciones recomendadas. Uno ha declarado que no utilice la validación de la "lista negra" para detectar XSS en la entrada o para codificar la salida. Buscando y reemplazando solo unos pocos caracteres (< y > y otros caracteres o frases similares como script) es débil y ha sido atacado con éxito. Incluso sin marcar “<b>” la etiqueta no es segura en algunos contextos. XSS tiene un sorprendente número de variantes que hacen que sea fácil pasar por alto la validación de la lista negra. Otra solución dijo que la codificación de salida fuerte. Asegúrese de que todos los datos proporcionados por el usuario estén adecuadamente codificados por la entidad (ya sea HTML o XML según el mecanismo de salida) antes de la representación. Entonces, ¿cuál es la mejor forma de evitar que las secuencias de comandos cross-site validen y reemplacen la entrada o codifiquen la salida?


32
2017-07-21 14:58


origen


Respuestas:


La práctica habitual es escaparse de HTML controlado por el usuario datos durante volver a mostrar en JSP, no durante tratamiento los datos enviados en servlet ni durante almacenamiento en DB. En JSP puedes usar el JSTL (para instalarlo, solo suelta jstl-1.2.jar en /WEB-INF/lib) <c:out> etiqueta o fn:escapeXml función para esto. P.ej.

<%@ taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c" %>
...
<p>Welcome <c:out value="${user.name}" /></p>

y

<%@ taglib uri="http://java.sun.com/jsp/jstl/functions" prefix="fn" %>
...
<input name="username" value="${fn:escapeXml(param.username)}">

Eso es. No hay necesidad de una lista negra. Tenga en cuenta que los datos controlados por el usuario cubren todo que viene por una solicitud HTTP: los parámetros de solicitud, cuerpo y encabezados (!!).

Si escapa HTML durante el procesamiento de los datos enviados y / o también los almacena en DB, entonces todo está distribuido en el código comercial y / o en la base de datos. Eso es solo un problema de mantenimiento y correrá el riesgo de escapes dobles o más cuando lo haga en diferentes lugares (p. & se convertiría &amp;amp; en lugar de &amp; para que el usuario final literalmente vea &amp; en lugar de & en vista. El código comercial y DB a su vez no son sensibles para XSS. Solo la vista es Entonces deberías escapar solo justo ahí en vista.

Ver también:


39
2017-08-10 01:22



Usa ambos. De hecho, consulte una guía como Hoja de trucos de OWASP XSS Prevention, sobre los posibles casos para el uso de la codificación de salida y la validación de entrada.

La validación de entrada ayuda cuando no puede confiar en la codificación de salida en ciertos casos. Por ejemplo, es mejor que valide las entradas que aparecen en las URL en lugar de codificar las mismas URL (Apache no publicará una URL codificada en url). O para el caso, valide las entradas que aparecen en las expresiones de JavaScript.

En última instancia, una regla simple ayudará: si no confías lo suficiente en la entrada del usuario o si sospechas que ciertas fuentes pueden provocar ataques XSS a pesar de la codificación de salida, valídala contra una lista blanca.

Eche un vistazo a la OWASP ESAPIcódigo fuente sobre cómo se escriben los codificadores de salida y los validadores de entrada en una biblioteca de seguridad.


6
2017-07-21 20:30



Mi preferencia es codificar todos los caracteres no alfabéticos como entidades de caracteres numéricos HTML. Dado que casi todos los ataques, si no todos, requieren caracteres no alfonéricos (como <, ", etc.) esto debería eliminar una gran cantidad de salida peligrosa.

El formato es & # N ;, donde N es el valor numérico del carácter (puede simplemente convertir el carácter en un int y concatenar con una cadena para obtener un valor decimal). Por ejemplo:

// pseudocódigo java-ish
StringBuffer safestrbuf = new StringBuffer (string.length () * 4);
foreach (char c: string.split ()) {
  if (Character.isAlphaNumeric (c)) safestrbuf.append (c);
  else safestrbuf.append ("" + (int) symbol);

También deberá asegurarse de que está codificando inmediatamente antes de imprimir en el navegador, para evitar la doble codificación o la codificación de HTML, pero enviando a una ubicación diferente.


0
2017-07-21 17:33