2008-10-21 9 views
26

Pregunta simple que me sigue molestando.HTML codifica la entrada del usuario al almacenar o al mostrar

¿Debo HTML codificar la entrada del usuario de inmediato y almacenar los contenidos codificados en la base de datos, o debo almacenar los valores sin procesar y la codificación HTML cuando se muestran?

Almacenar datos codificados reduce en gran medida el riesgo de que un desarrollador olvide codificar los datos cuando se muestran. Sin embargo, el almacenamiento de los datos codificados hará que la minería de datos sea algo más engorrosa y ocupará un poco más de espacio, a pesar de que generalmente no es un problema.

Respuesta

24

sugiero encarecidamente la codificación de la información en el camino de salida. almacenar datos sin formato en la base de datos es útil si desea cambiar la forma en que se ve en un determinado punto. El flujo debe ser algo similar a:

sanitize user input -> protect against sql injection -> db -> encode for display 

pensar en una situación en la que es posible que desee mostrar la información como un feed RSS en su lugar. tener que rehacer cualquier codificación específica de HTML antes de volver a mostrar parece un poco tonto. cualquier desarrollo siempre debe seguir el meme de "no confiar en la entrada", ya sea que la entrada provenga de un usuario o de la base de datos.

+2

¿Cómo funcionan las consultas subsiguientes cuando está haciendo un SELECT..WHERE y algunos de los valores tienen codificación HTML y otros no? – DOK

+0

ugh, suena un poco desordenado. realmente depende de sus detalles, pero si heredé un proyecto donde necesitaba crear nuevas vistas, y la información estaba medio codificada, probablemente volvería a almacenar la información sin codificar para hacer la vida más fácil a largo plazo. – Owen

+0

Para agregar a esto, si el proceso de codificación para la pantalla es costoso (por ejemplo, está permitiendo HTML y está ejecutando HTML Purifier), el almacenamiento en caché de la versión filtrada puede ser una opción. El espacio en disco es barato. –

5

Tenga en cuenta que es posible que necesite acceder a la base de datos con algo que no comprende el texto codificado en HTML (por ejemplo, una herramienta de informes). Estoy de acuerdo en que el espacio no es un problema, pero en mi humilde opinión, poner codificación HTML en la base de datos mueve el conocimiento de su vista/interfaz al nivel más bajo de la aplicación, y ese es un error de diseño.

+0

de acuerdo! En primer lugar, se ignora cuando las personas hacen para evitar XSS. – jack

+0

¿pueden echar un vistazo a esta [pregunta relacionada] (http://stackoverflow.com/questions/22297015/should-i-save-in-db-user-input-as-html-encode) mía? –

6

La codificación solo debe hacerse en la pantalla. Sin excepción.

6

Salida.

Con HTML no se puede simplemente comprobar longitud de una cadena (& es 1 carácter, pero strlen() le dirá 5), puede recortar fácilmente (que podría romper las entidades).

Es posible que necesite mezclar cadenas de la base de datos con cadenas de otra fuente, o leerlas y volver a escribirlas. Hacer esta aplicación sin perder ningún escape y evitar el doble escape es una pesadilla.

PHP intentó hacer algo similar con magic_quotes y resultó ser una gran falla. ¡No tome la ruta magic_entities! :)

0

¿Esto no defrauda el propósito de la codificación? Si se ingresa un script sql malicioso como entrada, que luego se pasa al db, podría causar un gran problema.

+0

Es por eso que utilizamos sql parametrizado y aprovechamos las configuraciones de seguridad. La solución para la inyección de sql es Seguridad: por ejemplo, no otorgue acceso a los usuarios de la aplicación web para escribir en tablas directamente y Dyanmic SQL: nunca escriba scripts dinámicos para insertar en una tabla. Use Procs u ORM para hacer esto por usted. –

Cuestiones relacionadas