name keywords google etiquetas ejemplos html security xss html-encode

html - keywords - meta tags google



HTML codifica la entrada del usuario cuando se almacena o cuando se muestra (5)

La codificación solo debería hacerse solo en la pantalla. Sin excepción.

Pregunta simple que me sigue molestando.

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

El almacenamiento de 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.


Le sugiero encarecidamente que codifique la información a la 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

piense en una situación en la que le interese mostrar la información como una fuente RSS. 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.


Tenga en cuenta que puede necesitar acceder a la base de datos con algo que no entienda 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.


Salida.

Con HTML, no puedes simplemente verificar la longitud de una cadena ( & es 1 carácter, pero strlen() te dirá 5), puedes recortarla fácilmente (podría romper 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 un gran fracaso. ¡No magic_entities ruta magic_entities ! :)


¿Esto no derrota 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.