shoucheng3/nahsra__antisamy_cve-2022-29577_1-6-6-1Biblioteca Java para la limpieza rápida y configurable de HTML no confiable para prevenir ataques de cross-site scripting (XSS). Utiliza análisis basado en políticas para sanitizar el marcado proporcionado por el usuario.
Una biblioteca para realizar una limpieza rápida y configurable de HTML proveniente de fuentes no confiables. Compatible con Java 7+.
Otra forma de decirlo podría ser: es una API que te ayuda a asegurarte de que los clientes no proporcionen código malicioso en el HTML que envían para su perfil, comentarios, etc., que se persiste en el servidor. El término "código malicioso" en relación con aplicaciones web generalmente significa "JavaScript". Mayormente, las Hojas de Estilo en Cascada solo se consideran maliciosas cuando invocan JavaScript. Sin embargo, hay muchas situaciones en las que el HTML y CSS "normales" pueden usarse de forma maliciosa.
Primero, agrega la dependencia desde Maven:
<dependency>
<groupId>org.owasp.antisamy</groupId>
<artifactId>antisamy</artifactId>
<version>LATEST_VERSION</version>
</dependency>
Es probable que el caso de uso de tu sitio para AntiSamy sea al menos aproximadamente comparable a uno de los archivos de política predefinidos. Cada uno representa un escenario "típico" para permitir que los usuarios proporcionen formato HTML (y posiblemente CSS). Veamos los diferentes archivos de política:
Slashdot es un sitio de noticias tecnológicas que permite a los usuarios responder anónimamente a publicaciones con un marcado HTML muy limitado. Slashdot no solo es uno de los sitios más populares, sino también uno que ha sido objeto de muchos ataques exitosos diferentes. Las reglas para Slashdot son bastante estrictas: los usuarios solo pueden enviar las siguientes etiquetas HTML y ningún CSS: <b>, <u>, <i>, <a>, <blockquote>.
En consecuencia, hemos creado un archivo de política que permite una funcionalidad bastante similar. Se han permitido todas las etiquetas de formato de texto que operan directamente sobre la fuente, el color o el énfasis.
eBay es el sitio de subastas en línea más popular del universo, hasta donde sé. Es un sitio público, por lo que cualquiera puede publicar listados con contenido HTML enriquecido. No sorprende que, dado el atractivo de eBay como objetivo, haya estado sujeto a algunos ataques XSS complejos. Los listados pueden contener contenido mucho más enriquecido que, por ejemplo, Slashdot, por lo que su superficie de ataque es considerablemente mayor.
MySpace era, cuando nació este proyecto, el sitio de redes sociales más popular. Se permitía a los usuarios enviar prácticamente todo el HTML y CSS que quisieran, siempre que no contuviera JavaScript. MySpace usaba una lista negra de palabras para validar el HTML de los usuarios, razón por la cual fue víctima del infame gusano Samy. El gusano Samy, que utilizaba ataques de fragmentación combinados con una palabra que debería haber estado en la lista negra (eval), fue la inspiración para este proyecto.
No conozco un caso de uso posible para este archivo de política. Si quisieras permitir todos y cada uno de los elementos HTML y CSS válidos (pero sin JavaScript ni ataques de phishing relacionados con CSS), puedes usar este archivo de política. Ni siquiera MySpace llegó a ese extremo. Sin embargo, sirve como una buena referencia porque contiene reglas base para cada elemento, por lo que puedes usarlo como base de conocimiento al personalizar los otros archivos de política.
Mientras trabajábamos en algunas mejoras en la Definición de Esquema XML (XSD) de AntiSamy para los archivos de política, notamos que AntiSamy NO estaba aplicando realmente el XSD. Por lo tanto, hemos CAMBIADO el comportamiento predeterminado a partir de AntiSamy 1.6.0 para que aplique el esquema y no continúe si la política de AntiSamy no es válida. Sin embargo...
reconocemos que puede no ser posible que los desarrolladores corrijan sus políticas de AntiSamy de inmediato si no cumplen, y aun así quieran actualizar AntiSamy para obtener mejoras de seguridad, nuevas funcionalidades y correcciones de errores. Por ello, proporcionamos dos formas de deshabilitar (¡temporalmente!) la validación del esquema:
Establecer la propiedad del sistema Java: owasp.validator.validateschema en false. Esto se puede hacer desde la línea de comandos (por ejemplo, -Dowasp.validator.validateschema=false) o mediante el archivo de propiedades del sistema Java. Ninguno de los dos requiere un cambio de código.
Modificar el código que usa AntiSamy para invocar: Policy.setSchemaValidation(false) antes de cargar la política de AntiSamy. Esta es una llamada estática, por lo que una vez deshabilitada, queda deshabilitada para todas las nuevas instancias de Policy.
Para animar a los usuarios de AntiSamy a usar solo políticas compatibles con XSD, AntiSamy siempre registrará algún tipo de advertencia cuando la validación del esquema esté deshabilitada. O bien ADVERTIRÁ que la política no cumple para que pueda corregirse, o bien ADVERTIRÁ que la política cumple, pero la validación del esquema está DESACTIVADA, por lo que la validación debería volver a activarse (es decir, dejar de deshabilitarla). También agregamos registro a nivel INFO cuando se cargan y validan los esquemas de AntiSamy.
La capacidad de deshabilitar la nueva función de validación de esquema pretende ser temporal, para facilitar la transición hacia archivos de política de AntiSamy correctamente válidos. Planeamos eliminar esta función en la próxima versión principal. Estimamos que esto ocurrirá a mediados o finales de 2022, así que no será pronto. La idea es dar a los equipos de desarrollo que usan AntiSamy directamente o a través de otras bibliotecas como ESAPI, tiempo suficiente para que sus archivos de política cumplan con el esquema antes de que la validación del esquema sea obligatoria.
Esto se solucionó rápidamente en 1.6.1 para usar solo las APIs de slf4j. AntiSamy ahora incluye la biblioteca slf4j-simple para su registro, pero los usuarios de AntiSamy pueden importar y usar una biblioteca de registro alternativa compatible con slf4j si lo prefieren. También pueden excluir slf4j-simple si así lo desean.
ADVERTENCIA: El uso de slf4j-simple por parte de AntiSamy, sin archivo de configuración, registra mensajes de forma almacenada en búfer en la salida estándar. Por lo tanto, algunos o todos estos mensajes de registro pueden perderse si se lanza una Excepción, como una PolicyException. Esto probablemente se puede solucionar configurando slf4j-simple para que registre en la salida de error estándar, o usando un registrador slf4j alternativo que lo haga.
Puede que quieras implementar AntiSamy con una configuración predeterminada, pero es igualmente probable que un sitio quiera tener reglas estrictas, impulsadas por el negocio, sobre lo que los usuarios pueden permitir. La discusión que decide la personalización también debe considerar la superficie de ataque, que crece en proporción relativa al archivo de política.
Usar AntiSamy es fácil. Aquí hay un ejemplo de cómo invocar AntiSamy con un archivo de política:
import org.owasp.validator.html.*;
Policy policy = Policy.getInstance(POLICY_FILE_LOCATION);
AntiSamy as = new AntiSamy();
CleanResults cr = as.scan(dirtyInput, policy);
MyUserDAO.storeUserProfile(cr.getCleanHTML()); // alguna función personalizada
Hay varias formas de crear un objeto Policy. El método getInstance() puede tomar cualquiera de los siguientes: