filtros - sanitize php

Cuándo filtrar/sanear los datos: ¿antes de la inserción de la base de datos o antes de mostrar? (6)

Mientras me preparo para abordar el problema del filtrado de datos de entrada y el saneamiento, tengo curiosidad por saber si hay una práctica mejor (o la más utilizada). ¿Es mejor filtrar / sanear los datos (de HTML, JavaScript, etc.) antes de insertar los datos en la base de datos, o debe hacerse cuando los datos se están preparando para mostrarlos en HTML?

Algunas notas:

Estoy haciendo esto en PHP, pero sospecho que la respuesta a esto es agnóstico del lenguaje. Pero si tiene alguna recomendación específica para PHP, ¡por favor comparta!
Este no es un problema de escapar de los datos para la inserción de la base de datos. Ya tengo muy bien el manejo de DOP.

¡Gracias!

Cuando se trata de mostrar datos enviados por el usuario, el mantra generalmente aceptado es "Filtrar entrada, salida de escape".

Recomendaría que no se escapen cosas como entidades html, etc., antes de ingresar a la base de datos, porque nunca se sabe cuándo el HTML no será su medio de visualización. Además, los diferentes tipos de situaciones requieren diferentes tipos de salida de escape. Por ejemplo, incrustar una cadena en Javascript requiere un escape diferente que en HTML. Hacer esto antes puede calmarte en una falsa sensación de seguridad.

Por lo tanto, la regla básica es sanear antes del uso y específicamente para ese uso; no preventivamente

(Tenga en cuenta que no estoy hablando de una salida de escape para SQL, solo para visualización. Por favor, siga haciendo los datos de escape para una cadena SQL).

Desinfecte la base de datos antes de colocarla en la base de datos, si es necesario (es decir, si no está utilizando una capa de interactividad de base de datos que se encarga de eso). Desinfecte para mostrar antes de mostrar.

Almacenar cosas en una forma de cita actualmente innecesaria solo causa demasiados problemas.

Hay al menos dos tipos de filtrado / desinfección que debe preocuparte:

SQL
HTML

Obviamente, el primero debe cuidarse antes / al insertar los datos en la base de datos, para evitar las inyecciones de SQL.
Pero ya lo sabes, como dijiste, así que no voy a hablar más sobre eso.

La segunda, por otro lado, es una pregunta más interesante:

Si sus usuarios deben poder editar sus datos, es interesante que se los devuelvan de la misma forma en que los ingresaron al principio; lo que significa que tiene que almacenar una versión "no html-specialchars-escaped".
si desea que se muestre algo de HTML, tal vez use algo como HTMLPurifier : muy potente ... Pero puede requerir demasiados recursos si lo está ejecutando en todos los datos cuando debe mostrarse ...

Asi que :

Si desea mostrar algo de HTML, usando una herramienta pesada para validarlo / filtrarlo, yo diría que necesita almacenar una versión ya filtrada / cualquiera que sea en la base de datos, para no destruir el servidor, recrearlo cada vez que los datos se visualiza
- pero también necesita almacenar la versión "original" (vea lo que dije antes)
- En ese caso, probablemente almacenaría ambas versiones en la base de datos, incluso si ocupa más lugar ... O al menos utilizo algún buen mecanismo de almacenamiento en caché, para no recrear la versión limpia una y otra vez.
Si no quieres mostrar ningún HTML, htmlspecialchars o un equivalente, lo que probablemente no sea un gran consumidor de CPU ... Así que probablemente no importe mucho.
- Todavía necesitas guardar la versión "original".
- pero escapar cuando estás enviando los datos podría estar bien.

Por cierto, la primera solución también es buena si los usuarios utilizan algo como bbcode / markdown / wiki al ingresar los datos, y los está mostrando en HTML ...
Al menos, siempre que se muestre con más frecuencia de la que se actualiza, y especialmente si no utiliza ningún caché para almacenar la versión HTML limpia.

Me gusta tener / almacenar los datos en forma original. solo escape / filtra los datos dependiendo de la ubicación donde lo estoy usando.

en una página web - codificar todo html
en sql - kill quotes
en url - urlencoding
en impresoras - codificar comandos de escape
en lo que sea - codifíquelo para ese trabajo

Principalmente, depende de lo que planea hacer con la entrada, así como de su entorno de desarrollo.

En la mayoría de los casos desea entrada original. De esta manera, obtienes el poder de ajustar tu salida al contenido de tu corazón sin temor a perder el original. Esto también le permite solucionar problemas como la salida rota. Siempre puede ver cómo sus filtros tienen errores o la entrada del cliente es errónea.

Por otro lado, algunos datos semánticos cortos podrían filtrarse inmediatamente. 1) No desea números de teléfono desordenados en la base de datos, por lo que para tales cosas podría ser bueno desinfectarlos. 2) No desea que otro programador genere datos de forma accidental sin escapar, y trabaja en un entorno multiprogramador. Sin embargo, para la mayoría de los casos, los datos en bruto son mejores que la OMI.

Siempre digo cosas de escape inmediatamente antes de pasarlas al lugar que necesitan para escapar. A su base de datos no le importa el HTML, por lo que es innecesario escapar de HTML antes de almacenarlo en la base de datos. Si alguna vez desea imprimir como algo que no sea HTML, o cambiar qué etiquetas están permitidas / no permitidas, es posible que tenga un poco de trabajo por delante. Además, es más fácil recordar hacer el escape correctamente cuando es necesario, que en una etapa mucho más temprana del proceso.

También vale la pena señalar que las cadenas escapadas de HTML pueden ser mucho más largas que la entrada original. Si pongo un nombre de usuario japonés en un formulario de registro, la cadena original podría tener solo 4 caracteres Unicode, pero el escape HTML puede convertirlo en una cadena larga de "& # 12345; & # 67890; & # 18504; & # 31337;" . Luego, mi nombre de usuario de 4 caracteres es demasiado largo para el campo de la base de datos y se almacena como dos caracteres japoneses más medio código de escape, lo que probablemente también me impide iniciar sesión.

Tenga en cuenta que los navegadores tienden a escapar de algunas cosas, como el texto que no está en inglés, en los formularios enviados, y siempre habrá ese smartass que usa un nombre de usuario japonés en todas partes. Por lo tanto, es posible que desee eliminar realmente el HTML antes de almacenarlo.