No, no es necesario. Pero por favor, sigue leyendo.
La entrada sanitización es un término horrible que pretende que puedes mover una varita mágica en los datos y convertirlos en "datos seguros". El problema es que la definición de "seguro" cambia cuando los datos son interpretados por diferentes piezas de software.
Los datos que pueden ser seguros para incrustarse en una consulta SQL pueden no ser seguros para incrustarlos en HTML. O JSON. O comandos de shell. O CSV. Y eliminar los valores (o rechazarlos directamente) para que sean seguros de incrustar en todos esos contextos (y muchos otros) es demasiado restrictivo.
Entonces, ¿qué debemos hacer? Asegúrese de que los datos nunca estén en condiciones de hacer daño.
La mejor manera de lograr esto es evitar la interpretación de los datos en primer lugar. Las consultas SQL parametrizadas son un excelente ejemplo de esto; los parámetros nunca se interpretan como SQL, simplemente se colocan en la base de datos como, bueno, datos.
Para muchas otras situaciones, los datos aún deben estar incrustados en otros formatos, por ejemplo, HTML. En ese caso, los datos deben escaparse para ese idioma en particular en el momento en que están incrustados. Por lo tanto, para evitar XSS, los datos se escapan de HTML en el momento de la visualización. No en el tiempo de entrada. Lo mismo se aplica a otras situaciones de incrustación.
Entonces, ¿deberíamos pasar todo lo que obtengamos directamente a la base de datos?
Tal vez. Depende.
Definitivamente, hay cosas que puedes consultar sobre la entrada del usuario, pero esto depende en gran medida del contexto. Debido a que el saneamiento está mal definido y es mal utilizado, prefiero llamar a esta validación .
- Por ejemplo, si se supone que un campo es un entero, ciertamente puede validar este campo para asegurarse de que contiene un entero (o tal vez NULL).
- Ciertamente, puede hacer alguna validación en los campos de correo electrónico (aunque algunas personas sostienen que no hay mucho que pueda hacer, además de verificar la presencia de
@ , y tienen un buen punto).
- Puede requerir que los comentarios tengan una longitud mínima y máxima.
- Probablemente debería verificar que cualquier cadena contenga únicamente caracteres válidos para su codificación (por ejemplo, no hay secuencias UTF-8 no válidas).
- Puede restringir un nombre de usuario a ciertos caracteres, si eso tiene sentido para su base de usuarios.
- Una longitud mínima para las contraseñas es, por supuesto, increíblemente común.
Como puede ver, estas comprobaciones dependen mucho del contexto. Y todos ellos son para ayudar a aumentar las probabilidades de obtener datos que tengan sentido. No deben proteger su aplicación de entradas maliciosas (inyección de SQL, XSS, inyección de comandos, etc.), porque este no es el lugar para hacerlo.
Los usuarios deben tener la libertad de escribir '; DROP TABLE users; -- sin que su publicación sea rechazada o modificada a \'; DROP TABLE users; -- . Tenga en cuenta que puedo incluir dicho contenido "malicioso" en sec.SE!
Entonces, para responder a tu pregunta original:
... ¿sigue siendo necesario y / o relevante para la seguridad a fin de sanear la entrada?
No, no lo es. Pero, por favor, escape adecuadamente los datos donde sea necesario antes de enviarlos. Y considere las validaciones, cuando corresponda.
Pienso en herramientas de terceros benignas, pero no tan bien diseñadas (tal vez scripts autoescritos por el administrador, o algunos CrystalReports elaborados por un no técnico) que intentan consumir datos no deseados de nuestra base de datos.
Luego, escape o filtre los datos antes de enviarlos a esas herramientas, pero no mezcle datos en su base de datos.
Pero realmente, esos scripts deben ser arreglados o reescritos teniendo en cuenta la seguridad.
(MySQL parece tener problemas con Emojis)
Poco fuera de tema, pero eche un vistazo al conjunto de caracteres utfmb4 para MySQL;)