El propósito de escapar de las entidades html

Cualquier analizador de análisis estático decente no marcaría una vulnerabilidad si estuviera almacenando HTML sin procesar en su base de datos; después de todo, solo es una cadena.

Las secuencias de cadenas solo se vuelven peligrosas cuando se pasan a través de una "función de sumidero".

Por ejemplo, <script> es completamente seguro para almacenar en su base de datos. De hecho asi es Robert'); DROP TABLE Students;-- .

Este último solo es peligroso cuando se pasa de una variable de cadena y se concatena a una consulta codificada en la aplicación porque toda la cadena se pasa al servidor de la base de datos y no conoce la diferencia entre la consulta y los datos. Esta es la razón por la que debería usar consultas parametrizadas para pasar datos a su base de datos; entonces, la propia base de datos sabe qué interpretar como datos fuertemente tipados, y qué interpretar como la propia construcción de la consulta.

Al enviar al navegador, aquí es donde debe codificar según corresponda. Por lo general, se enviará a HTML, por lo que necesita codificación HTML ( & se convierte en & como usted dice). Si está enviando a JSON o JavaScript (aunque no sea un campo minado), debe generar el texto con la codificación de entidad hexadecimal ( \x38 ).

Si va a persistir esos caracteres, asegúrese de utilizar variables de enlace (o declaraciones preparadas) para persistirlos.

También debe agregar la codificación HTML al mostrar la información en su interfaz de usuario.

Si puede evitar almacenar tales caracteres por las razones que mencionó (y otras), eso es lo mejor para usted. Sin embargo, si se ve obligado a considerar su modelo de negocio, aún tiene una opción: sea cual sea el lenguaje de programación que esté utilizando, siempre puede confiar en el concepto de consultas parametrizadas para cumplir ese objetivo. De esa forma, usted evita las inyecciones de SQL .