htmlentities - ã php

¿Almacenar las entidades html en la base de datos? O convertir cuando se recupera?

Question

Pregunta rápida, ¿es una mejor idea llamar htmlentities() (o htmlspecialchars() ) antes o después de insertar datos en la base de datos?

Antes: la nueva cadena más larga hará que tenga que cambiar la base de datos para mantener valores más largos en el campo. ( maxlength="800" podría cambiar a una cadena de 804 caracteres)

Después: Esto requerirá mucho más procesamiento del servidor, y se podrían hacer cientos de llamadas a htmlspecialchars() en cada carga de página o carga de AJAX.

Tan ¿La conversión cuando se recuperen los resultados ralentizará significativamente mi código? ¿Debo cambiar el DB?

Answer 1

En una aplicación web php / MySQL, los datos fluyen de dos maneras

Base de datos -> lenguaje de scripting (php) -> salida HTML -> navegador -> pantalla y teclado-> navegador-> $ _POST -> php -> declaración SQL -> base de datos.

Los datos se definen como todo lo proporcionado por el usuario.

SIEMPRE SIEMPRE SIEMPRE

A) procesar datos a través de mysql_real_escape_string a medida que los mueve a una declaración SQL, y

B) procese los datos a través de htmlspecialchars a medida que los mueve a la salida HTML.

Esto lo protegerá de los ataques de inyección de sql y permitirá que los caracteres y entidades html se muestren correctamente (a menos que logre olvidar un lugar y luego haya abierto un agujero de seguridad).

¿Mencioné que esto debe hacerse para cada pieza de datos que cualquier usuario pueda haber tocado, alterado o proporcionado a través de un script?

ps Por motivos de rendimiento, utilice la codificación UTF-8 en todas partes.

Answer 2

Es la forma del artesano de "medir dos veces, optimizar una vez".

Answer 3

La forma más fácil es almacenar los datos "tal cual" y luego convertirlos a htmlentities donde sea necesario.

La solución más segura es filtrar los datos antes de que entren en la base de datos, ya que esto evita posibles ataques a su servidor y a la base de datos debido a la falta de implementación de seguridad, y luego los convierte cuando sea necesario. Además, si está utilizando la DOP, esto sucederá automáticamente utilizando las declaraciones preparadas.

http://php.net/PDO

Answer 4

No tengo experiencia con php, pero generalmente siempre convierto o escapo más cerca de la salida. No sabe cuándo cambiarán sus requisitos de salida, por ejemplo, es posible que desee escupir datos como XML o matrices JSON y, por lo tanto, escapar a HTML y luego almacenar significa que está limitado a usar los datos solo como HTML.

Answer 5

Para ser honesto, es mejor almacenar el texto como sin formato y codificarlo según sea necesario. Siempre debe html codificar sus datos de todos modos cuando lo envía a la página wbe para evitar la piratería XSS.

No debe codificar sus datos antes de colocarlos en la base de datos. Las principales razones son:

1. Si dichos datos están cerca del límite de tamaño de la columna, digamos 32 caracteres, si el título era "Steve & Fred blah blah", entonces puede pasar ese límite de columna porque 1 char & se convierte en 5 char & amp;
2. Está asumiendo que los datos siempre se mostrarán en una página web, en el futuro nunca sabrá dónde los verá y es posible que no desee que estén codificados, ahora tiene que descodificarlos y es posible que no los tenga. Acceso a la función de decodificación de PHP.

Answer 6

Recomiendo almacenar la forma más cruda de los datos en la base de datos. Eso le da la mayor flexibilidad al elegir cómo y dónde generar esos datos.

Si descubre que el rendimiento es un problema, podría almacenar de alguna manera la versión en formato HTML de estos datos. Recuerde que la optimización prematura es una mala cosa.

Answer 7

Si no necesita un alto rendimiento para su sitio web, guárdelo como datos en bruto y cuando lo haga, haga lo que quiera.
Si necesita rendimiento, considere almacenarlo dos veces: datos sin procesar para hacer lo que quiera con él y otro campo con los datos filtrados. Podría verse como redundante, pero la CPU es costosa, mientras que el almacenamiento de datos es realmente barato.

Answer 8

Tuvimos este debate en el trabajo recientemente. Decidimos almacenar los valores escapados en la base de datos, porque antes (cuando los almacenábamos sin escapar) había casos de esquina donde los datos se mostraban sin escapar. Esto puede llevar a XSS. Así que decidimos guardarlo para estar a salvo, y si lo quieres sin escape, tienes que hacer el trabajo tú mismo.

Edit: Entonces, para todos los que no estén de acuerdo, permítanme agregar un poco de historia de fondo para mi caso. Digamos que está trabajando en un equipo de más de 50 personas ... y no se garantiza que los datos de la base de datos estén codificados en HTML a la salida. No hay un mecanismo incorporado para que el desarrollador tenga que escribir el código. para hacerlo. Y esta información se muestra en todo el lugar, por lo que no pasa por el código de 1 desarrollador, sino por la década de los 30, la mayoría de los cuales no tienen idea de estos datos (o que incluso podrían contener corchetes angulares, lo que es raro) y simplemente quieren obtenerlos. mostrado en la página, sigue adelante, y olvídate de ello.

¿ Sigues pensando que es mejor poner los datos, en HTML, en la base de datos y confiar en personas aleatorias que no son tú para que hagan las cosas correctamente? Porque, francamente, si bien puede que no parezca lo más cálido posible, prefiero fallar en el cierre (es decir, cuando los datos aparecen en un documento de Word se parece a Valor & lt; Stock en lugar de Valor <Stock) en lugar de abierto (por lo tanto El Word Doc se ve bien sin trabajo, pero algún rincón de la plataforma puede / es probable que sea vulnerable a XSS). No puedes tener los dos.