Tengo un proyecto (en Java) que el programador utilizó URLEncode para generar contenido como parte de HTML en lugar de HTMLEncode.
¿Cuál es el riesgo de que XSS sea vulnerable? (Olvidemos que es una codificación diferente y que obtendrá resultados diferentes)
¿Cuál es la forma correcta de hacer HTMLEncode en Java?
Evaluación de riesgos. Si los datos de URLEncoded se insertan en el contexto HTML (por ejemplo, entre etiquetas), no conozco ninguna forma de presentar un ataque XSS. URLEncode eliminará los caracteres < , > y & (a %3C , %3E y %26 , respectivamente). En los navegadores modernos, creo que esto es suficiente para evitar XSS para los valores insertados entre etiquetas.
Hay algunos casos más oscuros donde los ataques podrían ser posibles. Si está introduciendo datos no confiables (pero URLEncoded) en otros contextos de análisis, como una URL (por ejemplo, el atributo HREF de la etiqueta A), en Javascript, o en CSS, entonces es posible que los ataques XSS sigan siendo posibles a pesar de El uso URLEncode. No obstante, estos contextos son menos comunes, así que sospecho que no son de lo que estás hablando.
En resumen, es poco probable que esto sea vulnerable a XSS (por lo que puedo ver).
Por qué no deberías hacerlo. No obstante, como creo que reconoces, URLEncode es claramente la solución incorrecta para este problema. Escapa los datos de manera incorrecta y causará que los datos se modifiquen cuando el usuario los vea en su navegador. No utilice URLEncode; Es la herramienta equivocada para el trabajo. En su lugar, use la función de escape adecuada para el contexto HTML que va a usar.
Cómo hacerlo correctamente. Consulte Mi discusión en otro lugar sobre cómo seleccionar la función de escape adecuada y dónde obtener una implementación de esa función de escape. Por ejemplo, OWASP ESAPI es una excelente biblioteca llena de funciones de escape HTML que se pueden usar para prevenir vulnerabilidades de XSS.